Déployer une charge de travail Confidential Space avec des MIG à l'aide de l'autoscaling, de l'autoréparation et des mises à jour d'images

1. Présentation

Confidential Space (CS) fournit un environnement sécurisé, attesté et chiffré pour traiter les données sensibles. S'appuyer sur des instances de VM autonomes crée une surcharge opérationnelle, car l'orchestration manuelle ne dispose pas de l'évolutivité requise pour les services critiques. Sans orchestration automatisée, il devient techniquement difficile d'effectuer des mises à jour continues synchronisées ou de déployer de nouvelles images d'OS sur un parc, ce qui peut entraîner des temps d'arrêt.

Dans cet atelier de programmation, vous allez apprendre à déployer une charge de travail Confidential Space sur un groupe d'instances géré (MIG). Vous apprendrez également à activer l'autoréparation à l'aide de vérifications de l'état, l'autoscaling en fonction de l'utilisation du processeur et les mises à jour continues pour les images OS et les charges de travail.

Les processus présentés dans cet atelier de programmation devraient vous aider à configurer votre propre espace confidentiel sécurisé et prêt pour la production pour les déploiements de longue durée et critiques.

Points abordés

  • Découvrez comment créer un modèle d'instance spécialisé pour Confidential Space.
  • Utiliser Google Compute Engine et configurer des MIG et des groupes d'instances
  • Créer une règle de pare-feu et une vérification de l'état pour l'autoréparation
  • Configurer un MIG zonal avec le modèle et la vérification de l'état
  • Configurer l'autoscaling pour le MIG
  • Configurer les mises à jour de l'image de l'OS en un seul clic à l'aide de scripts sur les MIG pour les images de charge de travail et les nouvelles versions d'image de l'OS pour Confidential Space

Prérequis

  • Un projet Google Cloud avec facturation activée.
  • Connaissance des éditeurs de texte, des déploiements Docker et des scripts Bash
  • L'outil de ligne de commande gcloud est installé et authentifié.
  • Connaissances de base de Compute Engine, Confidential Space, IAM, Confidential VM, de la technologie de conteneur, des dépôts distants, des comptes de service, de Cloud Run et de Cloud Scheduler
  • Une image de conteneur de charge de travail Confidential Space déjà créée et transférée vers Artifact Registry.

2. Fonctionnement de Confidential Space avec les MIG

L'utilisation d'un groupe d'instances géré (MIG) pour déployer une charge de travail Confidential Space permet de rendre une application sécurisée plus robuste, plus évolutive et plus facile à utiliser.

Les besoins opérationnels et de sécurité d'un service de production sont logiquement répartis entre les deux composants. Confidential Space fournit la sécurité nécessaire en exécutant la charge de travail dans un environnement hautement isolé, chiffré et attesté appelé environnement d'exécution sécurisé (TEE). En revanche, les MIG fournissent les capacités opérationnelles essentielles requises pour exécuter l'application sécurisée à grande échelle, comme Kubernetes. Les MIG éliminent les risques inhérents à l'exécution d'une charge de travail critique sur une seule VM, qui peut être lente ou sujette à des défaillances. Cette combinaison garantit à la fois la protection des données et la fiabilité du système. Cette solution garantit une haute disponibilité et une autoréparation, car la charge de travail s'exécute sur plusieurs VM d'un pool. Si une VM plante, le service reste entièrement fonctionnel grâce à l'équilibrage de charge et à la présence des instances restantes.

De plus, les MIG utilisent des vérifications d'état configurables pour surveiller en permanence l'état opérationnel des VM. Si une instance est jugée non opérationnelle, le MIG la remplace automatiquement par une nouvelle VM opérationnelle, garantissant ainsi un fonctionnement continu.

Les MIG offrent également une évolutivité efficace aux utilisateurs grâce à leur fonctionnalité d'autoscaling. Cette fonctionnalité permet de gérer automatiquement la capacité sans intervention manuelle, ce qui répond à la nécessité d'ajouter ou de supprimer de la capacité de manière flexible en fonction de l'utilisation.

