Vertrauliche Arbeitslasten mit MIGs bereitstellen, die Autoscaling, automatische Reparatur und Image-Updates verwenden

1. Übersicht

Confidential Space (CS) bietet eine sichere, bestätigte und verschlüsselte Umgebung für die Verarbeitung sensibler Daten. Die Verwendung von eigenständigen VM-Instanzen führt zu einem erhöhten Betriebsaufwand, da die manuelle Orchestrierung nicht die Skalierbarkeit bietet, die für unternehmenskritische Dienste erforderlich ist. Ohne automatisierte Orchestrierung wird es technisch schwierig, synchronisierte Rolling Updates durchzuführen oder neue Betriebssystem-Images in einer Flotte bereitzustellen. Außerdem steigt das Risiko von Ausfallzeiten.

In diesem Codelab erfahren Sie, wie Sie eine Confidential Space-Arbeitslast in einer verwalteten Instanzgruppe (MIG) bereitstellen. Außerdem erfahren Sie, wie Sie die automatische Reparatur mithilfe von Systemdiagnosen, Autoscaling auf Grundlage der CPU-Auslastung und Rolling Updates für Betriebssystem-Images und Arbeitslasten aktivieren.

Die in diesem Codelab beschriebenen Prozesse sollen Ihnen helfen, einen eigenen produktionsbereiten und sicheren Confidential Space für unternehmenskritische, lang andauernde Bereitstellungen einzurichten.

Lerninhalte

So erstellen Sie eine spezielle Instanzvorlage für Confidential Space.
Google Compute Engine verwenden und MIGs und Instanzgruppen konfigurieren
So erstellen Sie eine Firewallregel und eine Systemdiagnose für die automatische Korrektur.
So konfigurieren Sie eine zonale MIG mit der Vorlage und der Systemdiagnose.
So richten Sie Autoscaling für die MIG ein.
Ein-Klick-Betriebssystem-Image-Updates für MIGs mithilfe von Scripting für Arbeitslast-Images sowie neue Betriebssystem-Image-Releases für Confidential Space einrichten

Voraussetzungen

Google Cloud-Projekt mit aktivierter Abrechnungsfunktion.
Vertrautheit mit Texteditoren, Docker-Bereitstellungen und Bash-Scripting
Das gcloud-Befehlszeilentool ist installiert und authentifiziert.
Grundkenntnisse in Compute Engine, Confidential Space, IAM, Confidential VMs, Containertechnologie, Remote-Repositories, Dienstkonten, Cloud Run und Cloud Scheduler
Ein Confidential Space-Arbeitslast-Container-Image, das bereits erstellt und per Push an Artifact Registry übertragen wurde.

2. Funktionsweise von Confidential Space mit MIGs

Wenn Sie eine verwaltete Instanzgruppe (Managed Instance Group, MIG) zum Bereitstellen einer Confidential Space-Arbeitslast verwenden, wird eine sichere Anwendung robuster, skalierbarer und einfacher zu betreiben.

Die Sicherheits- und Betriebsbedürfnisse eines Produktionsdienstes sind logisch zwischen den beiden Komponenten aufgeteilt. Confidential Space bietet die erforderliche Sicherheit, indem die Arbeitslast in einer hochgradig isolierten, verschlüsselten und bestätigten Umgebung ausgeführt wird, die als vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) bezeichnet wird. Im Gegensatz dazu bieten MIGs die wesentlichen Betriebsfunktionen, die für die Ausführung der sicheren Anwendung im großen Maßstab erforderlich sind, ähnlich wie Kubernetes. MIGs beseitigen die Risiken, die mit der Ausführung einer geschäftskritischen Arbeitslast auf einer einzelnen VM verbunden sind, die potenziell langsam oder anfällig für Fehler sein kann. Diese Kombination sorgt sowohl für Datenschutz als auch für Systemzuverlässigkeit. Diese Lösung bietet Hochverfügbarkeit und automatische Reparatur, da die Arbeitslast auf mehreren VMs in einem Pool ausgeführt wird. Wenn eine VM abstürzt, bleibt der Dienst aufgrund des Load-Balancings und der verbleibenden Instanzen voll funktionsfähig.

