Deployment di un workload Confidential Space con i MIG utilizzando la scalabilità automatica, la riparazione automatica e gli aggiornamenti delle immagini

1. Panoramica

Confidential Space (CS) fornisce un ambiente sicuro, attestato e criptato per l'elaborazione di dati sensibili. L'utilizzo di istanze VM autonome crea un sovraccarico operativo, poiché l'orchestrazione manuale non ha la scalabilità richiesta per i servizi mission critical. Senza l'orchestrazione automatizzata, l'esecuzione di aggiornamenti rolling sincronizzati o l'implementazione di nuove immagini del sistema operativo in un parco risorse diventa tecnicamente difficile e soggetta a tempi di inattività.

In questo codelab imparerai a eseguire il deployment di un workload Confidential Space su un gruppo di istanze gestite (MIG). Scoprirai anche come attivare il ripristino automatico utilizzando i controlli di integrità, la scalabilità automatica basata sull'utilizzo della CPU e gli aggiornamenti in sequenza per le immagini del sistema operativo e i workload.

Le procedure mostrate in questo codelab dovrebbero aiutarti a configurare il tuo Confidential Space sicuro e pronto per la produzione per i deployment di lunga durata e mission-critical.

Cosa imparerai a fare

• Come creare un modello di istanza specializzato per Confidential Space.
• Come utilizzare Google Compute Engine e come configurare i MIG e i gruppi di istanze
• Come creare una regola firewall e un controllo di integrità per il ripristino automatico.
• Come configurare un MIG a livello di zona con il modello e il controllo di integrità.
• Come configurare la scalabilità automatica per il gruppo di istanze gestite.
• Come configurare gli aggiornamenti delle immagini sistema operativo con un solo clic utilizzando gli script sui MIG sia per le immagini dei workload sia per le nuove release delle immagini sistema operativo per Confidential Space

Che cosa ti serve

• Un progetto Google Cloud con la fatturazione abilitata.
• Familiarità con editor di testo, deployment Docker e scripting Bash
• Lo strumento a riga di comando gcloud installato e autenticato.
• Comprensione di base di Compute Engine, Confidential Space, IAM, VM confidenziali, tecnologia container, repository remoti, service account, Cloud Run e Cloud Scheduler
• Un'immagine container del workload Confidential Space già creata e di cui è stato eseguito il push in Artifact Registry.

2. Come funziona Confidential Space con i MIG

L'utilizzo di un gruppo di istanze gestite (MIG) per il deployment di un carico di lavoro Confidential Space rende un'applicazione sicura più solida, scalabile e facile da utilizzare.

Le esigenze operative e di sicurezza di un servizio di produzione sono logicamente suddivise tra i due componenti. Confidential Space fornisce la sicurezza necessaria eseguendo il workload in un ambiente altamente isolato, criptato e attestato chiamato Trusted Execution Environment (TEE). Al contrario, i MIG forniscono le funzionalità operative essenziali necessarie per eseguire l'applicazione sicura su larga scala, in modo simile a Kubernetes. I MIG eliminano i rischi inerenti all'esecuzione di un workload mission critical su una singola VM, che può essere potenzialmente lenta o soggetta a errori. Questa combinazione garantisce sia la protezione dei dati che l'affidabilità del sistema. Questa soluzione garantisce alta affidabilità e ripristino automatico perché il carico di lavoro viene eseguito su più VM in un pool. Se una VM si arresta in modo anomalo, il servizio rimane completamente funzionante grazie al bilanciamento del carico e alla presenza delle istanze rimanenti.

Inoltre, i MIG utilizzano controlli di integrità configurabili per monitorare costantemente lo stato operativo delle VM. Se viene rilevato che un'istanza non è integra, il MIG la sostituisce automaticamente con una VM nuova e integra, garantendo così il funzionamento continuo.

I MIG offrono anche una scalabilità efficace per gli utenti con la funzionalità di scalabilità automatica. Questa funzionalità offre un modo automatico per gestire la capacità senza intervento manuale, soddisfacendo la necessità di aggiungere o rimuovere in modo flessibile la capacità in base all'utilizzo.