Enfin, les MIG permettent d'effectuer des mises à jour sans temps d'arrêt grâce aux mises à jour progressives. L'un des principaux avantages est la possibilité de mettre à niveau en un clic l'image OS de Confidential Space sous-jacente ou l'image de conteneur de l'application (ou les deux), sans provoquer d'interruption de service. Le MIG gère ce changement en remplaçant progressivement les anciennes instances par de nouvelles exécutant l'image mise à jour, ce qui garantit une disponibilité constante tout au long du déploiement. Notez que votre application devra peut-être être rétrocompatible pour prendre en charge ce type de mise à niveau progressive.

3. Configurer des ressources cloud

Avant de commencer

  1. configurer un projet Google Cloud ; Pour en savoir plus sur la création d'un projet Google Cloud, consultez l'atelier de programmation "Configurer et parcourir votre premier projet Google". Pour savoir comment récupérer l'ID du projet et en quoi il diffère du nom et du numéro du projet, consultez Créer et gérer des projets.
  2. Activez la facturation pour vos projets.
  3. Dans le Cloud Shell de l'un de vos projets Google, définissez les variables d'environnement requises pour le projet, comme indiqué ci-dessous.
export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>
  1. Activez l'API Confidential Computing et les API suivantes pour votre projet.
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
  1. Dans Cloud Shell de votre projet Google Cloud, clonez le dépôt GitHub de l'atelier de programmation Confidential Space, puis utilisez la commande ci-dessous pour obtenir les scripts appropriés nécessaires pour terminer cet atelier de programmation.
git clone https://github.com/GoogleCloudPlatform/confidential-space.git
  1. Accédez au répertoire des scripts pour l'atelier de programmation sur les groupes d'instances.
cd confidential-space/codelabs/mig_cs_codelab/scripts
  1. Modifiez la ligne de l'ID du projet dans config_env.sh pour refléter celui du projet choisi.
  2. Définissez les variables préexistantes. Remplacer les noms de ressources à l'aide de ces variables
  • Vous pouvez définir les variables suivantes avec des noms de ressources cloud existants. Si la variable est définie, les ressources cloud existantes correspondantes du projet sont utilisées. S'il n'est pas défini, le nom de la ressource cloud proviendra du script config_env.sh.
  1. Exécutez le script config_env.sh pour définir les noms de variables restants pour ce projet sur des valeurs basées sur l'ID de projet pour les noms de ressources.
source config_env.sh
  1. Ajoutez des autorisations pour le projet. Pour ajouter des autorisations, suivez les instructions de la page Web Accorder un rôle IAM.

Vous devez disposer des autorisations suivantes pour ce projet :

  • Rédacteur Artifact Registry
  • Administrateur Cloud Scheduler
  • Agent de service Compute
  • Utilisateur de charges de travail d'informatique confidentielle
  • Rédacteur de journaux
  • Développeur Cloud Run
  • Demandeur 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'
  1. Examiner test_workload.py
  • Vérifiez la sortie de la charge de travail en examinant le code source. Elle doit simplement afficher la version actuelle de la charge de travail.
  • Lorsque nous envoyons notre charge de travail à CS pour la première fois et que nous vérifions le résultat, nous devrions voir "version A" s'afficher.

4. Configurer une charge de travail

Vous devrez d'abord créer une image Docker pour la charge de travail utilisée dans cet atelier de programmation. La charge de travail est un script simple qui affiche la version de la charge de travail que vous exécutez actuellement. Il affichera que la charge de travail démarre, puis la version de la charge de travail, mettra en veille pendant cinq secondes, puis affichera que la charge de travail est terminée.

Étapes de création d'une charge de travail

  1. Exécutez create_workload.sh pour créer la charge de travail. Ce script :
  • Crée le dépôt Artifact Registry appartenant au projet dans lequel la charge de travail sera publiée.
  • Compile le code et l'empaquète dans une image Docker. Pour en savoir plus, consultez la configuration Dockerfile associée. En savoir plus
  • Publie l'image Docker dans Artifact Registry appartenant au projet
  • Accorde au compte de service <nom de votre compte de service> des autorisations de lecture pour le registre d'artefacts <nom du dépôt du registre d'artefacts>

5. Configurer un modèle d'instance et un MIG

Étapes à suivre pour créer un modèle d'instance

Vous devez d'abord créer un modèle d'instance. Ce modèle est le plan requis que le groupe d'instances géré (MIG) utilisera pour provisionner et exécuter vos charges de travail dans Confidential Space.