Außerdem verwenden MIGs konfigurierbare Systemdiagnosen, um den Betriebsstatus der VMs ständig zu überwachen. Wenn eine Instanz als fehlerhaft erkannt wird, ersetzt die MIG sie automatisch durch eine neue, fehlerfreie VM und sorgt so für einen kontinuierlichen Betrieb.

MIGs bieten Nutzern mit der Autoscaling-Funktion auch eine effektive Skalierbarkeit. Diese Funktion bietet eine automatische Möglichkeit, die Kapazität ohne manuellen Eingriff zu verwalten. So kann die Kapazität je nach Nutzung flexibel hinzugefügt oder entfernt werden.

Schließlich ermöglichen MIGs Zero-Downtime-Updates durch Rolling Updates. Ein wichtiger Vorteil ist die Möglichkeit zum Ein-Klick-Upgrade des zugrunde liegenden Confidential Space-Betriebssystem-Images oder des Container-Images der Anwendung (oder beider), ohne dass es zu Ausfallzeiten des Dienstes kommt. Die MIG verwaltet diese Änderung, indem sie die älteren Instanzen nach und nach durch neuere ersetzt, auf denen das aktualisierte Image ausgeführt wird. So wird während der gesamten Bereitstellung eine konstante Verfügbarkeit gewährleistet. Ihre Anwendung muss möglicherweise abwärtskompatibel sein, um diese Art von schrittweisem Upgrade zu unterstützen.

3. Cloud-Ressourcen einrichten

Hinweis

Richten Sie ein Google Cloud-Projekt ein. Weitere Informationen zum Erstellen eines Google Cloud-Projekts finden Sie im Codelab „Erstes Google-Projekt einrichten und darin navigieren“. Weitere Informationen zum Abrufen der Projekt-ID und zum Unterschied zwischen Projekt-ID, Projektname und Projektnummer finden Sie unter Projekte erstellen und verwalten.
Aktivieren Sie die Abrechnung für Ihre Projekte.
Legen Sie in der Cloud Shell eines Ihrer Google-Projekte die erforderlichen Projektumgebungsvariablen wie unten gezeigt fest.

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

Aktivieren Sie die Confidential Computing API und die folgenden APIs für Ihr Projekt.

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

Klonen Sie in Cloud Shell in Ihrem Google Cloud-Projekt das Confidential Space Codelab Github Repository und verwenden Sie den folgenden Befehl, um die entsprechenden Skripts für dieses Codelab zu erhalten.

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

Wechseln Sie in das Skriptverzeichnis für das Codelab zur Instanzgruppe.

cd confidential-space/codelabs/mig_cs_codelab/scripts

Aktualisieren Sie die Zeile mit der Projekt-ID in config_env.sh, sodass sie der ID Ihres ausgewählten Projekts entspricht.
Legen Sie alle vorhandenen Variablen fest. Ressourcennamen mit diesen Variablen überschreiben

Sie können die folgenden Variablen mit vorhandenen Cloud-Ressourcennamen festlegen. Wenn die Variable festgelegt ist, werden die entsprechenden vorhandenen Cloud-Ressourcen aus dem Projekt verwendet. Wenn sie nicht festgelegt ist, wird der Name der Cloud-Ressource aus dem Script config_env.sh abgerufen.

Führen Sie das Script „config_env.sh“ aus, um die verbleibenden Variablennamen für dieses Projekt auf Werte festzulegen, die auf der Projekt-ID für Ressourcennamen basieren.

source config_env.sh

Fügen Sie dem Projekt Berechtigungen hinzu. Berechtigungen können hinzugefügt werden, indem Sie der Anleitung zum Zuweisen einer IAM-Rolle folgen.

Sie benötigen die folgenden Berechtigungen für dieses Projekt:

Artifact Registry Writer
Cloud Scheduler-Administrator
Compute-Dienst-Agent
Confidential Computing Workload User
Log-Autor
Cloud Run-Entwickler
Cloud Run-Aufrufer

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'

Sehen Sie sich test_workload.py an.

Überprüfen Sie die Ausgabe der Arbeitslast, indem Sie den Quellcode ansehen. Es sollte lediglich die aktuelle Version der Arbeitslast ausgegeben werden.
Wenn wir unsere Arbeitslast zum ersten Mal in CS übertragen und die Ausgabe prüfen, sollte „Version A“ ausgegeben werden.

4. Arbeitslast einrichten

