Automatizar el ciclo de vida de una aplicación es una de las prácticas más valiosas en el desarrollo moderno. Aquí se muestra, paso a paso, cómo conectar un repositorio de código con Google Cloud Build, generar imágenes de contenedor, almacenarlas en Google Cloud Container Registry y desplegarlas en Google Cloud Run, construyendo un flujo real de Continuous Integration y Continuous Delivery.
¿Cómo se conecta el código fuente con Google Cloud Source Repository?
El punto de partida es tener el proyecto local vinculado a Google Cloud Source Repository [01:28]. Desde la consola de Google Cloud se pueden ver los repositorios existentes, crear uno nuevo o conectar uno externo proveniente de GitHub o Bitbucket, funcionando como un espejo (mirror) del repositorio original [02:05].
Para autenticarse y gestionar los repositorios existen tres vías:
- Conexión vía SSH.
- Uso de Google Cloud SDK.
- Configuración manual.
Una vez conectado, cualquier commit y push que se realice de forma local queda reflejado en el repositorio remoto de Google Cloud, lo que abre la puerta a la automatización.
¿Qué papel juega Google Cloud Build en la automatización?
Cuando se ingresa a Google Cloud Build se encuentra un historial completo de las construcciones anteriores [03:05]. El servicio registra cuándo se ejecutó cada tarea, cuánto duró y qué artefactos generó. La pieza clave para disparar estas construcciones son los triggers [03:30].
¿Cómo se configura un trigger?
Crear un trigger implica definir tres elementos principales [03:42]:
- Repositorio objetivo: el repositorio que Cloud Build va a vigilar.
- Evento disparador: puede ser un push a cualquier branch, a ramas específicas mediante expresiones regulares o a tags concretas.
- Acción a ejecutar: seguir las instrucciones de un Dockerfile o de un archivo de configuración cloudbuild.yaml.
El archivo cloudbuild.yaml se recomienda mantenerlo dentro del propio repositorio de código [04:42]. En su interior se definen steps que Cloud Build ejecuta secuencialmente. Cada step utiliza una imagen de contenedor para realizar una tarea; por ejemplo, docker build construye la imagen del proyecto a partir del Dockerfile y luego la empuja hacia Google Container Registry [05:05].
¿Cómo se verifica que el trigger funcionó?
Tras hacer un nuevo commit y push, el trigger detecta el cambio y activa automáticamente la construcción [05:40]. En la consola de Cloud Build se observa el progreso en tiempo real: las capas del contenedor que se construyen, el momento en que se hace el push al registro y la marca verde que confirma el éxito de la operación [06:10].
¿Cómo se despliega la imagen en Cloud Run desde Container Registry?
Google Container Registry almacena todas las imágenes generadas y ofrece un escaneo de vulnerabilidades integrado [06:40]. En el ejemplo mostrado se detectaron doscientas veintidós vulnerabilidades: ninguna crítica ni alta, veinte de prioridad media y el resto menores. Cada vulnerabilidad enlaza a documentación externa que explica el riesgo y las posibles soluciones [07:00].
Desde Container Registry, compatible con Docker, se puede hacer pull de cualquier imagen o desplegarla directamente hacia servicios como Cloud Run [07:30].
Para el despliegue en Cloud Run se configuran estos parámetros [07:42]:
- Seleccionar la imagen más reciente.
- Elegir la versión administrada o la versión para Anthos.
- Definir el nombre del servicio.
- Agregar variables de entorno necesarias, como la referencia a un bucket de almacenamiento.
- Permitir acceso sin autenticación si corresponde.
Tras unos segundos, el servicio queda activo con una URL pública (endpoint) desde la cual se accede a la aplicación ya actualizada con los últimos cambios del código [08:30].
El flujo completo queda así: los ajustes en el código se reflejan en el repositorio, Cloud Build construye el artefacto mediante el trigger, la imagen se almacena en Container Registry y desde ahí se despliega en Cloud Run. En el ejemplo se ejecutó un paso manual para el despliegue, pero es posible configurar un esquema completamente automático que cubra desde el push hasta la puesta en producción [09:00].
Si ya cuentas con proyectos en Google Cloud, probar este flujo con tus propios repositorios es la mejor forma de interiorizar cada paso. ¿Qué parte del proceso te resultó más interesante o cuál te genera más dudas? Compártelo en los comentarios.