Le modèle d'instance est essentiel, car il définit tous les paramètres spécialisés :

  • Type de machine : dans cet exemple, nous utilisons un type de machine Confidential VM (par exemple, n2d-standard-2) compatible avec la technologie de confidential computing AMD SEV (--confidential-compute-type=SEV).
  • Image d'OS de VM : nous utilisons le projet confidential-space-images et la famille d'images confidential-space-debug pour extraire la dernière image du système d'exploitation Confidential Space.
  • Remarque : Nous utilisons l'image debug dans ce guide pour faciliter le dépannage. Contrairement à l'image de production, la version de débogage maintient la VM en cours d'exécution une fois votre charge de travail terminée et autorise l'accès SSH pour les tests. Pour les déploiements en production utilisant des données sensibles réelles, vous devez passer à la famille d'images de production.
  • Référence de la charge de travail : la ligne requiredtee-image-reference dans les métadonnées contient l'image de conteneur spécifique (votre charge de travail d'application) que la VM Confidential Space lancera.

Cette configuration garantit que chaque VM créée par le MIG est un espace confidentiel correctement configuré et prêt à exécuter votre charge de travail.

Étapes à suivre pour créer un groupe d'instances géré

L'étape suivante consiste à créer le groupe d'instances géré (MIG) à l'aide du modèle que vous venez de définir. Le MIG est essentiel, car il automatise le déploiement, la gestion et le scaling de plusieurs VM identiques.

Le script create_launch_mig.sh remplit trois objectifs principaux :

1. Créer le MIG

  • Commande  : gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
  • Objectif : cette commande crée le groupe qui gérera vos VM.
  • --size 3 : indique que le MIG doit initialement créer et gérer trois instances de votre charge de travail.
  • --template ${TEMPLATE_NAME} : il est essentiel de faire référence au modèle d'instance créé précédemment pour s'assurer que les trois instances sont configurées en tant que VM Confidential Space exécutant votre conteneur de charge de travail tee-image-reference spécifique.
  • --zone ${CURRENT_PROJECT_ZONE} : spécifie l'emplacement de déploiement des instances.

2. Récupérer le numéro de projet

  • Commande  : PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
  • Objectif : le script récupère l'ID numérique de votre projet. Ce numéro est souvent requis pour créer des rôles et des autorisations de compte de service, en particulier pour les agents de service gérés par Google.