Zuerst müssen Sie ein Docker-Image für die Arbeitslast erstellen, die in diesem Codelab verwendet wird. Die Arbeitslast ist ein einfaches Skript, das die Version der Arbeitslast ausgibt, die Sie gerade ausführen. Es wird ausgegeben, dass die Arbeitslast gestartet wird, dann die Version der Arbeitslast, es wird 5 Sekunden gewartet und dann wird ausgegeben, dass die Arbeitslast abgeschlossen ist.

Schritte zum Erstellen einer Arbeitslast

Führen Sie „create_workload.sh“ aus, um die Arbeitslast zu erstellen. Mit diesem Skript wird Folgendes ausgeführt:

Erstellt das Artifact Registry-Repository, das dem Projekt gehört, in dem der Workload veröffentlicht wird.
Erstellt den Code und verpackt ihn in einem Docker-Image. Weitere Informationen finden Sie in der zugehörigen Dockerfile-Konfiguration.
Veröffentlicht das Docker-Image in der Artifact Registry des Projekts
Gewährt dem Dienstkonto <your service account name> Leseberechtigungen für die Artifact Registry <artifact registry repo name>

5. Instanzvorlage und MIG einrichten

Anleitung zum Erstellen von Instanzvorlagen

Sie müssen zuerst eine Instanzvorlage erstellen. Diese Vorlage ist der erforderliche Blueprint, den die verwaltete Instanzgruppe (Managed Instance Group, MIG) zum Bereitstellen und Ausführen Ihrer Arbeitslasten in Confidential Space verwendet.

Die Instanzvorlage ist wichtig, da sie alle speziellen Parameter definiert:

Maschinentyp:In diesem Beispiel verwenden wir einen Confidential VM-Maschinentyp (z.B. n2d-standard-2), der die AMD SEV-Technologie für vertrauliches Computing (--confidential-compute-type=SEV) unterstützt.
Betriebssystem-Image für VM:Wir verwenden das Projekt confidential-space-images und die Image-Familie confidential-space-debug, um das neueste Betriebssystem-Image für Confidential Space abzurufen.
Hinweis:In dieser Anleitung verwenden wir das debug-Image, um die Fehlerbehebung zu erleichtern. Im Gegensatz zum Produktions-Image wird die VM in der Debug-Version nach Abschluss der Arbeitslast nicht beendet. Außerdem ist SSH-Zugriff für Tests möglich. Für Produktionsbereitstellungen mit sensiblen Daten aus der Praxis müssen Sie zur Produktions-Image-Familie wechseln.
Arbeitslastreferenz:Die erforderliche Zeile tee-image-reference in den Metadaten enthält das spezifische Container-Image (Ihre Anwendungsarbeitslast), das von der Confidential Space-VM gestartet wird.

Bei dieser Einrichtung ist jede von der verwalteten Instanzgruppe erstellte VM ein korrekt konfiguriertes Confidential Space, das bereit ist, Ihre Arbeitslast auszuführen.

Schritte zum Erstellen einer verwalteten Instanzgruppe

Als Nächstes erstellen Sie die verwaltete Instanzgruppe (Managed Instance Group, MIG) mit der Vorlage, die Sie gerade definiert haben. Die MIG ist unerlässlich, da sie die Bereitstellung, Verwaltung und Skalierung mehrerer identischer VMs automatisiert.

Das Skript „create_launch_mig.sh“ erfüllt drei Hauptziele:

1. MIG erstellen

Befehl : gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
Zweck:Mit diesem Befehl wird die Gruppe erstellt, die Ihre VMs verwaltet.
--size 3: Gibt an, dass die MIG anfangs 3 Instanzen Ihrer Arbeitslast erstellen und verwalten soll.
--template ${TEMPLATE_NAME}: Wichtig: Sie verweist auf die zuvor erstellte Instanzvorlage. So wird sichergestellt, dass alle drei Instanzen als Confidential Space-VMs konfiguriert werden, auf denen Ihr spezifischer tee-image-reference-Arbeitslastcontainer ausgeführt wird.
--zone ${CURRENT_PROJECT_ZONE}: Gibt den Bereitstellungsort für die Instanzen an.

2. Projektnummer abrufen

