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.