Infine, i MIG consentono aggiornamenti senza tempi di inattività tramite gli aggiornamenti in sequenza. Un vantaggio fondamentale è la possibilità di eseguire l'"upgrade con un clic" dell'immagine del sistema operativo Confidential Space sottostante o dell'immagine container dell'applicazione (o di entrambi), il tutto senza causare tempi di inattività del servizio. Il MIG gestisce questa modifica sostituendo gradualmente le istanze precedenti con quelle più recenti che eseguono l'immagine aggiornata, garantendo una disponibilità costante durante l'intero deployment. Tieni presente che la tua applicazione potrebbe dover essere compatibile con le versioni precedenti per supportare questo tipo di upgrade graduale.

3. Configurazione delle risorse cloud

Prima di iniziare

1. Configurare un progetto Google Cloud. Per saperne di più sulla creazione di un progetto cloud Google, consulta il codelab"Configura e naviga nel tuo primo progetto Google". Per informazioni dettagliate su come recuperare l'ID progetto e su come si differenzia dal nome e dal numero del progetto, consulta Creazione e gestione dei progetti.
2. Abilita la fatturazione per i tuoi progetti.
3. In una delle Cloud Shell del tuo progetto Google, imposta le variabili di ambiente del progetto richieste come mostrato di seguito.

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

4. Abilita l'API Confidential Computing e le seguenti API per il tuo progetto.

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

5. In Cloud Shell del tuo progetto Google Cloud, clona il repository GitHub di Confidential Space Codelab e utilizza il comando riportato di seguito per ottenere gli script appropriati necessari per completare questo codelab.

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

6. Passa alla directory degli script per il codelab del gruppo di istanze

cd confidential-space/codelabs/mig_cs_codelab/scripts

7. Aggiorna la riga dell'ID progetto in config_env.sh in modo che rifletta quello del progetto scelto.
8. Imposta le variabili preesistenti. Esegui l'override dei nomi delle risorse utilizzando queste variabili

• Puoi impostare le seguenti variabili con i nomi delle risorse cloud esistenti. Se la variabile è impostata, vengono utilizzate le risorse cloud esistenti corrispondenti del progetto. Se non è impostato, il nome della risorsa cloud proviene dallo script config_env.sh

9. Esegui lo script config_env.sh per impostare i nomi delle variabili rimanenti per questo progetto su valori basati sull'ID progetto per i nomi delle risorse

source config_env.sh

10. Aggiungi le autorizzazioni per il progetto. Le autorizzazioni possono essere aggiunte seguendo i dettagli riportati nella pagina web Concedere un ruolo IAM.

Per questo progetto devi avere le seguenti autorizzazioni

• Artifact Registry Writer
• Cloud Scheduler Admin
• Service agent Compute
• Confidential Computing Workload User
• Log Writer
• Cloud Run Developer
• Cloud Run Invoker

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'

11. Esamina test_workload.py

• Verifica l'output del carico di lavoro esaminando il codice sorgente, che dovrebbe semplicemente stampare la versione corrente del carico di lavoro
• Quando eseguiamo il push del nostro carico di lavoro su CS e controlliamo l'output, dovremmo visualizzare la stampa di "versione A".

4. Configurazione del workload

Per prima cosa, devi creare un'immagine Docker per il carico di lavoro utilizzato in questo codelab. Il carico di lavoro è un semplice script che stampa la versione del carico di lavoro attualmente in esecuzione. Stampa l'avvio del workload, quindi la versione del workload, si mette in pausa per 5 secondi e poi stampa il completamento del workload.

Passaggi per creare un workload

1. Esegui create_workload.sh per creare il workload. Questo script:

• Crea Artifact Registry di proprietà del progetto in cui verrà pubblicato il workload
• Compila il codice e lo pacchettizza in un'immagine Docker. Per ulteriori informazioni, consulta la configurazione del Dockerfile associato.
• Pubblica l'immagine Docker in Artifact Registry di proprietà del progetto
• Concede all'account di servizio <your service account name> le autorizzazioni di lettura per il registro degli artefatti <artifact registry repo name>

5. Configurazione di un modello di istanza e di un MIG

Passaggi per creare un modello di istanza

Devi prima creare un template di istanza. Questo modello è il blueprint richiesto che il gruppo di istanze gestite (MIG) utilizzerà per eseguire il provisioning e l'esecuzione dei carichi di lavoro all'interno di Confidential Space.

Il modello di istanza è essenziale perché definisce tutti i parametri specializzati:

• Tipo di macchina:in questo esempio utilizziamo un tipo di macchina Confidential VM (ad es. n2d-standard-2) che supporta la tecnologia di confidential computing AMD SEV (--confidential-compute-type=SEV).
• Immagine sistema operativo VM:utilizziamo il progetto confidential-space-images e la famiglia di immagini confidential-space-debug per estrarre l'immagine sistema operativo Confidential Space più recente.
• Nota:in questa guida utilizziamo l'immagine debug per facilitare la risoluzione dei problemi. A differenza dell'immagine di produzione, la versione di debug mantiene la VM in esecuzione al termine del carico di lavoro e consente l'accesso SSH per i test. Per le implementazioni di produzione che utilizzano dati sensibili reali, devi passare alla famiglia di immagini di produzione.
• Riferimento al workload:la riga obbligatoriatee-image-reference nei metadati contiene l'immagine container specifica (il workload dell'applicazione) che verrà avviata dalla VM Confidential Space.

Questa configurazione garantisce che ogni VM creata dal MIG sia un Confidential Space configurato correttamente e pronto per eseguire il workload.

Passaggi per creare un gruppo di istanze gestite

Il passaggio successivo consiste nel creare il gruppo di istanze gestite (MIG) utilizzando il modello appena definito. Il MIG è essenziale perché automatizza il deployment, la gestione e la scalabilità di più VM identiche.

Lo script create_launch_mig.sh raggiunge tre obiettivi principali:

1. Crea il gruppo di istanze gestite

• Comando: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
• Scopo:questo comando crea il gruppo che gestirà le tue VM.
• --size 3: specifica che il MIG deve inizialmente creare e gestire 3 istanze del tuo workload.
• --template ${TEMPLATE_NAME}: aspetto fondamentale, fa riferimento al modello di istanza creato in precedenza, garantendo che tutte e tre le istanze siano configurate come VM Confidential Space che eseguono il tuo container di workload tee-image-reference specifico.
• --zone ${CURRENT_PROJECT_ZONE}: specifica la posizione di deployment per le istanze.

2. Recupera numero progetto

• Comando: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
• Scopo:lo script recupera l'ID numerico del tuo progetto. Questo numero è spesso necessario per creare ruoli e autorizzazioni per i service account, in particolare per i service agent gestiti da Google.

3. Concedi autorizzazioni IAM

• Comando: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
• Scopo: questo passaggio concede il ruolo Agente di servizio Compute Engine al service account del tuo workload (${SERVICE_ACCOUNT}). Questa autorizzazione è importante perché consente al service account di agire per conto del servizio Compute Engine del progetto, il che è spesso necessario per le funzionalità automatizzate del gruppo di istanze gestite, come la gestione delle istanze, la configurazione del networking e l'interazione con altri servizi Google Cloud.

Esegui create_launch_mig.sh per creare il gruppo di istanze gestite.

6. Passaggi per abilitare il ripristino automatico e la scalabilità automatica

Configurazione del ripristino automatico

Per garantire l'alta affidabilità, verifichiamo che il carico di lavoro risponda. Se l'applicazione si blocca, il MIG deve sostituire la VM. Le regole firewall per gli intervalli IP di origine sono definite in questo 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}

Configurazione della scalabilità automatica

Configureremo il gruppo in modo che venga scalato automaticamente tra 1 e 5 istanze per gestire i picchi di traffico.

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 del workload e configurazione degli aggiornamenti delle immagini

Verifica workload

Una volta che il gruppo di istanze gestite (MIG) ha avviato le VM, dobbiamo verificare che il tuo workload Confidential Space sia in esecuzione correttamente.

Puoi farlo tramite la console Google Cloud o la riga di comando.

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

Puoi anche controllare l'output della porta seriale per l'istanza specifica per visualizzare il log del carico di lavoro.

# 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

Configurare gli aggiornamenti delle immagini

In un ambiente di produzione, il gruppo di istanze gestite (MIG) deve essere aggiornato regolarmente per gestire due scenari distinti:

1. Aggiornamenti del workload:rilascio di una nuova versione del codice dell'applicazione (ad es. aggiornamento di test_workload.py dalla versione 1 alla versione 2).
2. Aggiornamenti dell'infrastruttura:Google rilascia una patch di sicurezza o un aggiornamento per il sistema operativo Confidential Space sottostante. Tieni presente che è una best practice acquisire l'ultima immagine di CS almeno una volta al mese.