Befehl : PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
Zweck:Das Script ruft die numerische ID Ihres Projekts ab. Diese Nummer ist häufig erforderlich, um Dienstkontorollen und -berechtigungen zu erstellen, insbesondere für von Google verwaltete Dienst-Agents.

3. IAM-Berechtigungen gewähren

Befehl : gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
Zweck:In diesem Schritt wird dem Dienstkonto Ihrer Arbeitslast (${SERVICE_ACCOUNT) die Rolle Compute Engine-Dienst-Agent zugewiesen. Diese Berechtigung ist wichtig, da das Dienstkonto dadurch im Namen des Compute Engine-Dienstes des Projekts agieren kann. Dies ist häufig für die automatisierten Funktionen der MIG erforderlich, z. B. zum Verwalten von Instanzen, Einrichten von Netzwerken und Interagieren mit anderen Google Cloud-Diensten.

Führen Sie create_launch_mig.sh aus, um die verwaltete Instanzgruppe zu erstellen.

6. Schritte zum Aktivieren von Autohealing und Autoscaling

Automatische Reparatur einrichten

Um eine hohe Verfügbarkeit zu gewährleisten, prüfen wir, ob die Arbeitslast reagiert. Wenn die Anwendung einfriert, sollte die MIG die VM ersetzen. Firewallregeln für Quell-IP-Bereiche sind in diesem Dokument definiert.

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

Autoscaling einrichten

Wir konfigurieren die Gruppe so, dass sie automatisch zwischen 1 und 5 Instanzen skaliert wird, um Trafficspitzen zu bewältigen.

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. Arbeitslast prüfen und Image-Updates einrichten

Arbeitslast überprüfen

Nachdem die VMs von der verwalteten Instanzgruppe (Managed Instance Group, MIG) gestartet wurden, müssen wir überprüfen, ob Ihre Confidential Space-Arbeitslast ordnungsgemäß ausgeführt wird.

Dies können Sie über die Google Cloud Console oder die Befehlszeile tun.

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

Sie können auch die Ausgabe des seriellen Ports für diese bestimmte Instanz prüfen, um das Log Ihrer Arbeitslast aufzurufen.

# 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

Bild-Aktualisierung einrichten

In einer Produktionsumgebung muss Ihre verwaltete Instanzgruppe (Managed Instance Group, MIG) regelmäßig aktualisiert werden, um zwei unterschiedliche Szenarien zu berücksichtigen:

Arbeitslast-Updates:Eine neue Version Ihres Anwendungscodes wird veröffentlicht (z.B. Aktualisieren von „test_workload.py“ von Version 1 auf Version 2).
Infrastrukturupdates:Google veröffentlicht einen Sicherheitspatch oder ein Update für das zugrunde liegende Confidential Space-Betriebssystem. Es wird empfohlen, mindestens einmal im Monat das neueste CS-Image zu verwenden.

Da wir unsere Instanzvorlage mit einem Dynamic Image Link (.../images/family/...) und einem Dynamic Container Tag (:latest) konfiguriert haben, können wir beide Szenarien mit einem einzigen „Rolling Replace“-Vorgang (fortlaufender Austausch) abwickeln. So wird sichergestellt, dass auf Ihren VMs immer der neueste Stack ausgeführt wird, ohne dass Ausfallzeiten entstehen und ohne dass Sie für jede geringfügige Änderung eine neue Instanzvorlage erstellen müssen.

Das Rolling Replace-Skript

Rufen Sie im Verzeichnis update_images „update_images_script.sh“ auf. Dieses Skript löst einen rollierenden Ersatz aus, bei dem jede VM in der Gruppe nach und nach zerstört und neu erstellt wird.

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

Für dieses Script können wir „replace“ anstelle von „restart“ verwenden.

Bei einem Neustart wird das Gerät einfach neu gestartet. Die vorhandene Betriebssystemfestplatte bleibt erhalten, sodass keine neuen Betriebssystempatches installiert werden.
Bei Ersetzen wird die VM gelöscht und eine neue aus der Vorlage erstellt. Dadurch wird das System gezwungen, das neueste Confidential Space-Betriebssystem-Image aus der Familie zu suchen und das Container-Image „Latest“ aus der Registry abzurufen.

--max-surge=1: Damit kann die MIG vorübergehend eine zusätzliche VM über der Zielgröße erstellen. Dabei wird eine neue (aktualisierte) VM gestartet und gewartet, bis sie fehlerfrei ist, bevor eine alte (veraltete) VM gelöscht wird.

–max-unavailable=0: Dadurch werden Ausfallzeiten vermieden. Sie weist die MIG an, dass sie keine Maschine offline nehmen darf, es sei denn, sie hat bereits erfolgreich eine Ersatzmaschine hochgefahren.

Das Script für den rollierenden Neustart

Im Verzeichnis update_images befindet sich auch das Skript update_workload_image_script.sh. Dieses Skript löst einen Rolling Restart aus. Dies ist eine schnellere Methode, die ausschließlich zum Aktualisieren der Arbeitslast verwendet wird. Da Confidential Space das Container-Image bei jedem Start aus der Registry abruft, reicht ein Neustart aus, um Ihre Anwendung auf die Version :latest zu aktualisieren, ohne den zugrunde liegenden Host zu ändern.

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

Aktualisierte Arbeitslast überprüfen

Wir können das „One-Click Upgrade“ testen, indem wir eine reale Anwendungsversion simulieren. Wir ändern den Arbeitslastcode, pushen ihn in die Artifact Registry, aktualisieren die verwaltete Instanzgruppe und prüfen, ob die neue Version ohne Ausfallzeit ausgeführt wird.

Schritt 1: Neue Version einer Arbeitslast bereitstellen

Zuerst müssen wir eine „neue“ Version Ihrer Anwendung erstellen.

Öffnen Sie die lokale Datei „test_workload.py“.
Ändern Sie die Anweisung zum Ausgeben der Version von print("Workload Version A") zu print("Workload Version B").
Erstellen Sie das Container-Image neu und übertragen Sie es per Push an Artifact Registry, indem Sie „create_workload.sh“ ausführen. Wir pushen zum selben Tag (:latest).

Schritt 2: Rolling Update ausführen

Führen Sie das Aktualisierungsskript aus, das wir im vorherigen Abschnitt erstellt haben. Dadurch wird die MIG gezwungen, jede VM zu ersetzen und den neuen Container-Hash abzurufen, der mit „:latest“ verknüpft ist.

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

Warten Sie, bis das Skript abgeschlossen ist.

Schritt 3: Update über seriellen Port überprüfen

Nach Abschluss des Updates prüfen wir, ob auf den neuen VMs der aktualisierte Code ausgeführt wird.

# 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

Name einer neuen Instanz abrufen:

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

Logs prüfen:

# 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

Wenn die Instanzen ausgeführt werden, wählen Sie einen beliebigen Instanznamen aus dem vorherigen gcloud-Befehl aus, um den seriellen Port aufzurufen.

Erwartete Ausgabe:Sie sollten die aktualisierte Log-Meldung sehen, die bestätigt, dass die Bereitstellung erfolgreich war:

... Workload-Version B ...

Schritt 4: Infrastrukturkonfiguration überprüfen (optional)

Sie können auch prüfen, ob Ihre Instanzvorlage richtig konfiguriert ist, um dynamische Updates für das Betriebssystem und die Arbeitslast abzurufen. Dazu müssen Sie die Metadaten der Vorlage untersuchen.

Führen Sie den folgenden Befehl aus, um die dynamische Containerreferenz aufzurufen:

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

Ergebnis:Das Container-Image sollte mit „:latest“ enden.

Implikation:Da die Vorlage auf das Tag und nicht auf einen bestimmten Hash verweist, wird bei jeder rollierenden Ersetzung der neueste Code abgerufen, den Sie in Schritt 1 übertragen haben.

(Optional) Automatisierte Updates

Manuelle Updates sind zwar für die Veröffentlichung von Hauptversionen nützlich, aber oft soll Ihre Flotte die neuesten Sicherheitspatches oder regulären Bereitstellungs-Builds automatisch ohne menschliches Eingreifen erhalten.

Wir können den Prozess „Rolling Replace“ automatisieren, indem wir unser Aktualisierungsskript in einem Cloud Run-Job verpacken. In diesem Codelab wird er alle 15 Minuten ausgelöst. In einer Produktionsumgebung sollte es viel seltener ausgeführt werden. Je nach Bedarf kann der Nutzer die Funktion wöchentlich oder monatlich konfigurieren.

Schritt 1: Updater-Skript in Container packen

Zuerst müssen wir unser update_images_script.sh-Skript (das die gcloud ... rolling-action replace-Logik enthält) in einen Docker-Container packen, damit es in der Cloud ausgeführt werden kann.

Wir haben ein Hilfsskript vorbereitet, mit dem dieser Container erstellt und in Ihre Artifact Registry übertragen wird.

Führen Sie dazu diesen Befehl aus:

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

Was passiert dabei?

Dazu wird das Script „update_images_script.sh“ aus dem Verzeichnis „update_images/“ verwendet.
Dadurch wird ein Docker-Image mit dem Google Cloud SDK und Ihrem Skript erstellt.
Das Image wird an ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest übertragen.

Schritt 2: Job bereitstellen und planen

Jetzt müssen wir Google Cloud anweisen, diesen Container regelmäßig auszuführen. Wir verwenden Cloud Run-Jobs, um den Container auszuführen, und Cloud Scheduler, um ihn auszulösen.

Führen Sie das Skript zur Konfiguration der Zeitplanung aus:

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

Im Skript:Dieses Skript führt zwei wichtige Aktionen aus:

Cloud Run-Job erstellen:Hier wird ein Job mit dem Namen „mig-updater-job“ definiert, der den Container ausführt, den wir gerade per Push übertragen haben.
Scheduler-Trigger erstellen:Ein Cloud Scheduler-Job wird eingerichtet, um alle 15 Minuten die Cloud Run Job API aufzurufen.

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

Schritt 3: Automatisierung überprüfen

Sie müssen nicht 15 Minuten warten, um die Funktion zu testen. Sie können den Scheduler zwingen, sofort ausgeführt zu werden, um die Pipeline zu überprüfen.

Job erzwingen:

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

Ausführung prüfen:Rufen Sie die Cloud Run Console > Jobs auf. Es sollte eine neue Ausführung gestartet werden.
MIG prüfen:Führen Sie gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} aus. Sie sehen, dass die Instanzen in den Status „RECREATING“ wechseln, wenn der Job das Rolling Update auslöst.

