Optimiza tus tiempos de creación de imágenes con el Docker cache: entiende cómo reutiliza capas, identifica cuándo aparece la línea cached y decide si conviene evitar el caché en pasos clave como apt-get update y apt-get upgrade. Con un simple cambio en el HTML y controlando el caché, el tiempo bajó de 38.8 s a 1.4 s, mientras que el paso de actualización pasó de 32.4 s a 0 s cuando quedó cacheado.
¿Qué es Docker cache y por qué acelera tus builds?
El Docker cache es una capa inteligente que compara cada instrucción del Dockerfile y reutiliza resultados si nada cambió. Así, al reconstruir una imagen con los mismos recursos, Docker evita descargar o compilar de nuevo y marca los pasos con la palabra cached. Esta reutilización explica tiempos dramáticamente menores en builds subsecuentes: con un pequeño cambio de contenido, la reconstrucción tomó 1.4 s frente a los 38.8 s iniciales.
¿Cómo se evidencia el impacto en tiempos?
- Primera compilación con
apt-get update y upgrade: 38.8 s.
- Paso
apt-get update/upgrade sin caché: 32.4 s en la primera corrida.
- Segunda compilación tras editar el HTML: 1.4 s con pasos marcados como cached.
- La línea cached confirma qué capas fueron reutilizadas.
¿Qué patrones debes observar en la salida de docker build?
- La aparición de cached en pasos repetidos.
- Reducciones de tiempo en pasos intensivos como
apt-get update/upgrade.
- Repetición del proceso cuando se fuerza a no usar caché.
¿Cómo replicar el ejemplo con NGINX y un Dockerfile?
Se partió de una imagen base NGINX para un sitio estático básico. Se actualizan repositorios, se crea un HTML con “Mi página de inicio personalizada” y se coloca en la ubicación del servidor. Luego se reconstruye cambiando el texto a “segunda versión” para ver el efecto del caché.
¿Qué instrucciones clave aparecen en el Dockerfile?
FROM nginx
# actualizar repositorios y paquetes
RUN apt-get update && apt-get upgrade -y
# crear HTML y colocarlo en la ubicación de NGINX
# (coloca el archivo en la ruta del servidor NGINX)
# ejemplo de contenido mínimo
# "Mi página de inicio personalizada"
# forzar variación para el caché en este paso específico
ARG cache_boost=1
RUN apt-get update && apt-get upgrade -y
FROM nginx: define la base del servidor web.RUN apt-get update && apt-get upgrade: actualiza repositorios y paquetes.ARG cache_boost=1: introduce un argumento para controlar el caché en un paso.
¿Qué comandos en terminal se usan para compilar?
# dentro del folder de trabajo (por ejemplo, Cache)
ls
cd Cache
# compilar con tag y contexto actual
docker build -t testing-cache .
# reconstruir para ver líneas cached cuando no cambian pasos
docker build -t testing-cache .
- Uso de terminal para ubicarse:
ls, cd.
- Reconstrucciones rápidas cuando el contenido no cambia.
¿Cómo controlar el caché: ARG selectivo o flag global?
Hay dos formas de decidir si se usa el caché: insertar un ARG para afectar un paso específico o desactivar el caché para todo el proceso con una flag global.
¿Cuándo conviene un ARG para pasos específicos?
- Cuando quieres que
apt-get update/upgrade se ejecute siempre.
- Cuando una parte de la imagen debe actualizarse de forma constante.
- Cuando otras capas (como archivos estáticos) pueden mantenerse cacheadas.
# ejemplo minimalista para afectar el caché de un paso
ARG cache_boost=1
RUN apt-get update && apt-get upgrade -y
- Con
ARG, se evita que ese paso quede almacenado y se repite en cada build.
¿Cuándo usar --no-cache para todo el build?
- Cuando necesitas una reconstrucción completa sin reutilizar ninguna capa.
- Cuando hay dudas sobre el estado de capas previas y prefieres empezar desde cero.
# compilar sin usar caché en ningún paso
docker build --no-cache -t testing-cache .
- La imagen base sigue almacenada, pero todos los pasos del build se vuelven a ejecutar.
¿Cómo decidir entre caché o reconstrucción total?
- Si tus archivos cambian poco: aprovecha caché para ahorrar tiempo.
- Si requieres datos siempre frescos: fuerza sin caché en pasos clave o en todo el build.
- Cada escenario es distinto: selecciona capas a cachear según tu necesidad.
¿Te quedó alguna duda sobre cómo leer la salida de docker build o cuándo aplicar --no-cache versus ARG? Comparte tus preguntas y cuéntanos tu caso de uso.
