Crear imágenes eficientes con Docker empieza por un Dockerfile mínimo y evoluciona hacia multi-stage builds cuando el proyecto crece. Aquí se explica, paso a paso y sin complicaciones, cómo pasar de una imagen simple a una imagen final de .NET optimizada, tal como se ve al trabajar con Visual Studio, VS Code y Docker Desktop.
¿Por qué iniciar con un Dockerfile mínimo?
Empezar con pocas líneas reduce errores y acelera la creación de imágenes. En un backend de Python, basta con una imagen base, un directorio de trabajo e instalar dependencias. Funciona y es simple. Sin embargo, en proyectos complejos, la imagen puede crecer de forma importante.
¿Qué problema resuelve multi-stage?
Al crear una API con ASP.NET desde Visual Studio, el Dockerfile generado tenía varias sentencias FROM repetidas. Esto indica una técnica multi-stage: varias etapas encadenadas para compilar, publicar y ensamblar solo lo necesario.
- Imagen base: queda lista, sin cargar código aún.
- Etapa de compilación: usa SDK para tomar el proyecto de C# y ejecutar un dotnet build.
- Etapa de publicación: ejecuta dotnet publish y deja únicamente los ensamblados.
- Etapa final: copia los archivos publicados a la imagen base con runtime y entrega una imagen más pequeña y enfocada.
El resultado: se usa solo lo necesario, no todo el árbol de código, y la imagen se vuelve más ligera y segura de manejar.
¿Cómo funciona el flujo multi-stage en .NET?
El Dockerfile de Visual Studio puede tener unas 25 líneas y tres etapas bien visibles: compilación, publicación y final. Durante la construcción, el log muestra claramente “etapa 1/3, 2/3, 3/3”, lo que ayuda a verificar que cada paso se ejecuta correctamente.
¿Qué diferencia hay entre Visual Studio y la documentación de Microsoft?
La documentación de Microsoft simplifica el proceso a dos etapas: usar FROM para restaurar y publicar, y luego una segunda etapa para empaquetar en la imagen de ASP.NET. Es la misma idea, pero más compacta: menos pasos, mismo objetivo.
- Visual Studio: tres etapas separadas y explícitas.
- Documentación de Microsoft: dos etapas, restaurar/publicar y final.
Ambas rutas dejan una imagen optimizada con solo los archivos necesarios de la aplicación.
¿Qué comandos clave se usan?
Para construir la imagen multi-stage del proyecto “multi-stage” en VS Code:
- Cambiar a la carpeta del proyecto:
cd multi-stage.
- Verificar el Dockerfile en la ruta actual.
- Construir con etiqueta específica.
docker build -t multi-stage .
Durante la compilación se observan mensajes que indican el paso entre etapas. Así confirmas que el encadenamiento funciona y que cada fase hace su parte.
¿Qué resultados y optimización se observaron?
En Docker Desktop, la imagen “multi-stage” aparece con un peso aproximado de 843 MB para una aplicación estándar de .NET. Es un avance, pero aún hay margen para reducir más el tamaño en iteraciones futuras.
¿Qué habilidades y conceptos se refuerzan?
- Diseño de Dockerfile minimalista: menos líneas, menos errores.
- Uso de multi-stage: FROM repetidos que representan etapas.
- Diferencia entre SDK y runtime: compilar vs ejecutar.
- Comandos dotnet build y dotnet publish: separar compilación y publicación.
- Lectura del log de construcción: identificar “1/3, 2/3, 3/3”.
- Trabajo en VS Code sin tener .NET instalado: se ejecuta todo dentro de Docker.
- Validación en Docker Desktop: revisión de la imagen final y su tamaño.
¿Te gustaría que mostremos más tácticas para recortar el peso de la imagen y automatizar el flujo? Deja tus dudas y propuestas en los comentarios.