Warum 15 Minuten? Für dieses Codelab haben wir den Zeitplan auf */15 * * * * festgelegt, damit Sie die Ergebnisse schnell sehen können. In einer echten Produktionsumgebung würden Sie dies wahrscheinlich so ändern, dass der Job täglich (z.B. 0 3 * * * für 3:00 Uhr) oder wöchentlich ausgeführt wird.

8. Bereinigen

Mit dem Bereinigungsskript „cleanup.sh“ können Sie die Ressourcen bereinigen, die wir im Rahmen dieses Codelabs erstellt haben. Im Rahmen dieser Bereinigung werden die folgenden Ressourcen gelöscht:

Die verwaltete Instanzgruppe (${CURRENT_MIG_NAME}) und die zugehörigen VMs.
Die Instanzvorlage (${TEMPLATE_NAME}).
Die Systemdiagnose und die Firewallregeln (${HEALTH_CHECK_NAME}).
Das Artifact Registry-Repository (${REPOSITORY}).
Das Dienstkonto, falls Sie ein dediziertes Konto für dieses Lab erstellt haben.

Wenn Sie die Erkundung abgeschlossen haben, sollten Sie Ihr Projekt löschen. Folgen Sie dazu der Anleitung unter Projekte beenden (löschen).

Glückwunsch

Sie haben das Codelab erfolgreich abgeschlossen.

Sie haben gelernt, wie Sie Confidential Space-Arbeitslasten mit verwalteten Instanzgruppen (MIGs) sicher skalieren. Sie haben Autohealing konfiguriert, um Fehler zu beheben, Autoscaling, um Trafficspitzen zu bewältigen, und Updates ohne Ausfallzeiten für Ihr Confidential Space-Betriebssystem-Image und den Arbeitslastcontainer durchgeführt.

Nächste Schritte

Weitere Confidential Space-Codelabs:

ML-Modelle und geistiges Eigentum mit Confidential Space schützen
So werden digitale Assets mit Multi-Party Computation und Confidential Space bearbeitet
Vertrauliche Daten mit Confidential Space analysieren
Confidential Space mit geschützten Ressourcen verwenden, die nicht bei einem Cloud-Anbieter gespeichert sind