Cómo reducir capas en Docker

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:00

Cómo reducir capas en Docker

Curso de Docker Avanzado

Clase 11 de 34

Clase 11 / 34

Recursos

Reducir capas en Docker es una de las prácticas más efectivas para optimizar imágenes y bajar su tamaño final. Si trabajas con contenedores y quieres imágenes más ligeras y rápidas en la nube, entender cómo se generan y combinan las capas dentro de un Dockerfile te va a ahorrar megas y segundos de build.

Lo interesante es que esta optimización no requiere que pienses demasiado en ella. Con la práctica, vas a reducir capas de forma natural, casi por intuición.

¿Qué es una capa en Docker y cómo se genera?

Cada instrucción que escribes en un Dockerfile genera una capa nueva dentro de la imagen. Eso significa que entre más comandos sueltos tengas, más pesada y lenta será tu imagen final.

Para verlo claro, imagina un Dockerfile sencillo con cinco instrucciones [00:50]:

Capa 1: imagen base con FROM ubuntu:latest.
Capa 2: actualización con apt update.
Capa 3: instalación de curl, una herramienta para hacer solicitudes HTTP.
Capa 4: copia de archivos al directorio /app.
Capa 5: ejecución de un comando tipo Hello world.

Cada uno de esos pasos suma peso. Y aquí viene lo interesante: muchos de ellos se pueden fusionar.

¿Qué es una capa en Docker? Es el resultado de cada instrucción dentro de un Dockerfile. Cada comando como FROM, RUN o COPY crea una capa nueva que se apila sobre la anterior para formar la imagen final.

¿Cómo reduzco el número de capas en mi Dockerfile?

La clave está en agrupar comandos relacionados dentro de una sola instrucción RUN. En lugar de separar apt-get update y apt-get install en líneas distintas, los unes con && y, de paso, eliminas archivos de configuración que ya no necesitas.

En el ejemplo de la clase, la primera versión de la imagen capas pesó 204 MB después de 26 segundos de build [02:30]. Al fusionar los comandos en una sola capa, la nueva imagen capas2 bajó a 131 MB y el tiempo se redujo en casi 11 segundos [03:25]. Eso es poco más de la mitad del peso original, partiendo de la misma imagen base.

Este proceso es lo que en programación se llama refactorización de código: reescribir lo que ya funciona para que sea más limpio y eficiente. Aplicado a Docker, refactorizar capas significa que múltiples pasos se condensen en menos instrucciones, ahorrando espacio sin cambiar la funcionalidad.

¿Qué comandos conviene fusionar dentro de un RUN?

Los candidatos naturales son los que pertenecen al mismo flujo lógico:

Actualización del sistema con apt-get update.
Instalación de paquetes como curl o cualquier dependencia.
Limpieza de archivos temporales y cachés que ya no usarás.

Al combinarlos, no solo reduces capas: también evitas que archivos basura queden almacenados en capas intermedias.

¿Reducir capas reemplaza a las imágenes multi-stage?

No. Son estrategias complementarias, no excluyentes. Tanto las imágenes multi-stage como la reducción de capas buscan lo mismo: que tu imagen final pese menos y sea más eficiente. Pero atacan el problema desde ángulos distintos [04:30].

¿Cuándo uso multi-stage y cuándo reduzco capas? Usa multi-stage cuando necesitas separar el entorno de compilación del de ejecución. Reduce capas cuando quieres optimizar un Dockerfile simple agrupando comandos relacionados. Puedes combinar ambas técnicas en un mismo proyecto.

La decisión depende del escenario. Si tu proyecto compila código en un lenguaje como Go o Java, multi-stage te conviene. Si tu Dockerfile solo instala dependencias y copia archivos, fusionar capas es suficiente.

Buenas prácticas para mantener imágenes ligeras

Más allá del comando RUN, hay hábitos que ayudan a que tus imágenes nazcan optimizadas:

Elimina archivos de configuración y cachés dentro de la misma capa donde los generas.
Copia solo los archivos que tu aplicación realmente necesita, no todo el directorio.
Verifica el peso de tus imágenes en Docker Desktop después de cada build para comparar resultados.
Limpia tu terminal antes de comparar tiempos de build solo si lo necesitas; mantenerlos visibles ayuda a medir mejoras.

Al aplicar estas prácticas vas a notar que tus imágenes se vuelven más rápidas de construir, más ligeras de transferir y más eficientes al desplegarse.

¿Has medido cuánto pesan tus imágenes de Docker actuales? Cuéntame en los comentarios qué técnicas usas para optimizarlas.

Ulises Serrano Pérez

Hace 2 años

Considero importante mencionar que el orden de cada una de las instrucciones son importantes, por ejemplo si tenemos lo siguiente como en el video.

FROM ubuntu:latest

RUN apt-get update && \
  apt-get install-y curl \
  rm -rf /var/lib/apt/lists/*

COPY . /app

CMD ["echo", "Hello, World"]
```La primera vez que se ejecute esto se va a guardar en cache, como ya lo hemos visto si se volviera a ejecutar sería mucho mas rápido. Pero, ¿qué pasa si agregamos lo siguiente?```js
FROM ubuntu:latest

CMD ["echo", "Linea nueva"]

RUN apt-get update && \
  apt-get install-y curl \
  rm -rf /var/lib/apt/lists/*

COPY . /app

CMD ["echo", "Hello, World"]
```Lo nuevo como es la segunda instrucción, invalidaría el cache a partir de ese punto por lo tanto lo demás se volvería a ejecutar sin cache. Si moviéramos esa instrucción al final mantendríamos nuestro cache intacto y solo agregaríamos una instrucción mas. De ahí la importancia de saber jugar con el cache.

Raul Andres Daza Liñan

Hace un año

Es cierto, de eso me di cuenta en la clase sobre caché cuando averigüé más. ARG CACHENUST=1 no resetea la caché como tal, sino que más bien cambia la capa y eso obliga a reconstruir esa capa. Las siguientes capas también se reconstruyen ya que la forma en la que docker sabe si una capa cambió o no es con un hash que se genera por cada capa. Las capas usan el hash de la capa anterior, así que si una capa cambia, el hash de esta y de todas las capas siguientes lo hacen, obligando a que se reconstruyan todas las capas siguientes, aunque estas no hayan cambiado.

Optimización Avanzada en Docker

Optimización avanzada de Docker para cloud native

Docker productivo vs comandos básicos

Multi-stage builds en Docker con ASP.NET

Cómo escanear vulnerabilidades en imágenes Docker

Imágenes distroless: de 840 MB a 52 MB

Imágenes Docker para múltiples arquitecturas

Cómo funciona el caché en Docker builds

De 1.19 GB a 126 MB con Alpine

Qué es el build context en Docker

Docker Hub para compartir imágenes en la nube

Buenas Prácticas en Docker

Cómo reducir capas en Docker

Cómo usar .dockerignore para imágenes más pequeñas

Limpia Docker y recupera gigas con prune

Creando usuarios en Docker sin privilegios root

6 prácticas Docker para imágenes listas para producción

Instalación y Configuración en Entornos Multiplataforma

Publica imágenes Docker en Azure Container Registry

Azure Container Registry hacia Container App

Redes Avanzadas y Balanceo de Carga

Redes en Docker: los 5 modelos explicados

Cómo funcionan los puertos en Docker

Balanceo de carga con NGINX en Docker

Automatización de CI/CD

Optimizar Dockerfile con comandos RUN y scripts

Automatiza Docker con GitHub Actions

Pruebas automáticas de Docker con GitHub Actions

Despliegue automático en Azure con GitHub Actions

Orquestación

Docker Compose: balanceo de cargas automatizado

Estructura y plantilla de Docker Compose YAML

Volúmenes Docker: bind vs nombrados

docker-compose down vs Control C en apagado

Docker Swarm para principiantes paso a paso

Despliegue Docker Swarm con réplicas de Nginx

Costos ocultos de contenedores en la nube

Cómo habilitar Kubernetes en Docker Desktop

Planes y límites de Docker Hub en producción

Develop

Dev containers en VS Code con Docker

Cómo reducir capas en Docker