Optimización de imágenes de contenedores: De 1,2 GB a 45 MB
Las imágenes Docker grandes ralentizan los pipelines CI/CD y los despliegues. Con Multi-Stage Builds y buenas prácticas puede reducir drásticamente el tamaño de la imagen.
Por qué importa el tamaño de la imagen
Una imagen Docker de 1.2 GB significa: builds más lentos, pushes más lentos al registry, pulls más lentos en los nodos y una mayor superficie de ataque. Las imágenes más pequeñas son más rápidas y más seguras.
Multi-Stage Builds
La palanca más importante: separe las dependencias de Build de las dependencias de Runtime. En la etapa de Build, instale compiladores, herramientas de construcción y dependencias de desarrollo. En la etapa final, copie solo los artefactos compilados.
Selección del Base Image
- Alpine: Base Image de aproximadamente 5 MB, ideal para aplicaciones Go y Rust. Precaución con PHP y Python: musl vs. glibc puede causar problemas de compatibilidad.
- Distroless: Las imágenes Distroless de Google contienen solo el runtime, sin shell ni gestores de paquetes. Máxima seguridad.
- Debian Slim: Buen compromiso entre compatibilidad y tamaño para aplicaciones PHP y Node.js.
Optimización de capas
- Orden: Las capas que cambian con poca frecuencia (SO, dependencias) antes de las capas que cambian frecuentemente (código de la aplicación), para maximizar el uso de la caché.
- .dockerignore: Excluya node_modules, .git, tests y documentación del contexto de build.
- Combinar: Agrupar múltiples comandos RUN en una sola capa para evitar capas intermedias.
Resultado
Mediante estas técnicas, en un proyecto de cliente redujimos el tamaño de la imagen de 1.2 GB a 45 MB. El tiempo de build bajó de 8 a 2 minutos, y los despliegues son tres veces más rápidos.
¿Preguntas sobre este tema?
Le asesoramos con gusto sobre las tecnologías y soluciones descritas en este artículo.
Contactar
