Implementa una carga de trabajo de Confidential Space con MIG usando el ajuste de escala automático, la reparación automática y las actualizaciones de imágenes

1. Descripción general

Confidential Space (CS) proporciona un entorno seguro, certificado y encriptado para procesar datos sensibles. Confiar en instancias de VM independientes genera una sobrecarga operativa, ya que la organización manual carece de la escalabilidad necesaria para los servicios críticos. Sin la orquestación automatizada, realizar actualizaciones continuas sincronizadas o implementar nuevas imágenes del SO en una flota se vuelve técnicamente difícil y propenso a tiempos de inactividad.

En este codelab, aprenderás a implementar una carga de trabajo de Confidential Space en un grupo de instancias administrado (MIG). También aprenderás a habilitar la reparación automática con verificaciones de estado, el ajuste de escala automático basado en el uso de CPU y las actualizaciones progresivas para las imágenes del SO y las cargas de trabajo.

Los procesos que se muestran en este codelab deberían ayudarte a configurar tu propio Confidential Space seguro y listo para producción para implementaciones de larga duración y críticas para la misión.

Qué aprenderás

Cómo crear una plantilla de instancias especializada para Confidential Space
Cómo usar Google Compute Engine y configurar MIG y grupos de instancias
Cómo crear una regla de firewall y una verificación de estado para la reparación automática
Cómo configurar un MIG zonal con la plantilla y la verificación de estado
Cómo configurar el ajuste de escala automático para el MIG
Cómo configurar actualizaciones de imágenes de SO con un clic usando secuencias de comandos en MIGs para imágenes de cargas de trabajo y lanzamientos de imágenes de SO nuevas para Confidential Space

Requisitos

Un proyecto de Google Cloud con facturación habilitada.
Conocimiento de editores de texto, implementaciones de Docker y secuencias de comandos de Bash
La herramienta de línea de comandos de gcloud instalada y autenticada
Conocimientos básicos de Compute Engine, Confidential Space, IAM, VMs confidenciales, tecnología de contenedores, repositorios remotos, cuentas de servicio, Cloud Run y Cloud Scheduler
Una imagen de contenedor de carga de trabajo de Confidential Space ya compilada y enviada a Artifact Registry

2. Cómo funciona Confidential Space con los MIG

Usar un grupo de instancias administrado (MIG) para implementar una carga de trabajo de Confidential Space hace que una aplicación segura sea más sólida, escalable y fácil de operar.

Las necesidades operativas y de seguridad de un servicio de producción se dividen lógicamente entre los dos componentes. Confidential Space proporciona la seguridad necesaria ejecutando la carga de trabajo en un entorno altamente aislado, encriptado y certificado llamado entorno de ejecución confiable (TEE). En cambio, las MIG proporcionan las capacidades operativas esenciales necesarias para ejecutar la aplicación segura a gran escala, de manera similar a Kubernetes. Los MIG eliminan los riesgos inherentes a la ejecución de una carga de trabajo esencial en una sola VM, que puede ser lenta o susceptible a fallas. Esta combinación garantiza la protección de los datos y la confiabilidad del sistema. Esta solución garantiza la alta disponibilidad y la reparación automática porque la carga de trabajo se ejecuta en varias VMs de un grupo. Si falla una VM, el servicio sigue funcionando por completo debido al balanceo de cargas y a la presencia de las instancias restantes.

Además, los MIG utilizan verificaciones de estado configurables para supervisar constantemente el estado operativo de las VMs. Si se detecta que una instancia está en mal estado, el MIG la reemplaza automáticamente por una VM nueva en buen estado, lo que garantiza un funcionamiento continuo.

Los MIG también ofrecen una escalabilidad eficaz para los usuarios con su función de ajuste de escala automático. Esta capacidad proporciona una forma automática de administrar la capacidad sin intervención manual, lo que satisface la necesidad de agregar o quitar capacidad de forma flexible según el uso.

Por último, los MIG permiten las actualizaciones sin tiempo de inactividad a través de las actualizaciones progresivas. Un beneficio clave es la capacidad de "actualización con un solo clic" para la imagen del SO subyacente de Confidential Space o la imagen del contenedor de la aplicación (o ambas), todo sin causar tiempo de inactividad del servicio. El MIG administra este cambio reemplazando gradualmente las instancias más antiguas por otras más nuevas que ejecutan la imagen actualizada, lo que garantiza la disponibilidad constante durante toda la implementación. Ten en cuenta que es posible que tu aplicación deba ser retrocompatible para admitir este tipo de actualización gradual.