3. Accorder des autorisations IAM

  • Commande  : gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
  • Objectif : cette étape attribue le rôle Agent de service Compute Engine au compte de service de votre charge de travail (${SERVICE_ACCOUNT). Cette autorisation est importante, car elle permet au compte de service d'agir au nom du service Compute Engine du projet, ce qui est souvent nécessaire pour les fonctionnalités automatisées du MIG, comme la gestion des instances, la configuration du réseau et l'interaction avec d'autres services Google Cloud.

Exécutez create_launch_mig.sh pour créer le groupe d'instances géré.

6. Étapes à suivre pour activer l'autoréparation et l'autoscaling

Configurer l'autoréparation

Pour garantir une haute disponibilité, nous vérifions que la charge de travail est réactive. Si l'application se fige, le MIG doit remplacer la VM. Les règles de pare-feu pour les plages d'adresses IP sources sont définies dans ce document.

# 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}

Configurer l'autoscaling

Nous allons configurer le groupe pour qu'il évolue automatiquement entre une et cinq instances afin de gérer les pics de trafic.

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. Vérifier la charge de travail et configurer les mises à jour d'images

Valider la charge de travail

Une fois que le groupe d'instances géré (MIG) a lancé les VM, nous devons vérifier que votre charge de travail Confidential Space s'exécute correctement.

Vous pouvez le faire via la console Google Cloud ou la ligne de commande.

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

Vous pouvez également consulter la sortie du port série de cette instance spécifique pour afficher le journal de votre charge de travail.

# 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

Configurer les mises à jour d'images

Dans un environnement de production, votre groupe d'instances géré (MIG) doit être mis à jour régulièrement pour deux scénarios distincts :

  1. Mises à jour de la charge de travail : publication d'une nouvelle version du code de votre application (par exemple, mise à jour de test_workload.py de la version 1 à la version 2).
  2. Mises à jour de l'infrastructure : Google publie un correctif de sécurité ou une mise à jour pour l'OS Confidential Space sous-jacent. Notez qu'il est recommandé de récupérer la dernière image CS au moins une fois par mois.

Comme nous avons configuré notre modèle d'instance avec un lien d'image dynamique (.../images/family/...) et un tag de conteneur dynamique (:latest), nous pouvons gérer ces deux scénarios avec une seule opération de remplacement progressif. Cela garantit que votre parc de VM exécute toujours la dernière pile sans aucun temps d'arrêt et sans que vous ayez à créer un modèle d'instance pour chaque modification mineure.

Script de remplacement progressif

Dans le répertoire update_images, accédez à update_images_script.sh. Ce script déclenche un remplacement progressif, qui détruit et recrée progressivement chaque VM du groupe.

#!/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}"

Pour ce script, nous pouvons utiliser "replace" plutôt que "restart".

  • Un redémarrage consiste simplement à redémarrer l'ordinateur. Il conserve le disque OS existant, ce qui signifie qu'il ne récupérera pas les nouveaux correctifs OS.
  • L'option Remplacer supprime la VM et en crée une à partir du modèle. Cela force le système à rechercher la dernière image d'OS Confidential Space de la famille et à extraire la dernière image de conteneur du registre.

--max-surge=1 : permet au MIG de créer temporairement une VM supplémentaire au-delà de la taille cible. Il lance une nouvelle VM (mise à jour) et attend qu'elle soit opérationnelle avant de supprimer une ancienne VM (obsolète).

–max-unavailable=0 : cela garantit l'absence de temps d'arrêt. Il indique au MIG qu'il n'est pas autorisé à mettre hors connexion une machine à moins qu'il n'ait déjà réussi à la remplacer.

Script de redémarrage progressif

Le répertoire update_images contient également un autre script, update_workload_image_script.sh. Ce script déclenche un redémarrage progressif, qui est une méthode plus rapide utilisée uniquement pour actualiser la charge de travail. Comme Confidential Space extrait l'image de conteneur du registre à chaque démarrage, un redémarrage suffit pour mettre à jour votre application vers la version :latest sans modifier l'hôte sous-jacent.

#!/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}"

Vérifier la charge de travail mise à jour

Nous pouvons tester la mise à niveau en un clic en simulant la publication d'une application réelle. Nous allons modifier le code de la charge de travail, le transférer vers Artifact Registry, mettre à jour le MIG et vérifier que la nouvelle version s'exécute sans temps d'arrêt.

Étape 1 : Déployez une nouvelle version de charge de travail

Tout d'abord, nous devons créer une "nouvelle" version de votre application.

  1. Ouvrez votre fichier test_workload.py local.
  2. Remplacez l'instruction d'impression de la version de charge de travail par print("Workload Version B") au lieu de print("Workload Version A").
  3. Recompilez et transférez l'image de conteneur vers Artifact Registry en exécutant create_workload.sh. Notez que nous envoyons la même balise (:latest).

Étape 2 : Exécutez la mise à jour progressive

Exécutez le script de mise à jour que nous avons créé dans la section précédente. Le MIG sera alors forcé de remplacer chaque VM, en récupérant le nouveau hachage de conteneur associé à ":latest".

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

Attendez que le script finisse de s'exécuter.

Étape 3 : Vérifiez la mise à jour via le port série

Une fois la mise à jour terminée, nous vérifions que les nouvelles VM exécutent le code mis à jour.

# 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

Obtenir le nom d'une nouvelle instance :

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

Vérifiez les journaux :

# 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

Une fois les instances en cours d'exécution, sélectionnez le nom d'une instance à partir de la commande gcloud précédente pour afficher son port série.

Résultat attendu : vous devriez voir le message de journal mis à jour, confirmant que le déploiement a réussi :

... Version B de la charge de travail ...

Étape 4 : Vérifiez la configuration de l'infrastructure (facultatif)

Vous pouvez également vérifier que votre modèle d'instance est correctement configuré pour extraire les mises à jour dynamiques de l'OS et de la charge de travail en inspectant ses métadonnées.

Exécutez la commande suivante pour afficher la référence du conteneur dynamique :

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

Résultat : L'image de votre conteneur doit se terminer par ":latest".

  • Implication : Étant donné que le modèle pointe vers la balise et non vers un hachage spécifique, chaque remplacement progressif extrait le code le plus récent que vous avez envoyé à l'étape 1.

(Facultatif) Mises à jour automatiques

Les mises à jour manuelles sont utiles pour les versions majeures, mais vous souhaitez souvent que votre parc adopte automatiquement les derniers correctifs de sécurité ou les versions de déploiement régulières sans intervention humaine.

Nous pouvons automatiser le processus de remplacement progressif en regroupant notre script de mise à jour dans un job Cloud Run. Pour cet atelier de programmation, nous le déclencherons toutes les 15 minutes. Dans un environnement de production, il doit s'exécuter beaucoup moins souvent. Selon les besoins de l'utilisateur, il peut configurer la fonctionnalité sur une base hebdomadaire ou mensuelle.

Étape 1 : Conteneurisez le script de mise à jour

Tout d'abord, nous devons empaqueter notre script update_images_script.sh (qui contient la logique gcloud ... rolling-action replace) dans un conteneur Docker afin qu'il puisse s'exécuter dans le cloud.

Nous avons préparé un script d'assistance qui crée ce conteneur et le transfère vers votre Artifact Registry.

Exécutez la commande suivante :

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

Ce que cela signifie :

  • Il extrait update_images_script.sh du répertoire update_images/.
  • Il crée une image Docker contenant le SDK Google Cloud et votre script.
  • Il transfère l'image vers ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

Étape 2 : Déployez et planifiez le job

Nous devons maintenant indiquer à Google Cloud d'exécuter ce conteneur de manière périodique. Nous utilisons Cloud Run Jobs pour exécuter le conteneur et Cloud Scheduler pour le déclencher.

Exécutez le script de configuration de la planification :

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

Dans le script : ce script effectue deux actions essentielles :

  1. Crée un job Cloud Run : il définit un job nommé mig-updater-job qui exécute le conteneur que nous venons de transférer.
  2. Crée un déclencheur Scheduler : configure une tâche Cloud Scheduler pour appeler l'API Cloud Run Jobs toutes les 15 minutes.
# (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}

Étape 3 : Valider l'automatisation

Vous n'avez pas besoin d'attendre 15 minutes pour le tester. Vous pouvez forcer l'exécution immédiate du planificateur pour valider le pipeline.

  1. Forcer l'exécution de la tâche :
gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}
  1. Vérifier l'exécution : accédez à la console Cloud Run > Jobs. Une nouvelle exécution devrait démarrer.
  2. Vérifiez le MIG : exécutez gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. Vous verrez les instances passer à l'état RECREATING (RECRÉATION) lorsque le job déclenchera la mise à jour continue.

