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.
RUN echo '<html><body>Mi página de inicio personalizada en su segunda versión</body></html>' > /usr/share/nginx/html/index.html
Cached bust es un argumento que se utiliza en Docker para evitar que ciertos pasos de la construcción de una imagen usen el caché. Al establecer ARG CACHEBUST=1 en tu Dockerfile o pasar --build-arg CACHEBUST=1 en el comando docker build, forzarás a Docker a ejecutar siempre ese paso, ignorando lo que se haya almacenado previamente en el caché. Esto es útil cuando necesitas asegurarte de que, por ejemplo, se realice una actualización de dependencias cada vez que construyes la imagen, en lugar de utilizar una versión almacenada que podría estar desactualizada.
"Cached bust" (o --no-cache) fuerza un paso o toda la construcción de Docker a ejecutarse sin usar el caché. El ARG cachebust=1 en el Dockerfile indica que ese paso no use caché; el 1 es un valor para activarlo.
Casos de uso:
Asegurar que pasos como apt get update siempre busquen las últimas actualizaciones.
Obtener una construcción completamente nueva para depuración o despliegues críticos.
¿Es posible, en un Dockerfile con múltiples etapas, mantener el caché en algunas etapas mientras que en otras se fuerce la reconstrucción sin usar caché?
Sí, con el argumento de CACHEBUST, lo puedes cambiar el cualquier etapa de la imagen
utilizar --no-cache hace que se sobre escriba el cache que ya habia generado la imagen anteriormente?
Utilizar --no-cache evita usar el caché en el proceso completo, cada vez que crees la imagen este proceso se repetirá desde cero.
Si por ejemplo yo subo una imagen a un registry y luego la descargo en otro lugar donde esta el mismo dockerfile con la misma informacion y hago el build eso usa cache ?
Según entiendo, No, el caché de Docker es local a la máquina donde se ejecuta el docker build. Si construyes en otro lugar, esa nueva máquina no tendrá el caché de la anterior y el proceso se ejecutará desde cero.
el cache es local
La Mtoria de Aplicaciones en DevOps requieren tener habilitado el Cache: auto ; en sus proyectos de Contenedores en imagenes staticas.
a que te refieres? me da curiosidad lo que mencionar pero no llego a entender.
¿Si quitas el caché de tu Dockerfile, este va a ser más eficiente y ocupar menos espacio?
No, lo que dices es que con el cache tiene guardado en memoria informacion de todo lo creado antes y este trabaja mas rapido al momento de crear, si lo eliminar entonces tardara mas tiempo ya que debe de realizar todo el proceso desde 0 cada vez.
