BuildKit y Artifact Registry solucionan el cacheo de Docker en Cloud Build
La documentación oficial de Google sigue recomendando métodos obsoletos, pero una configuración de tres líneas con BuildKit elimina la reconstrucción de capas innecesaria.
Mazlum Tosun, ingeniero de plataforma y Google Developer Expert, ha detallado cómo CONFIGURAR UN CACHEO PERSISTENTE DE IMÁGENES DE CONTENEDOR EN GOOGLE CLOUD BUILD. El problema central es que la herramienta de CI/CD de Google no conserva el caché local entre ejecuciones, lo que obliga a cada build a redesplegar todas las dependencias desde cero si no se configura específicamente una estrategia externa.
La limitación del modelo efímero
Cloud Build ejecuta cada tarea en una máquina virtual efímera que se destruye tras finalizar la construcción. A diferencia de un host local, donde el demonio de Docker mantiene las capas en disco, aquí el estado se pierde. La guía oficial de Google apunta tradicionalmente a utilizar --cache-from con la imagen anterior o a recurrir a Kaniko. Sin embargo, Kaniko fue archivado por Google en junio de 2025 y marcado como sin mantenimiento, dejando a los usuarios con opciones limitadas y poco documentadas para gestionar las capas más costosas de los Dockerfiles multiestadio.
La solución propuesta por Tosun consiste en utilizar BuildKit en modo max para el caché de registro, almacenando las capas directamente en Artifact Registry. Este enfoque permite que múltiples pipelines compartan el mismo caché de dependencias. Para ilustrarlo, el autor presenta un ejemplo con una aplicación FastAPI y el gestor de paquetes uv, donde se demuestra que, siempre que el archivo de bloqueo (uv.lock) no cambie, la capa de instalación de dependencias se reutiliza instantáneamente en vez de tardar entre 30 y 60 segundos en descargarse y compilarse en cada push.
El repositorio con el código completo está disponible en GitHub. La clave operativa reside en la estructura del Dockerfile: las instrucciones que copian archivos estables deben ir primeras para que el caché no se invalide al modificar el código fuente. Esta técnica reduce no solo el tiempo de construcción, sino también el consumo de recursos de cómputo y la huella de carbono asociada a la infraestructura.
Para los equipos que operan en GCP, esto corrige una suposición común: que el cacheo de Docker simplemente "no funciona" en Cloud Build. La realidad es que requiere una configuración explícita fuera del alcance de la interface por defecto. Con la descontinuación de Kaniko, adoptar BuildKit con caché externo se convierte en la vía estándar para optimizar pipelines de contenedores en la nube.