Pourquoi 15 minutes ? Pour cet atelier de programmation, nous avons défini la planification sur "*/15 * * * *" afin que vous puissiez voir les résultats rapidement. Dans un environnement de production réel, vous devrez probablement modifier cette valeur pour une exécution quotidienne (par exemple, 0 3 * * * pour 3h du matin) ou hebdomadaire.

8. Effectuer un nettoyage

Le script cleanup.sh peut être utilisé pour nettoyer les ressources que nous avons créées dans cet atelier de programmation. Dans le cadre de ce nettoyage, les ressources suivantes seront supprimées :

  • Le groupe d'instances géré (${CURRENT_MIG_NAME}) et ses VM sous-jacentes.
  • Modèle d'instance (${TEMPLATE_NAME}).
  • Vérification de l'état et règles de pare-feu (${HEALTH_CHECK_NAME}).
  • Dépôt Artifact Registry (${REPOSITORY}).
  • Le compte de service (si vous en avez créé un dédié pour cet atelier).

Si vous avez terminé d'explorer, pensez à supprimer votre projet en suivant ces instructions : Arrêter (supprimer) des projets.

Félicitations

Bravo ! Vous avez terminé cet atelier de programmation.

Vous avez appris à mettre à l'échelle de manière sécurisée les charges de travail Confidential Space à l'aide de groupes d'instances gérés (MIG). Vous avez configuré l'autoréparation pour récupérer les données en cas d'échec, l'autoscaling pour gérer les pics de trafic et effectué des mises à jour sans temps d'arrêt pour votre image OS Confidential Space et votre conteneur de charge de travail.

Et ensuite ?

Consultez d'autres ateliers de programmation Confidential Space :

Complément d'informations