In diesem Leitfaden erfahren Sie, wie Sie mit Cloud Build und Terraform Blau/Grün-Bereitstellungen ohne Ausfallzeiten in Compute Engine-verwalteten Instanzgruppen (Managed Instance Groups, MIGs) durchführen.
Mit Cloud Build können Sie eine Vielzahl von Entwicklerprozessen automatisieren, z. B. das Erstellen und Bereitstellen von Anwendungen in verschiedenen Google Cloud Laufzeitumgebungen wie Compute Engine, Google Kubernetes Engine, GKE Enterprise und Cloud Run-Funktionen.
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 Aktualisierung. Mit dem Blue/Green-Modell für die kontinuierliche Bereitstellung erfahren Sie, wie Sie den Nutzertraffic schrittweise von einer MIG (blau) auf eine andere MIG (grün) übertragen, die beide in der Produktion ausgeführt werden.
Designübersicht
Das folgende Diagramm zeigt das Blau/Grün-Bereitstellungsmodell, das in dem in diesem Dokument beschriebenen Codebeispiel verwendet wird:
Dieses Modell umfasst 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 an den blauen oder den grünen Pool von VM-Instanzen weiterleitet.
- Ein blauer Load Balancer, der Traffic von QA-Ingenieuren und Entwicklern an den Blue-VM-Instanzpool weiterleitet.
- Ein grüner Load Balancer, der Traffic von QA-Ingenieuren 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-Ingenieure und Entwickler, die für Entwicklungs- und Testzwecke Zugriff auf beide Pools benötigen. Sie können sowohl auf den blauen als auch auf den grünen Load Balancer zugreifen, die sie jeweils an den blauen und den grünen Instanzpool weiterleiten.
Die Blue- und Green-VM-Pools werden als Compute Engine-MIGs implementiert und externe IP-Adressen werden über externe HTTP(S)-Load Balancer an die VMs in der MIG weitergeleitet. Im in diesem Dokument beschriebenen Codebeispiel wird Terraform verwendet, um diese Infrastruktur zu konfigurieren.
Das folgende Diagramm veranschaulicht die Entwickleraktionen, die bei der Bereitstellung ausgeführt werden:
Im Diagramm oben stehen die roten Pfeile für den Bootstrapping-Vorgang, der beim ersten Einrichten der Bereitstellungsinfrastruktur ausgeführt wird. Die blauen Pfeile stehen für den GitOps-Vorgang, der bei jeder Bereitstellung ausgeführt wird.
Um diese Infrastruktur einzurichten, führen Sie ein Einrichtungsskript aus, das den Bootstrap-Prozess startet und die Komponenten für den GitOps-Workflow einrichtet.
Das Setup-Script führt eine Cloud Build-Pipeline aus, die die folgenden Vorgänge ausführt:
- Erstellen Sie ein Repository in Cloud Source Repositories mit dem Namen
copy-of-gcp-mig-simple
und kopieren Sie den Quellcode aus dem GitHub-Beispielrepository in das Repository in Cloud Source Repositories. - Es werden zwei Cloud Build-Trigger mit den Namen
apply
unddestroy
erstellt.
Der Trigger apply
ist mit einer Terraform-Datei namens main.tfvars
in Cloud Source Repositories verknüpft. Diese Datei enthält die Terraform-Variablen für den blauen und den grünen Load Balancer.
Zum Einrichten der Bereitstellung aktualisieren Sie die Variablen in der Datei main.tfvars
.
Der apply
-Trigger führt eine Cloud Build-Pipeline aus, die tf_apply
ausführt und die folgenden Vorgänge ausführt:
- Es werden 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 der Splitter) und drei öffentliche IP-Adressen erstellt.
- Hier werden die IP-Adressen ausgegeben, mit denen Sie die bereitgestellten Anwendungen in der blauen und der grünen Instanz aufrufen können.
Der Destroy-Trigger wird manuell ausgelöst, um alle vom Apply-Trigger erstellten Ressourcen zu löschen.
Lernziele
Mit Cloud Build und Terraform externe HTTP(S)-Load Balancer mit Compute Engine-VM-Instanzgruppen-Back-Ends einrichten
Führen Sie Blau/Grün-Bereitstellungen auf den VM-Instanzen durch.
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
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Make sure that billing is enabled for your Google Cloud project.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Make sure that billing is enabled for your Google Cloud project.
Testen
Führen Sie das Einrichtungsskript aus dem Google-Repository für Codebeispiele aus:
bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)
Wenn das Einrichtungsskript um die Nutzereinwilligung bittet, geben Sie yes ein.
Die Ausführung des Scripts dauert nur wenige Sekunden.
Öffnen Sie in der Google Cloud Console die Seite Build-Verlauf von Cloud Build:
Klicken Sie auf den neuesten Build.
Die Seite Build-Details wird angezeigt. Darauf ist eine Cloud Build-Pipeline mit drei Build-Schritten zu sehen: Im ersten Build-Schritt wird ein Repository in Cloud Source Repositories erstellt, im 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 sehen Sie einen Commit mit der Beschreibung
A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git
, der von Cloud Build erstellt wurde, um ein Repository namenscopy-of-gcp-mig-simple
zu erstellen.Öffnen Sie in Cloud Build die 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 wechseln Sie zu diesem: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
Wechseln Sie zum geklonten Verzeichnis:
cd ./copy-of-mig-blue-green
Aktualisieren Sie
infra/main.tfvars
, 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 der Triggerapply
ausgeführt, wodurch die Bereitstellung gestartet wird.
Öffnen Sie Cloud Source Repositories:
Klicken Sie in der Liste der Repositories auf
copy-of-gcp-mig-simple
.Der Commit mit der Beschreibung
Promote green
wird unten auf der Seite auf dem Tab Verlauf angezeigt.Wenn Sie die Ausführung des
apply
-Triggers ansehen möchten, öffnen Sie in der Google Cloud Console die Seite Build-Verlauf:Klicken Sie auf den ersten Build, um die Seite Build-Details zu öffnen.
Sie sehen die Trigger-Pipeline
apply
mit zwei Build-Schritten. Im ersten Buildschritt wird Terraform apply ausgeführt, um die Compute Engine zu erstellen und Ressourcen für die Bereitstellung auszugleichen. Im zweiten Build-Schritt wird die IP-Adresse ausgegeben, unter der die Anwendung ausgeführt wird.Öffnen Sie die IP-Adresse, die der grünen MIG entspricht, in einem Browser. Sie sehen einen Screenshot, der der folgenden Abbildung ähnelt:
Rufen Sie die Seite Instanzgruppe der Compute Engine auf, um die blaue und die grüne Instanzgruppe 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 apply
-Trigger ist der Datei infra/main.tfvars
im Branch main
angehängt. Dieser Trigger wird jedes Mal ausgeführt, wenn die Datei aktualisiert wird. Der Trigger destroy
ist ein manueller Trigger.
Code verstehen
Der Quellcode für dieses Codebeispiel enthält:
- Quellcode, der sich auf das Einrichtungsskript bezieht.
- Quellcode im Zusammenhang mit den Cloud Build-Pipelines.
- Quellcode zu den Terraform-Vorlagen.
Einrichtungsskript
setup.sh
ist das Einrichtungsskript, das den Bootstrap-Prozess ausführt und die Komponenten für die Blau/Grün-Bereitstellung erstellt. Das Script führt die folgenden Vorgänge aus:
- Aktiviert die Cloud Build API, die Resource Manager API, die Compute Engine API und die Cloud Source Repositories API.
- Weisen Sie dem Cloud Build-Dienstkonto in Ihrem Projekt die IAM-Rolle
roles/editor
zu. Diese Rolle ist erforderlich, damit Cloud Build die erforderlichen GitOps-Komponenten für die Bereitstellung erstellen und einrichten kann. - Dem Cloud Build-Dienstkonto in Ihrem Projekt wird die IAM-Rolle
roles/source.admin
zugewiesen. Diese Rolle ist für das Cloud Build-Dienstkonto erforderlich, um die Cloud Source Repositories in Ihrem Projekt zu erstellen und den Inhalt des Beispiel-GitHub-Repositories in Ihre Cloud Source Repositories zu klonen. Er generiert eine Cloud Build-Pipeline namens
bootstrap.cloudbuild.yaml
inline, die Folgendes enthält:- Erstellt ein neues Repository in Cloud Source Repositories.
- Der Quellcode wird aus dem Beispiel-GitHub-Repository in das neue Repository in Cloud Source Repositories kopiert.
- Erstellt die Build-Trigger „apply“ und „destroy“.
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-Vorgang einrichtet. apply.cloudbuild.yaml
enthält zwei Build-Schritte:
tf_apply build
-Buildschritt, der die Funktiontf_install_in_cloud_build_step
aufruft, über die Terraform installiert wirdtf_apply
, mit dem die im GitOps-Ablauf verwendeten Ressourcen erstellt werden. Die Funktionentf_install_in_cloud_build_step
undtf_apply
sind inbash_utils.sh
definiert und werden im Build-Schritt mit dem Befehlsource
aufgerufen.describe_deployment
-Buildschritt, der die Funktiondescribe_deployment
aufruft, die die IP-Adressen der Load Balancer ausgibt.
destroy.cloudbuild.yaml
ruft tf_destroy
auf, wodurch alle von tf_apply
erstellten Ressourcen gelöscht werden.
Die Funktionen tf_install_in_cloud_build_step
, tf_apply
, describe_deployment
und tf_destroy
sind in der Datei bash_utils.sh
definiert.
In den Build-Konfigurationsdateien werden die Funktionen mit dem Befehl source
aufgerufen.
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 direkt zu installieren. Es wird ein Cloud Storage-Bucket erstellt, um den Terraform-Status zu erfassen.
Das folgende Code-Snippet zeigt die Funktion tf_apply
, die in bash_utils.sh
definiert ist. Zuerst wird terraform init
aufgerufen, um alle Module und benutzerdefinierten Bibliotheken zu laden. 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. Es verwendet gcloud compute addresses describe
, um die IP-Adressen der Load Balancer anhand des Namens abzurufen und auszugeben.
Das folgende Code-Snippet zeigt die Funktion tf_destroy
, die in bash_utils.sh
definiert ist. Es ruft terraform init
auf, wodurch alle Module und benutzerdefinierten Bibliotheken geladen werden, und führt dann terraform destroy
aus, wodurch die Terraform-Variablen entladen werden.
Terraform-Vorlagen
Alle Terraform-Konfigurationsdateien und ‑Variablen finden Sie im Ordner copy-of-gcp-mig-simple/infra/
.
main.tf
: Dies ist die Terraform-Konfigurationsdatei.main.tfvars
: In dieser Datei werden die Terraform-Variablen definiert.mig/
undsplitter/
: Diese Ordner enthalten die Module, die die Load Balancer definieren. Der Ordnermig/
enthält die Terraform-Konfigurationsdatei, in der die MIG für den blauen und den grünen Load Balancer definiert wird. 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 festlegen, welche Anwendungsversion im blauen und im grünen Pool 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
. In diesem Snippet:
- Für das Google Cloud-Projekt ist eine Variable definiert.
- Google ist als Terraform-Anbieter festgelegt.
- Für den Namespace ist eine Variable definiert. Alle von Terraform erstellten Objekte werden mit dieser Variablen vorangestellt, damit mehrere Versionen der Anwendung im selben Projekt bereitgestellt werden können und die Objektnamen nicht miteinander kollidieren.
- Die Variablen
MIG_VER_BLUE
,MIG_VER_BLUE
undMIG_ACTIVE_COLOR
sind die Bindungen für die Variablen in derinfra/main.tfvars
-Datei.
Das folgende Code-Snippet aus infra/main.tf
zeigt die Instanziierung des Splitter-Moduls. Dieses Modul nimmt die aktive Farbe auf, damit der Load Balancer des Splitters weiß, in welcher verwalteten Instanzgruppe die Anwendung bereitgestellt werden soll.
Im folgenden Code-Snippet aus infra/main.tf
werden zwei identische Module für Blue- und Green-MIGs definiert. Es nimmt die Farbe, das Netzwerk und das Subnetzwerk an, die im Splittermodul definiert sind.
Die Datei splitter/main.tf
definiert die Objekte, die für die Splitter-MIG erstellt werden. Im folgenden Code-Snippet aus splitter/main.tf
ist die Logik zum Wechseln zwischen der grünen und der blauen MIG enthalten. Er 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
legt fest, wie viel Traffic weitergeleitet werden soll.
Der folgende Code leitet 100% des Traffics an die angegebene Farbe weiter. Sie können diesen Code jedoch für die Canary-Bereitstellung aktualisieren, um den Traffic an eine Teilmenge der Nutzer weiterzuleiten.
Die Datei mig/main.tf
definiert die Objekte, die zu den blauen und grünen MIGs gehören. Im folgenden Code-Snippet aus dieser Datei wird die Compute Engine-Instanzvorlage definiert, die zum Erstellen der VM-Pools verwendet wird. Beachten Sie, dass für diese Instanzvorlage die Terraform-Lebenszykluseigenschaft auf create_before_destroy
festgelegt ist.
Das liegt daran, dass Sie 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 die ältere Version des Pools jedoch vor dem Erstellen der neuen Vorlage gelöscht wird, sind die Pools für einen bestimmten Zeitraum nicht verfügbar. Um dieses Szenario zu vermeiden, haben wir den Terraform-Lebenszyklus auf create_before_destroy
festgelegt, damit die neuere Version eines VM-Pools zuerst erstellt wird, 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 vom Trigger „apply“ erstellten Compute Engine-Ressourcen:
Öffnen Sie in Cloud Build die Seite Trigger:
Suchen Sie in der Tabelle Trigger nach der Zeile, die dem Trigger destroy entspricht, und klicken Sie auf Ausführen. Nach Abschluss der Ausführung des Triggers werden die vom Trigger apply erstellten Ressourcen gelöscht.
Löschen Sie die beim 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
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID