Cómo funciona el caché en Docker builds

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:009:34

Cómo funciona el caché en Docker builds

Curso de Docker Avanzado

Clase 7 de 34

Clase 7 / 34

Recursos

Cuando construyes una imagen en Docker por primera vez, el proceso puede tardar varios segundos o incluso minutos. Pero al recrearla, el tiempo baja drásticamente: de 38 segundos a menos de 2. Aquí entra Docker Cache, el mecanismo silencioso que decide qué pasos reutilizar y cuáles ejecutar de nuevo para que tus builds sean cada vez más veloces.

¿Cómo funciona Docker Cache al construir una imagen?

Docker guarda el resultado de cada instrucción del Dockerfile en capas. Si una capa no cambió desde la última build, Docker la reutiliza en lugar de ejecutarla otra vez. Eso explica por qué la primera compilación es lenta y las siguientes son casi instantáneas.

En el ejercicio práctico [01:30] se parte de un Dockerfile con la imagen base de nginx, una actualización de repositorios con apt-get update y apt-get upgrade, y la creación de un archivo HTML simple llamado Mi página de inicio personalizada.

dockerfile FROM nginx RUN apt-get update && apt-get upgrade -y RUN echo "Mi página de inicio personalizada" > /usr/share/nginx/html/index.html

La primera build con docker build -t testing-cache . tardó 38.8 segundos, en su mayoría por el apt-get update && upgrade que consumió 32.4 segundos.

¿Qué es Docker Cache? Es el sistema interno de Docker que almacena el resultado de cada capa de tu imagen para reutilizarlo en builds posteriores y evitar repetir pasos costosos.

¿Por qué la segunda build es tan rápida?

Al modificar solo el contenido del HTML a segunda versión y volver a ejecutar el mismo comando, el tiempo bajó a 1.4 segundos. Casi 37 segundos de diferencia.

En la salida aparece la palabra CACHED junto a los pasos reutilizados. El apt-get update && upgrade que antes tardaba 32.4 segundos ahora tomó cero. Docker detectó que esa instrucción no había cambiado y reutilizó la capa existente.

La regla es simple: Docker invalida la caché desde la primera línea que cambia hacia abajo. Por eso conviene poner las instrucciones más estables al principio del Dockerfile y las que cambian con frecuencia al final.

¿Cómo forzar a Docker a no usar la caché en un paso específico?

A veces no quieres que un paso quede congelado en caché, por ejemplo cuando necesitas que apt-get update se ejecute siempre para traer parches nuevos. La técnica que se muestra [05:10] es agregar un argumento llamado cache-bust justo antes de la instrucción que quieres invalidar.

dockerfile ARG CACHE_BUST=1 RUN apt-get update && apt-get upgrade -y

Cuando cambias el valor de CACHE_BUST al construir, Docker considera ese paso distinto y lo vuelve a ejecutar, mientras conserva la caché de los pasos previos. Así eres selectivo: mantienes lo que sí te conviene reutilizar y refrescas solo lo que necesita actualizarse.

¿Cuándo conviene usar cache-bust? Cuando un paso depende de información que cambia fuera del Dockerfile, como repositorios remotos, dependencias o parches de seguridad que deben quedar siempre al día.

¿Y si quiero ignorar la caché en toda la build?

Para eso existe la bandera --no-cache directamente en el comando:

bash docker build --no-cache -t testing-cache .

Con esta opción, Docker recompila absolutamente todos los pasos desde cero. La imagen base sigue almacenada localmente porque ya fue descargada antes, pero las instrucciones del Dockerfile se ejecutan de nuevo una por una. El tiempo vuelve a subir a los 30 y tantos segundos del primer build.

¿Cuándo usar la caché y cuándo evitarla?

No hay una respuesta única. Depende del tipo de archivos y del comportamiento que esperas de tu imagen.

Usa la caché cuando trabajas con dependencias estables, librerías que no cambian o assets estáticos. Te ahorra minutos en cada build.
Evita la caché con --no-cache cuando necesitas garantizar que todo se construya desde cero, por ejemplo antes de un despliegue a producción.
Usa cache-bust con ARG cuando solo un paso intermedio debe refrescarse, como actualizaciones del sistema o descargas de paquetes que deben estar siempre al día.

La decisión final depende de tu escenario. Si tus archivos cambian seguido, la caché puede convertirse en un pequeño problema porque sirve versiones viejas. Si son estáticos y predecibles, te ahorra una cantidad enorme de tiempo en cada compilación.

¿Qué estrategia de caché estás usando en tus Dockerfiles? Cuéntame en los comentarios cómo organizas el orden de tus instrucciones para sacarle el máximo provecho.

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 funciona el caché en Docker builds