Poiché abbiamo configurato il nostro modello di istanza con un link dinamico all'immagine (.../images/family/...) e un tag dinamico del container (:latest), possiamo gestire entrambi questi scenari con una singola operazione di "sostituzione progressiva". In questo modo, il tuo parco risorse di VM esegue sempre lo stack più recente senza tempi di inattività e senza richiedere la creazione di un nuovo template di istanza per ogni modifica secondaria.

Lo script di sostituzione progressiva

Nella directory update_images, vai a update_images_script.sh. Questo script attiva una sostituzione in sequenza, che distrugge e ricrea gradualmente ogni VM del gruppo

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

Per questo script possiamo utilizzare replace anziché restart.

• Un Riavvio riavvia semplicemente la macchina. Conserva il disco del sistema operativo esistente, il che significa che non riceverà nuove patch del sistema operativo.
• Un'operazione di sostituzione elimina la VM e ne crea una nuova dal modello. In questo modo, il sistema è costretto a cercare l'ultima immagine sistema operativo Confidential Space della famiglia e a eseguire il pull dell'immagine container "Latest" dal registro.

--max-surge=1: consente al MIG di creare temporaneamente una VM aggiuntiva rispetto alle dimensioni di destinazione. Avvia una nuova VM (aggiornata) e attende che sia integra prima di eliminare una VM precedente (obsoleta).

–max-unavailable=0: in questo modo si garantisce un tempo di inattività pari a zero. Indica al MIG che non è consentito mettere offline nessuna macchina a meno che non sia già stato eseguito correttamente l'incremento di un sostituto.

Lo script di riavvio graduale

Nella directory update_images è presente anche un altro script update_workload_image_script.sh. Questo script attiva un riavvio graduale, un metodo più rapido utilizzato esclusivamente per aggiornare il workload. Poiché Confidential Space estrae l'immagine container dal registro a ogni avvio, un riavvio è sufficiente per aggiornare l'applicazione alla versione :latest senza alterare l'host sottostante.

#!/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 del workload aggiornato

Possiamo testare l'"Aggiornamento con un clic" simulando il rilascio di un'applicazione reale. Modificheremo il codice del workload, lo invieremo ad Artifact Registry, aggiorneremo il MIG e verificheremo che la nuova versione sia in esecuzione senza tempi di inattività.

Passaggio 1: esegui il deployment di una nuova versione del workload

Innanzitutto, dobbiamo creare una "nuova" versione della tua applicazione.

1. Apri il file test_workload.py locale.
2. Modifica l'istruzione di stampa della versione da print("Workload Version A") a print("Workload Version B")
3. Ricrea ed esegui il push dell'immagine container in Artifact Registry eseguendo create_workload.sh. Tieni presente che stiamo eseguendo il push dello stesso tag (:latest).

Passaggio 2: esegui l'aggiornamento in sequenza

Esegui lo script di aggiornamento che abbiamo creato nella sezione precedente. In questo modo, il MIG sostituirà ogni VM, estraendo il nuovo hash del container associato a :latest.

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

Attendi il completamento dello script

Passaggio 3: verifica l'aggiornamento tramite porta seriale

Una volta completato l'aggiornamento, verifichiamo che le nuove VM eseguano il codice aggiornato.

# 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

Recupera il nome di una nuova istanza:

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

Controllare i log:

# 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 volta eseguite le istanze, seleziona un nome di istanza dal comando gcloud precedente per visualizzarne la porta seriale.

Output previsto:dovresti visualizzare il messaggio di log aggiornato, che conferma che il deployment è andato a buon fine:

... Workload Version B ...

Passaggio 4: verifica la configurazione dell'infrastruttura (facoltativo)

Puoi anche verificare che il modello di istanza sia configurato correttamente per eseguire il pull degli aggiornamenti dinamici sia per il sistema operativo che per il workload esaminando i relativi metadati.

Esegui questo comando per visualizzare il riferimento al container dinamico:

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

Risultato:dovresti vedere l'immagine container che termina con :latest.

• Implicazione:poiché il modello punta al tag e non a un hash specifico, ogni sostituzione in sequenza recupera correttamente il codice più recente che hai inviato nel passaggio 1.

(Facoltativo) Aggiornamenti automatici

Sebbene gli aggiornamenti manuali siano utili per le release delle versioni principali, spesso vuoi che il tuo parco risorse acquisisca automaticamente le patch di sicurezza più recenti o le build di deployment regolari senza intervento umano.

