Compilar imágenes de Docker y subirlas a un registry en la nube es una pieza fundamental dentro de cualquier flujo de integración continua. Dominar este proceso en los tres principales proveedores cloud — AWS, GCP y Azure — te da flexibilidad para elegir la opción que mejor se adapte a tu proyecto, presupuesto y experiencia.
¿Cómo se configura el workflow de build en GitHub Actions?
El workflow de compilación se activa mediante dos tipos de eventos [0:18]. El primero es workflow dispatch, que permite lanzarlo manualmente y recibe un input de tipo choice con tres opciones: AWS, GCP o Azure. El segundo es issue comment, que detecta comentarios creados en un pull request.
Para controlar qué job se ejecuta, se utilizan condicionales con if [1:12]. El condicional combina dos verificaciones con un operador AND:
- Que el evento provenga de un pull request.
- Que el cuerpo del comentario contenga el texto "build AWS" (o el proveedor correspondiente).
Además, un operador OR agrega la posibilidad de que el job corra cuando se seleccione el proveedor desde el workflow dispatch. Esta lógica condicional garantiza que solo se ejecute el job del proveedor deseado.
¿Qué pasos previos son comunes a los tres proveedores?
Antes de interactuar con cualquier registry, el workflow ejecuta pasos compartidos [2:36]:
- Clonar el repositorio para tener los archivos necesarios.
- Configurar QEMU mediante el action oficial
docker/setup-qemu-action, que habilita la emulación de múltiples arquitecturas.
- Configurar Docker Buildx, la herramienta recomendada para compilar imágenes en ambientes de producción con mayor control.
- Definir el tag de la imagen: si la rama es
master, el tag será latest; en cualquier otra rama será snapshot [3:22].
Estas variables se almacenan en GITHUB_ENV, el mecanismo que GitHub Actions provee para que los pasos siguientes de un job puedan acceder a variables de entorno compartidas.
¿Cómo subir una imagen Docker al ECR de AWS?
El Elastic Container Registry (ECR) es el servicio de AWS para almacenar imágenes de Docker [4:24]. El proceso requiere:
- Usar el action
ConfigureAWSCredentials pasándole un access key ID y un secret access key almacenados como secretos del repositorio.
- Configurar la región como variable de entorno, ya que no es información sensible.
- Autenticarse en ECR con el action
Amazon ECR Login, indicando que el repositorio será público.
AWS ofrece una capa gratuita de 50 GB para repositorios públicos, frente a solo 500 MB en privados [5:28]. Esta es una ventaja considerable si buscas una opción sin costo.
Finalmente, se usa el action docker/build-push-action para compilar y subir la imagen [6:02]. Los parámetros clave son:
- El archivo
Dockerfile y el contexto (raíz del repositorio).
- Las plataformas destino: linux/amd64 y linux/arm64.
- El parámetro
push: true para confirmar la subida.
- Los tags compuestos por la ruta del registry, el alias y el nombre del repositorio.
¿Qué cambia para GCP y Azure?
Para GCP se utiliza el Artifact Registry [7:52]. La autenticación se realiza con el action google-github-actions/auth, que genera un access token. Luego, el login al registry se hace con docker/login-action, pasando como contraseña ese token generado. La ruta del registry incluye la región, el ID del proyecto y el nombre de la imagen.
Para Azure se emplea el Azure Container Registry [9:22]. Se autentica primero con azure/login usando credenciales de Azure almacenadas como secretos, y después con azure/docker-login indicando el login server, username y password del registry. La compilación mantiene la misma estructura con docker/build-push-action, ajustando únicamente la ruta del registry.
¿Cómo elegir el proveedor cloud adecuado?
No es necesario subir la imagen a los tres proveedores simultáneamente [12:18]. La recomendación práctica es:
- Si necesitas un registry gratuito y generoso, usa el ECR público de AWS con sus 50 GB sin costo.
- Si planeas desplegar containers de forma serverless, GCP ofrece una capa gratuita más beneficiosa que AWS o Azure para ese caso de uso.
- Elige el proveedor donde tengas créditos o mayor experiencia.
En la pestaña Actions de GitHub puedes ver el historial de ejecuciones [13:08]. El workflow de build puede tomar varias horas en proyectos grandes; en el ejemplo mostrado tardó tres horas y veinticinco minutos debido al tamaño del proyecto. La primera ejecución siempre es la más lenta, y las siguientes aprovechan capas de caché.
Para lanzar el workflow manualmente, basta con ir a la pestaña Actions, seleccionar el workflow de build, hacer clic en Run workflow, elegir la rama y el proveedor cloud deseado [14:12].
Si ya lograste configurar tu propio flujo de integración continua con compilación de imágenes Docker, compártelo en los comentarios y etiqueta al instructor para revisarlo en conjunto.