3. Configura recursos de Cloud

Antes de comenzar

Configura un proyecto de Google Cloud. Para obtener más información sobre cómo crear un proyecto de Google Cloud, consulta el codelab"Configura y navega por tu primer proyecto de Google". Puedes consultar cómo crear y administrar proyectos para obtener detalles sobre cómo recuperar el ID del proyecto y en qué se diferencia del nombre y el número del proyecto.
Habilita la facturación para tus proyectos.
En uno de los proyectos de Google de Cloud Shell, configura las variables de entorno del proyecto necesarias como se muestra a continuación.

export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>

Habilita la API de Confidential Computing y las siguientes APIs para tu proyecto.

gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com

En Cloud Shell de tu proyecto de Google Cloud, clona el repositorio de GitHub del codelab de Confidential Space y usa el siguiente comando para obtener las secuencias de comandos adecuadas que necesitas para completar este codelab.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

Cambia el directorio al directorio de secuencias de comandos del codelab del grupo de instancias.

cd confidential-space/codelabs/mig_cs_codelab/scripts

Actualiza la línea del ID del proyecto en config_env.sh para que refleje el de tu proyecto elegido.
Establece las variables preexistentes. Cómo anular los nombres de los recursos con estas variables

Puedes configurar las siguientes variables con nombres de recursos de Cloud existentes. Si se configura la variable, se usarán los recursos existentes correspondientes en la nube del proyecto. Si no se configura, el nombre del recurso de Cloud provendrá del script config_env.sh.

Ejecuta la secuencia de comandos config_env.sh para establecer los nombres de las variables restantes de este proyecto en valores basados en el ID del proyecto para los nombres de los recursos.

source config_env.sh

Agrega permisos para el proyecto. Para agregar permisos, sigue los detalles de la página web sobre cómo otorgar un rol de IAM.

Necesitarás los siguientes permisos para este proyecto

Escritor de Artifact Registry
Administrador de Cloud Scheduler
Agente de servicio de Compute
Usuario de cargas de trabajo de Confidential Computing
Escritor de registros
Desarrollador de Cloud Run
Invocador de Cloud Run

gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'

Consulta test_workload.py

Verifica el resultado de la carga de trabajo revisando el código fuente. Simplemente debería imprimir la versión actual de la carga de trabajo.
Cuando enviemos por primera vez nuestra carga de trabajo a CS y verifiquemos el resultado, deberíamos ver que se imprime "versión A".

4. Cómo configurar la carga de trabajo

Primero, deberás crear una imagen de Docker para la carga de trabajo que se usa en este codelab. La carga de trabajo es una secuencia de comandos simple que imprime la versión de la carga de trabajo que se está ejecutando. Imprimirá que la carga de trabajo se está iniciando, luego imprimirá la versión de la carga de trabajo, esperará 5 segundos y, luego, imprimirá que la carga de trabajo finalizó.

Pasos para crear una carga de trabajo

Ejecuta create_workload.sh para crear la carga de trabajo. Esta secuencia de comandos hace lo siguiente:

Crea el registro de Artifact Registry que pertenece al proyecto en el que se publicará la carga de trabajo.
Compila el código y lo empaqueta en una imagen de Docker. Consulta la configuración del Dockerfile asociado para obtener más información.
Publica la imagen de Docker en Artifact Registry, que es propiedad del proyecto.
Otorga permisos de lectura a la cuenta de servicio <nombre de tu cuenta de servicio> para el registro de artefactos <nombre del repo de registro de artefactos>.

5. Configura una plantilla de instancias y un MIG

Pasos para crear una plantilla de instancias

Primero debes crear una plantilla de instancias. Esta plantilla es el plano requerido que el grupo de instancias administrado (MIG) usará para aprovisionar y ejecutar tus cargas de trabajo en Confidential Space.

La plantilla de instancias es fundamental porque define todos los parámetros especializados:

Tipo de máquina: En este ejemplo, usamos un tipo de máquina de Confidential VM (p.ej., n2d-standard-2) que admite la tecnología de procesamiento confidencial SEV de AMD (--confidential-compute-type=SEV).
Imagen del SO de la VM: Usamos el proyecto confidential-space-images y la familia de imágenes confidential-space-debug para extraer la imagen del sistema operativo más reciente de Confidential Space.
Nota: En esta guía, usamos la imagen debug para facilitar la solución de problemas. A diferencia de la imagen de producción, la versión de depuración mantiene la VM en ejecución después de que finaliza la carga de trabajo y permite el acceso SSH para las pruebas. Para las implementaciones de producción que usan datos sensibles del mundo real, debes cambiar a la familia de imágenes de producción.
Referencia de carga de trabajo: La línea obligatoria tee-image-reference en los metadatos contiene la imagen de contenedor específica (tu carga de trabajo de aplicación) que iniciará la VM de Confidential Space.

Esta configuración garantiza que cada VM creada por el MIG sea un Confidential Space configurado correctamente y listo para ejecutar tu carga de trabajo.

Pasos para crear un grupo de instancias administrado

El siguiente paso es crear el grupo de instancias administrado (MIG) con la plantilla que acabas de definir. El MIG es esencial porque automatiza la implementación, la administración y el ajuste de escala de varias VMs idénticas.

La secuencia de comandos create_launch_mig.sh cumple tres objetivos principales:

1. Crea el MIG

Comando: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
Propósito: Este comando crea el grupo que administrará tus VMs.
--size 3: Especifica que el MIG debe crear y mantener inicialmente 3 instancias de tu carga de trabajo.
--template ${TEMPLATE_NAME}: Es fundamental que haga referencia a la plantilla de instancias creada anteriormente, lo que garantiza que las 3 instancias estén configuradas como VMs de Confidential Space que ejecutan tu contenedor de cargas de trabajo tee-image-reference específico.
--zone ${CURRENT_PROJECT_ZONE}: Especifica la ubicación de implementación de las instancias.

2. Recuperar el número de proyecto

Comando: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
Propósito: La secuencia de comandos recupera el ID numérico de tu proyecto. Este número suele ser necesario para crear roles y permisos de cuentas de servicio, en especial para los agentes de servicio administrados por Google.

3. Otorga permisos de IAM

Comando: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
Propósito: Este paso otorga el rol de agente de servicio de Compute Engine a la cuenta de servicio de tu carga de trabajo (${SERVICE_ACCOUNT}). Este permiso es importante porque permite que la cuenta de servicio actúe en nombre del servicio de Compute Engine del proyecto, lo que suele ser necesario para las funciones automatizadas de la MIG, como la administración de instancias, la configuración de redes y la interacción con otros servicios de Google Cloud.

Ejecuta create_launch_mig.sh para crear el grupo de instancias administrado.

6. Pasos para habilitar la reparación automática y el ajuste de escala automático

Cómo configurar la reparación automática

Para garantizar la alta disponibilidad, verificamos que la carga de trabajo responda. Si la aplicación se bloquea, el MIG debe reemplazar la VM. Las reglas de firewall para los rangos de IP de origen se definen en este documento.

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

Configura el escalado automático

Configuraremos el grupo para que se ajuste automáticamente entre 1 y 5 instancias para controlar los picos de tráfico.

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. Verifica la carga de trabajo y configura las actualizaciones de imágenes

Verificar carga de trabajo

Una vez que el grupo de instancias administrado (MIG) haya iniciado las VMs, debemos verificar que tu carga de trabajo de Confidential Space se ejecute correctamente.

Puedes hacerlo a través de la consola de Google Cloud o la línea de comandos.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

También puedes consultar el resultado del puerto en serie de esa instancia específica para ver el registro de tu carga de trabajo.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Cómo configurar las actualizaciones de imágenes

En un entorno de producción, tu grupo de instancias administrado (MIG) debe actualizarse con regularidad para abordar dos situaciones distintas:

Actualizaciones de la carga de trabajo: Lanzar una nueva versión del código de tu aplicación (p. ej., actualizar test_workload.py de la versión 1 a la versión 2)
Actualizaciones de infraestructura: Google lanza un parche o una actualización de seguridad para el SO subyacente de Confidential Space. Ten en cuenta que se recomienda obtener la imagen de CS más reciente al menos una vez al mes.

Debido a que configuramos nuestra plantilla de instancia con un vínculo dinámico a la imagen (.../images/family/...) y una etiqueta dinámica del contenedor (:latest), podemos controlar ambos casos con una sola operación de "reemplazo progresivo". Esto garantiza que tu flota de VMs siempre ejecute la pila más reciente sin tiempo de inactividad y sin que tengas que crear una nueva plantilla de instancias para cada cambio menor.

The Rolling Replace Script

En el directorio update_images, navega a update_images_script.sh. Esta secuencia de comandos activa un reemplazo progresivo, que destruye y recrea gradualmente cada VM del grupo.

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

Para esta secuencia de comandos, podemos usar reemplazar en lugar de reiniciar.

La opción Reiniciar simplemente reinicia la máquina. Conserva el disco del SO existente, lo que significa que no detectará parches nuevos del SO.
La opción Reemplazar borra la VM y crea una nueva a partir de la plantilla. Esto obliga al sistema a buscar la imagen de SO de Confidential Space más reciente de la familia y a extraer la imagen de contenedor "Latest" del registro.

–max-surge=1: Esto permite que el MIG cree temporalmente 1 VM adicional por encima del tamaño objetivo. Inicia una VM nueva (actualizada) y espera a que esté en buen estado antes de borrar una VM antigua (obsoleta).

–max-unavailable=0: Esto garantiza que no haya tiempo de inactividad. Indica al MIG que no se permite desconectar ninguna máquina, a menos que ya se haya reemplazado correctamente.

La secuencia de comandos de reinicio progresivo

En el directorio update_images, también hay otra secuencia de comandos update_workload_image_script.sh. Esta secuencia de comandos activa un reinicio progresivo, que es un método más rápido que se usa estrictamente para actualizar la carga de trabajo. Dado que Confidential Space extrae la imagen del contenedor del registro en cada inicio, un reinicio es suficiente para actualizar tu aplicación a la versión :latest sin alterar el host subyacente.

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

Verifica la carga de trabajo actualizada

Podemos probar la "Actualización con un solo clic" simulando el lanzamiento de una aplicación del mundo real. Modificaremos el código de la carga de trabajo, lo enviaremos a Artifact Registry, actualizaremos el MIG y verificaremos que la nueva versión se ejecute sin tiempo de inactividad.

Paso 1: Implementa una nueva versión de la carga de trabajo

Primero, debemos crear una versión "nueva" de tu aplicación.

Abre tu archivo test_workload.py local.
Cambia la sentencia de impresión de la versión de print("Workload Version A") a print("Workload Version B").
Vuelve a compilar y envía la imagen del contenedor a Artifact Registry ejecutando create_workload.sh. Ten en cuenta que enviamos a la misma etiqueta (:latest).

Paso 2: Ejecuta la actualización progresiva

Ejecuta la secuencia de comandos de actualización que creamos en la sección anterior. Esto obligará al MIG a reemplazar cada VM y extraer el nuevo hash del contenedor asociado con :latest.

# Run your update script
./update_images/update_images_script.sh

Espera a que se complete la secuencia de comandos

Paso 3: Verifica la actualización a través del puerto en serie

Una vez que se completa la actualización, verificamos que las VMs nuevas ejecuten el código actualizado.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Obtén el nombre de una instancia nueva:

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

Verifica los registros:

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Una vez que las instancias estén en ejecución, selecciona cualquier nombre de instancia del comando de gcloud anterior para ver su puerto en serie.

Resultado esperado: Deberías ver el mensaje de registro actualizado, que confirma que la implementación se realizó correctamente:

… Versión B de la carga de trabajo …

Paso 4: Verifica la configuración de la infraestructura (opcional)

También puedes verificar que tu plantilla de instancia esté configurada correctamente para extraer actualizaciones dinámicas tanto para el SO como para la carga de trabajo inspeccionando sus metadatos.

Ejecuta el siguiente comando para ver la referencia del contenedor dinámico:

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

Resultado: Deberías ver que la imagen del contenedor termina en :latest.

Implicación: Dado que la plantilla apunta a la etiqueta y no a un hash específico, cada reemplazo de acción progresiva extrae correctamente el código más reciente que insertaste en el paso 1.

(Opcional) Actualizaciones automáticas

