In dieser Anleitung wird erläutert, wie Sie mit Cloud Build und Terraform Blau/Grün-Bereitstellungen ohne Ausfallzeiten in verwalteten Compute Engine-Instanzgruppen (MIGs) ausführen.
Mit Cloud Build können Sie eine Vielzahl von Entwicklerprozessen automatisieren, darunter das Erstellen und Bereitstellen von Anwendungen in verschiedenen Google Cloud-Laufzeiten wie Compute Engine, Google Kubernetes Engine, GKE Enterprise und Cloud Functions.
Mit Compute Engine-MIGs können Sie Anwendungen auf mehreren identischen virtuellen Maschinen (VMs) ausführen. Sie können Ihre Arbeitslasten skalierbar und hochverfügbar machen, indem Sie automatisierte MIG-Dienste nutzen, darunter Autoscaling, automatische Reparatur, regionale Bereitstellung (in mehreren Zonen) und automatische Updates. Mit dem Blau/Grün-Modell für kontinuierliche Bereitstellung erfahren Sie, wie Sie Nutzertraffic schrittweise von einer verwalteten Instanzgruppe (blau) auf eine andere verwaltete Instanzgruppe (grün) übertragen, die beide in der Produktion ausgeführt werden.
Designübersicht
Das folgende Diagramm zeigt das Blau/Grün-Bereitstellungsmodell, das im Codebeispiel in diesem Dokument verwendet wird:
Grundsätzlich umfasst dieses Modell die folgenden Komponenten:
- Zwei Compute Engine-VM-Pools: Blau und Grün.
- Drei externe HTTP(S)-Load-Balancer:
- Ein Blau/Grün-Load-Balancer, der den Traffic von Endnutzern entweder zum blauen oder zum grünen Pool von VM-Instanzen weiterleitet.
- Ein blauer Load Balancer, der den Traffic von QA-Entwicklern und -Entwicklern an den blauen VM-Instanzpool weiterleitet
- Ein grüner Load-Balancer, der den Traffic von QA-Entwicklern und -Entwicklern an den grünen Instanzpool weiterleitet.
- Zwei Nutzergruppen:
- Endnutzer, die Zugriff auf den Blau/Grün-Load-Balancer haben, der sie entweder auf den blauen oder den grünen Instanzpool verweist.
- QA-Entwickler und -Entwickler, die für Entwicklungs- und Testzwecke Zugriff auf beide Gruppen von Pools benötigen. Sie können auf die blauen und den grünen Load-Balancer zugreifen, die sie jeweils an den blauen und den grünen Instanzpool weiterleiten.
Die blauen und grünen VM-Pools werden als Compute Engine-MIGs implementiert und externe IP-Adressen werden über externe HTTP(S)-Load-Balancer an die VMs in der verwalteten Instanzgruppe weitergeleitet. Im hier beschriebenen Codebeispiel wird Terraform verwendet, um diese Infrastruktur zu konfigurieren.
Das folgende Diagramm veranschaulicht die Entwicklervorgänge, die bei der Bereitstellung stattfinden:
Im obigen Diagramm stellen die roten Pfeile den Bootstrapping-Ablauf beim ersten Einrichten der Bereitstellungsinfrastruktur dar. Die blauen Pfeile stellen den GitOps-Ablauf während jeder Bereitstellung dar.
Zum Einrichten dieser Infrastruktur führen Sie ein Einrichtungsskript aus, das den Bootstrap-Prozess startet und die Komponenten für den GitOps-Ablauf einrichtet.
Das Einrichtungsskript führt eine Cloud Build-Pipeline aus, die die folgenden Vorgänge ausführt:
- Ein Repository mit dem Namen
copy-of-gcp-mig-simple
in Cloud Source Repositories wird erstellt und der Quellcode aus dem GitHub-Beispiel-Repository wird in das Repository in Cloud Source Repositories kopiert. - Es werden zwei Cloud Build-Trigger mit den Namen
apply
unddestroy
erstellt.
Der apply
-Trigger ist an eine Terraform-Datei mit dem Namen main.tfvars
in Cloud Source Repositories angehängt. Diese Datei enthält die Terraform-Variablen, die die blauen und die grünen Load-Balancer darstellen.
Aktualisieren Sie die Variablen in der Datei main.tfvars
, um die Bereitstellung einzurichten.
Der apply
-Trigger führt eine Cloud Build-Pipeline aus, die tf_apply
und die folgenden Vorgänge ausführt:
- Erstellt zwei Compute Engine-MIGs (eine für Grün und eine für Blau), vier Compute Engine-VM-Instanzen (zwei für die grüne MIG und zwei für die blaue MIG), die drei Load-Balancer (Blau, Grün und den Splitter) und drei öffentliche IP-Adressen.
- Gibt die IP-Adressen aus, mit denen Sie die bereitgestellten Anwendungen in den blauen und den grünen Instanzen sehen können.
Der Löschtrigger wird manuell ausgelöst, um alle Ressourcen zu löschen, die vom Trigger zum Anwenden erstellt wurden.
Lernziele
Verwenden Sie Cloud Build und Terraform, um externe HTTP(S)-Load-Balancer mit Compute Engine-VM-Instanzgruppen-Back-Ends einzurichten.
Blau/Grün-Bereitstellungen auf den VM-Instanzen ausführen
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.
Hinweise
- Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
- Installieren Sie die Google Cloud CLI.
-
Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:
gcloud init
-
Google Cloud-Projekt erstellen oder auswählen.
-
Erstellen Sie ein Google Cloud-Projekt:
gcloud projects create PROJECT_ID
Ersetzen Sie
PROJECT_ID
durch einen Namen für das Google Cloud-Projekt, das Sie erstellen. -
Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:
gcloud config set project PROJECT_ID
Ersetzen Sie
PROJECT_ID
durch den Namen Ihres Google Cloud-Projekts.
-
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
- Installieren Sie die Google Cloud CLI.
-
Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:
gcloud init
-
Google Cloud-Projekt erstellen oder auswählen.
-
Erstellen Sie ein Google Cloud-Projekt:
gcloud projects create PROJECT_ID
Ersetzen Sie
PROJECT_ID
durch einen Namen für das Google Cloud-Projekt, das Sie erstellen. -
Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:
gcloud config set project PROJECT_ID
Ersetzen Sie
PROJECT_ID
durch den Namen Ihres Google Cloud-Projekts.
-
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
Testen
Führen Sie das Einrichtungsskript aus dem Codebeispiel-Repository von Google aus:
bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)
Wenn das Einrichtungsskript die Nutzereinwilligung anfordert, geben Sie yes ein.
Das Skript ist in einigen Sekunden fertig.
Rufen Sie in der Google Cloud Console die Cloud Build-Seite Build-Verlauf auf:
Klicken Sie auf den neuesten Build.
Sie sehen die Seite Build-Details. Hier wird eine Cloud Build-Pipeline mit drei Build-Schritten angezeigt: Mit dem ersten Build-Schritt wird ein Repository in Cloud Source Repositories erstellt, mit dem zweiten Schritt wird der Inhalt des Beispiel-Repositorys in GitHub in Cloud Source Repositories geklont und im dritten Schritt werden zwei Build-Trigger hinzugefügt.
Öffnen Sie Cloud Source Repositories:
Klicken Sie in der Liste der Repositories auf
copy-of-gcp-mig-simple
.Auf dem Tab Verlauf unten auf der Seite wird ein Commit mit der Beschreibung
A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git
angezeigt, der von Cloud Build zum Erstellen eines Repositorys mit dem Namencopy-of-gcp-mig-simple
erstellt wurde.Öffnen Sie die Cloud Build-Seite Trigger:
Aktualisieren Sie die Datei
infra/main.tfvars
, um den Bereitstellungsprozess zu starten:Erstellen Sie in Ihrem Terminalfenster einen Ordner mit dem Namen
deploy-compute-engine
und rufen Sie ihn auf:mkdir ~/deploy-compute-engine cd ~/deploy-compute-engine
Klonen Sie das
copy-of-gcp-mig-simple
-Repo:gcloud source repos clone copy-of-mig-blue-green
Gehen Sie zum geklonten Verzeichnis:
cd ./copy-of-mig-blue-green
infra/main.tfvars
aktualisieren, um Blau durch Grün zu ersetzen:sed -i'' -e 's/blue/green/g' infra/main.tfvars
Fügen Sie die aktualisierte Datei hinzu:
git add .
Führen Sie mit der Datei ein Commit durch:
git commit -m "Promote green"
Übertragen Sie die Datei per Push:
git push
Wenn Sie Änderungen an
infra/main.tfvars
vornehmen, wird derapply
-Trigger ausgeführt, der die Bereitstellung startet.
Öffnen Sie Cloud Source Repositories:
Klicken Sie in der Liste der Repositories auf
copy-of-gcp-mig-simple
.Sie sehen den Commit mit der Beschreibung
Promote green
auf dem Tab Verlauf unten auf der Seite.Wenn Sie die Ausführung des
apply
-Triggers ansehen möchten, öffnen Sie in der Google Cloud Console die Seite Build-Verlauf:Öffnen Sie die Seite Build-Details, indem Sie auf den ersten Build klicken.
Sie sehen die Triggerpipeline
apply
mit zwei Build-Schritten. Der erste Build-Schritt führt Terraform apply aus, um die Compute Engine- und Load-Balancing-Ressourcen für die Bereitstellung zu erstellen. Im zweiten Build-Schritt wird die IP-Adresse ausgegeben, unter der Sie die ausgeführte Anwendung sehen können.Öffnen Sie die IP-Adresse der grünen MIG in einem Browser. Sie sehen einen Screenshot ähnlich dem folgenden, der die Bereitstellung zeigt:
Rufen Sie die Compute Engine-Seite Instanzgruppe auf, um die Instanzgruppen Blau und Grün zu sehen:
Öffnen Sie die Seite VM-Instanzen, um die vier VM-Instanzen zu sehen:
Öffnen Sie die Seite Externe IP-Adressen, um die drei Load-Balancer zu sehen:
Sie sehen zwei Build-Trigger mit den Namen apply
und destroy
. Der Trigger apply
ist an die Datei infra/main.tfvars
im Zweig main
angehängt. Dieser Trigger wird jedes Mal ausgeführt, wenn die Datei aktualisiert wird. Der destroy
-Trigger ist ein manueller Trigger.
Code verstehen
Der Quellcode für dieses Codebeispiel umfasst Folgendes:
- Quellcode für das Einrichtungsskript.
- Quellcode für die Cloud Build-Pipelines.
- Quellcode für die Terraform-Vorlagen.
Setup script
setup.sh
ist das Einrichtungsskript, das den Bootstrap-Prozess ausführt und die Komponenten für die Blau/Grün-Bereitstellung erstellt. Das Skript führt die folgenden Vorgänge aus:
- Die APIs Cloud Build, Resource Manager, Compute Engine und Cloud Source Repositories werden aktiviert.
- Gewährt dem Cloud Build-Dienstkonto in Ihrem Projekt die IAM-Rolle
roles/editor
. Diese Rolle ist erforderlich, damit Cloud Build die erforderlichen GitOps-Komponenten für die Bereitstellung erstellen und einrichten kann. - Gewährt dem Cloud Build-Dienstkonto in Ihrem Projekt die IAM-Rolle
roles/source.admin
. Diese Rolle ist für das Cloud Build-Dienstkonto erforderlich, um die Cloud Source Repositories in Ihrem Projekt zu erstellen und den Inhalt des GitHub-Beispiel-Repositorys in Ihre Cloud Source Repositories zu klonen. Generiert eine Cloud Build-Pipeline namens
bootstrap.cloudbuild.yaml
inline, die:- Erstellt ein neues Repository in Cloud Source Repositories.
- Kopiert den Quellcode aus dem Beispiel-GitHub-Repository in das neue Repository in Cloud Source Repositories.
- Erstellt die Build-Trigger für das Anwenden und Löschen.
Cloud Build-Pipelines
apply.cloudbuild.yaml
und destroy.cloudbuild.yaml
sind die Cloud Build-Konfigurationsdateien, mit denen das Einrichtungsskript die Ressourcen für den GitOps-Ablauf einrichtet. apply.cloudbuild.yaml
enthält zwei Build-Schritte:
- Build-Schritt
tf_apply build
, mit dem die Funktiontf_install_in_cloud_build_step
aufgerufen wird, mit der Terraform installiert wird.tf_apply
, der die im GitOps-Ablauf verwendeten Ressourcen erstellt. Die Funktionentf_install_in_cloud_build_step
undtf_apply
sind inbash_utils.sh
definiert und im Build-Schritt werden sie mit dem Befehlsource
aufgerufen. - Build-Schritt
describe_deployment
, der die Funktiondescribe_deployment
aufruft, die die IP-Adressen der Load-Balancer ausgibt.
destroy.cloudbuild.yaml
ruft tf_destroy
auf, um alle von tf_apply
erstellten Ressourcen zu löschen.
Die Funktionen tf_install_in_cloud_build_step
, tf_apply
, describe_deployment
und tf_destroy
sind in der Datei bash_utils.sh
definiert.
Die Build-Konfigurationsdateien verwenden den Befehl source
, um die Funktionen aufzurufen.
Der folgende Code zeigt die Funktion tf_install_in_cloud_build_step
, die in bash_utils.sh
definiert ist. Die Build-Konfigurationsdateien rufen diese Funktion auf, um Terraform spontan zu installieren. Es wird ein Cloud Storage-Bucket erstellt, um den Terraform-Status aufzuzeichnen.
Das folgende Code-Snippet zeigt die Funktion tf_apply
, die in bash_utils.sh
definiert ist. Zuerst wird terraform init
aufgerufen, das alle Module und benutzerdefinierten Bibliotheken lädt. Anschließend wird terraform apply
ausgeführt, um die Variablen aus der Datei main.tfvars
zu laden.
Das folgende Code-Snippet zeigt die Funktion describe_deployment
, die in bash_utils.sh
definiert ist. Sie verwendet gcloud compute addresses describe
, um die IP-Adressen der Load-Balancer anhand des Namens abzurufen, und gibt sie aus.
Das folgende Code-Snippet zeigt die Funktion tf_destroy
, die in bash_utils.sh
definiert ist. Er ruft terraform init
auf, der alle Module und benutzerdefinierten Bibliotheken lädt, und führt dann terraform destroy
aus, das die Terraform-Variablen entlädt.
Terraform-Vorlagen
Sie finden alle Terraform-Konfigurationsdateien und -variablen im Ordner copy-of-gcp-mig-simple/infra/
.
main.tf
: Das ist die Terraform-Konfigurationsdatei.main.tfvars
: Diese Datei definiert die Terraform-Variablen.mig/
undsplitter/
: Diese Ordner enthalten die Module, die die Load-Balancer definieren. Der Ordnermig/
enthält die Terraform-Konfigurationsdatei, die die MIG für die blauen und grünen Load-Balancer definiert. Die blauen und grünen MIGs sind identisch. Daher werden sie einmal definiert und für die blauen und grünen Objekte instanziiert. Die Terraform-Konfigurationsdatei für den Splitter-Load-Balancer befindet sich im Ordnersplitter/
.
Das folgende Code-Snippet zeigt den Inhalt von infra/main.tfvars
. Es enthält drei Variablen: zwei, die bestimmen, welche Anwendungsversion in den blauen und den grünen Pools bereitgestellt werden soll, und eine Variable für die aktive Farbe: Blau oder Grün. Änderungen an dieser Datei lösen die Bereitstellung aus.
Im Folgenden finden Sie ein Code-Snippet aus infra/main.tf
. Dabei gilt:
- Für das Google Cloud-Projekt ist eine Variable definiert.
- Google ist als Terraform-Anbieter festgelegt.
- Für den Namespace ist eine Variable definiert. Allen von Terraform erstellten Objekten wird diese Variable vorangestellt, sodass mehrere Versionen der Anwendung im selben Projekt bereitgestellt werden können und die Objektnamen sich nicht überschneiden.
- Die Variablen
MIG_VER_BLUE
,MIG_VER_BLUE
undMIG_ACTIVE_COLOR
sind die Bindungen für die Variablen in der Dateiinfra/main.tfvars
.
Das folgende Code-Snippet aus infra/main.tf
zeigt die Instanziierung des Splitter-Moduls. Dieses Modul verwendet die aktive Farbe, damit der Splitter-Load-Balancer weiß, welche MIG die Anwendung bereitstellen soll.
Das folgende Code-Snippet aus infra/main.tf
definiert zwei identische Module für blaue und grüne MIGs. Er nimmt die Farbe, das Netzwerk und das Subnetzwerk an, die im Splitter-Modul definiert sind.
Die Datei splitter/main.tf
definiert die Objekte, die für die Splitter-MIG erstellt werden. Das folgende Code-Snippet aus splitter/main.tf
enthält die Logik zum Wechseln zwischen der grünen und der blauen MIG. Sie wird vom Dienst google_compute_region_backend_service
unterstützt, der Traffic an zwei Back-End-Regionen weiterleiten kann: var.instance_group_blue
oder var.instance_group_green
.
capacity_scaler
definiert, wie viel Verkehr auf der Route verlaufen soll.
Mit dem folgenden Code werden 100% des Traffics an die angegebene Farbe weitergeleitet. Sie können diesen Code jedoch für das Canary-Deployment aktualisieren, um den Traffic an eine Teilmenge der Nutzer weiterzuleiten.
Die Datei mig/main.tf
definiert die Objekte, die zu den blauen und den grünen MIGs gehören. Das folgende Code-Snippet aus dieser Datei definiert die Compute Engine-Instanzvorlage, die zum Erstellen der VM-Pools verwendet wird. In dieser Instanzvorlage ist das Terraform-Lebenszyklusattribut auf create_before_destroy
festgelegt.
Das liegt daran, dass Sie beim Aktualisieren der Version des Pools die Vorlage nicht zum Erstellen der neuen Version der Pools verwenden können, wenn sie noch von der vorherigen Version des Pools verwendet wird. Wenn jedoch die ältere Version des Pools gelöscht wird, bevor die neue Vorlage erstellt wird, sind die Pools eine bestimmte Zeit lang nicht verfügbar. Um dieses Szenario zu vermeiden, legen wir den Terraform-Lebenszyklus auf create_before_destroy
fest. Damit wird die neuere Version eines VM-Pools erstellt, bevor die ältere Version gelöscht wird.
Bereinigen
Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.
Einzelne Ressourcen löschen
Löschen Sie die Compute Engine-Ressourcen, die mit dem Trigger zum Anwenden erstellt wurden:
Öffnen Sie die Cloud Build-Seite Trigger:
Suchen Sie in der Tabelle Trigger die Zeile, die dem Zerstörer-Trigger entspricht, und klicken Sie auf Ausführen. Wenn die Ausführung des Triggers abgeschlossen ist, werden die vom apply-Trigger erstellten Ressourcen gelöscht.
Löschen Sie die während des Bootstrapping erstellten Ressourcen. Führen Sie dazu den folgenden Befehl in Ihrem Terminalfenster aus:
bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/teardown.sh)
Projekt löschen
Google Cloud-Projekt löschen:
gcloud projects delete PROJECT_ID