Construir imágenes de contenedores es una habilidad fundamental para cualquier profesional que trabaje con aplicaciones en la nube. En esta práctica se recorren cinco pasos concretos para crear, almacenar y publicar imágenes utilizando los servicios de cómputo de Google Cloud, desde la preparación de archivos fuente hasta la verificación del resultado final en Artifact Registry.
¿Cómo preparar los archivos fuente para una imagen de contenedor?
Todo comienza dentro de Cloud Shell [01:30], la línea de comandos virtual que Google Cloud ofrece directamente en el navegador, sin costo y sin necesidad de instalar nada en tu máquina local. Junto al terminal, también se dispone de un editor de texto enriquecido basado en el navegador, ideal para crear y modificar archivos.
Los archivos necesarios son dos:
- quickstart.sh: un script sencillo que funciona como programa de demostración, similar a un "hola mundo".
- Dockerfile: el archivo de configuración que define cómo se construirá la imagen del contenedor.
El Dockerfile contiene tres líneas esenciales [03:50]:
- La imagen base del sistema operativo que se utilizará.
- Los archivos que se copiarán dentro de la imagen.
- El punto de entrada o comando de ejecución del contenedor.
Una vez creados ambos archivos dentro de una carpeta de trabajo, se otorga permiso de ejecución al script con un comando estándar de terminal.
¿Qué es Artifact Registry y cómo crear un repositorio de imágenes?
Antes de construir la imagen, es necesario definir dónde se almacenará. Para eso existe Artifact Registry [04:30], un servicio de Google Cloud diseñado específicamente para gestionar repositorios de imágenes de contenedores.
La creación del repositorio se realiza desde la línea de comandos con gcloud:
bash
gcloud artifacts repositories create quickstart-docker-repo
--repository-format=docker
--location=us-central1
Para verificar que el repositorio fue creado correctamente, se ejecuta:
bash
gcloud artifacts repositories list
El resultado muestra el repositorio recién creado bajo el proyecto activo. Conocer el nombre del proyecto es importante porque garantiza que las imágenes se publiquen en el repositorio correcto.
¿Cuáles son los dos métodos para construir imágenes de contenedores?
Existen dos caminos para crear imágenes y cada uno tiene ventajas particulares.
¿Cómo construir una imagen usando Dockerfile?
El primer método utiliza el comando gcloud builds submit [05:50] junto con el Dockerfile. Se especifica el repositorio destino, el nombre de la imagen y una etiqueta o tag:
bash
gcloud builds submit --tag us-central1-docker.pkg.dev/PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1
Este comando ejecuta cada paso definido en el Dockerfile, construye la imagen y la sube al repositorio en la nube. Al finalizar, se puede verificar el resultado directamente en la consola de Artifact Registry, donde aparecerá la imagen quickstart_image con el tag número uno [07:00].
¿Cómo construir una imagen con un archivo de build config en YAML?
El segundo método reemplaza al Dockerfile con un archivo llamado cloudbuild.yaml [08:00]. Su estructura define los pasos de construcción en formato YAML, de forma análoga al Dockerfile, pero con una diferencia clave: no solo crea la imagen, sino que también indica directamente hacia qué repositorio debe publicarse.
yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1', '.']
images:
- 'us-central1-docker.pkg.dev/PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1'
Para ejecutar la construcción con este archivo se usa:
bash
gcloud builds submit --config cloudbuild.yaml
El servicio Cloud Build [09:30] registra cada compilación realizada, permitiendo revisar el historial de construcciones. Al finalizar, la imagen aparece en Artifact Registry junto a la creada previamente con Dockerfile.
¿Cuál es la diferencia principal entre ambos métodos?
- Dockerfile: crea la imagen del contenedor, pero la publicación al repositorio depende del comando que se ejecute.
- cloudbuild.yaml: integra la creación y la publicación en un solo archivo, lo que resulta más eficiente al definir explícitamente el destino de la imagen.
Ambos métodos son válidos y complementarios. Dominar los dos te da flexibilidad para adaptarte a distintos flujos de trabajo en entornos de desarrollo, despliegue y monitoreo de aplicaciones en la nube.
¿Ya probaste ambos métodos en tu proyecto? Comparte en los comentarios cuál prefieres y por qué.
