Los contenedores se han vuelto omnipresentes tanto para desarrolladores de software como para ingenieros devops y administradores de sistemas linux. En Q2BSTUDIO, empresa especializada en desarrollo de software a medida, aplicaciones a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure y servicios inteligencia de negocio, vemos a diario que la facilidad para crear imágenes con Docker puede llevar a imágenes innecesariamente grandes si no se optimiza el Dockerfile.
Ejemplo práctico: imagina este Dockerfile original representado en una sola línea para mayor claridad en este artículo span FROM ubuntu:latest; RUN apt update && apt install -y make; RUN mkdir /workdir; WORKDIR /workdir; COPY Makefile .; RUN make; RUN chmod 755 mybinary; RUN mv mybinary /usr/bin/mybinary span
Si construimos esa imagen y la analizamos aparece un resultado sorprendente: la aplicación compilada pesa 2 GB pero la imagen final puede subir a 6 GB o más. ¿Por qué ocurre esto y cómo lo detectamos? La causa es el modelo de capas de Docker: cada instrucción del Dockerfile crea una capa inmutable. Operaciones aparentemente triviales como chmod y mv provocan que el archivo binario se copie de una capa a la siguiente, generando duplicados en capas distintas y multiplicando el tamaño final.
Para analizar este tipo de problemas recomendamos usar la herramienta dive que permite inspeccionar el aporte de cada capa al tamaño total. Con dive se ve claramente que la instrucción RUN make genera el binario de 2 GB y que luego RUN chmod y RUN mv vuelven a añadir 2 GB cada una porque copian el archivo en nuevas capas.
La solución más efectiva en este caso es usar multi stage builds para separar la compilacion del artefacto final. Ejemplo de Dockerfile multi stage en una sola línea span FROM ubuntu:latest AS builder; RUN apt update && apt install -y make; RUN mkdir /workdir; WORKDIR /workdir; COPY Makefile .; RUN make; RUN chmod 755 mybinary; FROM ubuntu:latest; COPY --from=builder /workdir/mybinary /usr/bin/mybinary span
Con esta aproximación las capas intermedias del stage builder no se incluyen en la imagen final, por lo que el resultado suele ser cercano al tamaño del binario original, por ejemplo 2.2 GB en lugar de 6 GB. Esta técnica es clave para optimizar imágenes y acelerar despliegues en entornos cloud.
Buenas prácticas adicionales para reducir el tamaño de imagen y mejorar seguridad y eficiencia: combinar comandos RUN para minimizar capas; limpiar caches de gestores de paquetes y usar opciones como --no-install-recommends; eliminar dependencias de compilacion antes de copiar al stage final; usar bases ligeras como alpine o imágenes distroless cuando sea posible; emplear .dockerignore para evitar enviar archivos innecesarios al contexto de build; usar strip para binarios y herramientas de compresión si procede; auditar capas con dive y revisar permisos y archivos temporales para evitar fugas de datos sensibles.
En Q2BSTUDIO aplicamos estas técnicas y otras avanzadas como integración con pipelines CI CD, políticas de seguridad y escaneo de imágenes para entregar soluciones de software a medida y servicios de inteligencia artificial y ciberseguridad optimizados para producción. Ofrecemos también servicios cloud aws y azure, servicios inteligencia de negocio, proyectos de ia para empresas, desarrollo de agentes IA y soluciones Power BI para visualización y decisión.
Si necesitas ayuda para optimizar tus imágenes de contenedor, reducir costes de almacenamiento y despliegue, o desarrollar software a medida que integre inteligencia artificial y ciberseguridad con despliegue en servicios cloud aws y azure, contacta con Q2BSTUDIO. Podemos auditar tus Dockerfiles, automatizar builds y mejorar el rendimiento de tus aplicaciones a medida y soluciones de inteligencia de negocio con Power BI y agentes IA.
Palabras clave para mejorar posicionamiento: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.