Si bien las actualizaciones manuales son útiles para los lanzamientos de versiones principales, a menudo deseas que tu flota obtenga automáticamente los parches de seguridad más recientes o las compilaciones de implementación periódicas sin intervención humana.

Podemos automatizar el proceso de "reemplazo progresivo" si empaquetamos nuestro script de actualización en un trabajo de Cloud Run. En este codelab, lo activaremos cada 15 minutos. En un entorno de producción, debería ejecutarse con mucha menos frecuencia. Según las necesidades del usuario, es posible que lo configure semanal o mensualmente.

Paso 1: Crea un contenedor para el script del actualizador

Primero, debemos empaquetar nuestro update_images_script.sh (que contiene la lógica de reemplazo de gcloud … rolling-action) en un contenedor de Docker para que se pueda ejecutar en la nube.

Preparamos un script auxiliar que compila este contenedor y lo envía a tu registro de Artifact Registry.

Ejecuta el siguiente comando:

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

Qué hace:

Toma el archivo update_images_script.sh del directorio update_images/.
Crea una imagen de Docker que contiene el SDK de Google Cloud y tu secuencia de comandos.
Envía la imagen a ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

Paso 2: Implementa y programa el trabajo

Ahora debemos indicarle a Google Cloud que ejecute este contenedor de forma periódica. Usamos Cloud Run Jobs para ejecutar el contenedor y Cloud Scheduler para activarlo.

Ejecuta la secuencia de comandos de configuración de la programación:

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

Dentro de la secuencia de comandos: Esta secuencia de comandos realiza dos acciones fundamentales:

Crea un trabajo de Cloud Run: Define un trabajo llamado mig-updater-job que ejecuta el contenedor que acabamos de enviar.
Crea un activador de Scheduler: Configura un trabajo de Cloud Scheduler para que llame a la API de Cloud Run Jobs cada 15 minutos.

# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

Paso 3: Verifica la automatización

No tienes que esperar 15 minutos para probarlo. Puedes forzar al programador a que se ejecute de inmediato para verificar la canalización.

Forzar la ejecución del trabajo:

gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}

Verifica la ejecución: Ve a la consola de Cloud Run > Trabajos. Deberías ver que se inicia una nueva ejecución.
Verifica el MIG: Ejecuta gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. Verás que las instancias ingresan al estado RECREATING a medida que el trabajo activa la actualización continua.

¿Por qué 15 minutos? Para este codelab, establecimos el programa en */15 * * * * para que puedas ver los resultados rápidamente. En un entorno de producción real, es probable que cambies esta configuración para que se ejecute a diario (p. ej., 0 3 * * * para las 3 a.m.) o semanalmente.

8. Limpieza

La secuencia de comandos de limpieza cleanup.sh se puede usar para limpiar los recursos que creamos como parte de este codelab. Como parte de esta limpieza, se borrarán los siguientes recursos:

El grupo de instancias administrado (${CURRENT_MIG_NAME}) y sus VMs subyacentes.
Es la plantilla de instancias (${TEMPLATE_NAME}).
La verificación de estado y las reglas de firewall (${HEALTH_CHECK_NAME}).
Repositorio de Artifact Registry (${REPOSITORY}).
La cuenta de servicio (si creaste una dedicada para este lab)

Si terminaste de explorar, considera borrar tu proyecto. Para ello, sigue estas instrucciones: Cómo cerrar (borrar) proyectos.

Felicitaciones

¡Felicitaciones! Completaste el codelab correctamente.

Aprendiste a escalar de forma segura las cargas de trabajo de Confidential Space con grupos de instancias administrados (MIG). Configuraste correctamente la reparación automática para recuperarte de las fallas, el ajuste de escala automático para controlar los aumentos repentinos de tráfico y realizaste actualizaciones sin tiempo de inactividad para la imagen del SO de Confidential Space y el contenedor de carga de trabajo.

¿Qué sigue?

Consulta otros codelabs de Confidential Space:

Protege los modelos de AA y la propiedad intelectual con Confidential Space
Cómo realizar transacciones de recursos digitales con computación de varias partes y Confidential Space
Analiza datos confidenciales con Confidential Space
Cómo usar Confidential Space con recursos protegidos que no se almacenan con un proveedor de servicios en la nube