Possiamo automatizzare il processo di sostituzione progressiva inserendo lo script di aggiornamento in un job Cloud Run. Per questo codelab, lo attiveremo ogni 15 minuti. In un ambiente di produzione, dovrebbe essere eseguito molto meno frequentemente. A seconda delle esigenze dell'utente, potrebbe configurarlo su base settimanale o mensile.

Passaggio 1: inserisci lo script di aggiornamento in un container

Innanzitutto, dobbiamo inserire il nostro script update_images_script.sh (che contiene la logica di sostituzione rolling-action gcloud) in un container Docker in modo che possa essere eseguito nel cloud.

Abbiamo preparato uno script helper che crea questo container e ne esegue il push su Artifact Registry.

Esegui questo comando:

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

Cosa fa:

• Prende update_images_script.sh dalla directory update_images/.
• Crea un'immagine Docker contenente Google Cloud SDK e lo script.
• Esegue il push dell'immagine su ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

Passaggio 2: esegui il deployment e pianifica il job

Ora dobbiamo indicare a Google Cloud di eseguire questo container periodicamente. Utilizziamo Cloud Run Jobs per eseguire il container e Cloud Scheduler per attivarlo.

Esegui lo script di configurazione della pianificazione:

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

All'interno dello script:questo script esegue due azioni fondamentali:

1. Crea un job Cloud Run:definisce un job denominato mig-updater-job che esegue il container che abbiamo appena eseguito il push.
2. Crea un trigger di Scheduler:configura un job Cloud Scheduler per chiamare l'API Cloud Run Jobs ogni 15 minuti.

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

Passaggio 3: verifica l'automazione

Non devi aspettare 15 minuti per testarlo. Puoi forzare l'esecuzione immediata dello scheduler per verificare la pipeline.

1. Forza l'esecuzione del job:

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

2. Controlla l'esecuzione:vai alla console Cloud Run > Job. Dovresti vedere l'avvio di una nuova esecuzione.
3. Controlla il gruppo di istanze gestite: esegui gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. Vedrai le istanze entrare nello stato RECREATING quando il job attiva l'aggiornamento in sequenza.

Perché 15 minuti? Per questo codelab, abbiamo impostato la pianificazione su */15 * * * * in modo che tu possa vedere rapidamente i risultati. In un ambiente di produzione reale, probabilmente modificheresti questa impostazione in modo che venga eseguita giornalmente (ad es. 0 3 * * * per le 3:00) o settimanalmente.

8. Esegui la pulizia

Lo script di pulizia cleanup.sh può essere utilizzato per liberare spazio dalle risorse che abbiamo creato nell'ambito di questo codelab. Nell'ambito di questa pulizia, verranno eliminate le seguenti risorse:

• Il gruppo di istanze gestite (${CURRENT_MIG_NAME}) e le relative VM sottostanti.
• Il modello di istanza (${TEMPLATE_NAME}).
• Controllo di integrità e regole firewall (${HEALTH_CHECK_NAME}).
• Il repository Artifact Registry (${REPOSITORY}).
• Il service account (se ne hai creato uno dedicato per questo lab).

Se hai terminato l'esplorazione, valuta la possibilità di eliminare il progetto seguendo queste istruzioni: Arresto (eliminazione) dei progetti.

Congratulazioni

Congratulazioni, hai completato il codelab.

Hai imparato a scalare in modo sicuro i workload di Confidential Space utilizzando i gruppi di istanze gestite (MIG). Hai configurato correttamente Autohealing per il ripristino in caso di errori, Scalabilità automatica per gestire i picchi di traffico ed eseguito Aggiornamenti senza tempi di inattività sia per l'immagine del sistema operativo Confidential Space sia per il container del carico di lavoro.

Passaggi successivi

Dai un'occhiata ad altri codelab di Confidential Space:

• Protezione dei modelli di ML e della proprietà intellettuale con Confidential Space
• Come eseguire transazioni di asset digitali con il calcolo multipartitico e Confidential Space
• Analizzare i dati riservati con Confidential Space
• Utilizza Confidential Space con risorse protette che non sono archiviate con un provider cloud

Further reading

• Scalabilità basata sulle metriche di Monitoring
• Ti senti isolato? Confidential Computing in soccorso
• Confidential Computing su GCP
• Confidential Space: il futuro della collaborazione che tutela la privacy
• Panoramica sulla sicurezza di Confidential Space
• Rafforzare la privacy dei dati: collaborazione confidenziale tra più parti su larga scala