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)lscd Cache
# compilar con tag y contexto actualdocker build -t testing-cache .# reconstruir para ver líneas cached cuando no cambian pasosdocker 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 pasodocker 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.
