Optimiza tus contenedores con una técnica simple y eficaz: combinar comandos para reducir capas en imágenes de Docker. Esta práctica mejora tiempos de build y disminuye el tamaño final, sin complicarte ni perder claridad en tu Dockerfile.
¿Cómo optimizar imágenes de Docker con capas mínimas?
Reducir capas es clave porque cada instrucción en el Dockerfile crea una capa independiente. Al fusionar pasos repetitivos, como actualizaciones e instalaciones, se obtiene una imagen más ligera y rápida de construir. Además, este enfoque surge de la experiencia: con el tiempo vas identificando qué comandos pueden ir juntos sin sacrificar legibilidad.
En el ejemplo, se parte de una imagen base de Ubuntu y se construyen varias capas: actualización del paquete, instalación de curl, copia de archivos a /app y ejecución de un comando simple de terminal. La idea central: agrupar actualización e instalación en un solo RUN para ahorrar una capa y, cuando aplica, eliminar archivos innecesarios para liberar espacio.
¿Qué comandos y estructura componen el ejemplo?
En VS Code se crea una carpeta “Capas” y un Dockerfile (en minúscula, para demostrar que funciona igual). La primera versión usa cinco capas: imagen base, actualización, instalación, copia y ejecución.
¿Cuál es la versión por pasos del Dockerfile?
# Capa 1: imagen base
FROM ubuntu:latest
# Capa 2: actualización de paquetes
RUN apt update
# Capa 3: instalación de curl
RUN apt install -y curl
# Capa 4: copia de archivos a /app
COPY . /app
# Capa 5: ejecutar un comando
RUN echo "Hello World"
Para construir la imagen desde la carpeta “Capas” se usa:
¿Cómo combinar apt get update e install en una sola capa?
Al fusionar actualización e instalación en un solo RUN, se elimina una capa. Incluso se puede, cuando corresponde, limpiar archivos que ya no se necesiten.
FROM ubuntu:latest
# Actualización + instalación en una sola capa
RUN apt-get update && apt-get install -y curl
COPY . /app
RUN echo "Hello World"
Este pequeño cambio reduce el número de capas y mejora el rendimiento general del build.
¿Qué resultados y buenas prácticas se obtienen?
En la primera construcción, la imagen “capas” pesa aproximadamente 204 MB y tarda cerca de 26 segundos en generarse. Tras fusionar comandos, la nueva imagen “capas2” desciende a 131 MB y el tiempo baja en torno a 11 segundos. Puede influir la caché, pero la mejora es evidente en tamaño y velocidad. En Docker Desktop se aprecia claramente la diferencia entre ambas imágenes.
¿Por qué hablar de refactorización de capas en Docker?
Refactorizar no es solo para código de aplicación. En imágenes, significa reorganizar comandos para:
- Reducir capas redundantes.
- Eliminar archivos que ya no se necesitan.
- Mantener legibilidad y repetir menos pasos.
- Mejorar tiempos de build.
- Disminuir el tamaño final.
¿Esto entra en conflicto con imágenes multi stage?
No. Las imágenes con pocas capas y las imágenes multi stage persiguen el mismo objetivo: reducir el tamaño final y mejorar el rendimiento. Puedes usar uno u otro, o combinarlos, según el escenario y la necesidad:
- Multi stage: separar build y runtime para empaquetar solo lo esencial.
- Menos capas: fusionar pasos para evitar capas innecesarias.
Habilidades y conceptos reforzados en el ejercicio:
- Manejo de capas en Dockerfile y su impacto en tamaño y performance.
- Uso de comandos del sistema: apt update, apt install y su combinación en un RUN.
- Copia de artefactos con COPY hacia /app.
- Ejecución de comandos de terminal con RUN (ejemplo: "Hello World").
- Construcción con docker build -t y verificación en Docker Desktop.
- Criterio para aplicar refactorización y evaluar caché.
- Compatibilidad con enfoques multi stage.
¿Tienes otra técnica para reducir capas o medir el impacto en tu pipeline? Comparte tu experiencia y dudas en los comentarios.
