In diesem Leitfaden wird erläutert, wie Sie Blau/Grün-Bereitstellungen ohne Ausfallzeiten für Von Compute Engine verwaltete Instanzgruppen (MIGs) mit Cloud Build und Terraform
Mit Cloud Build können Sie Entwicklungsprozesse automatisieren, z. B. Anwendungen für verschiedene Google Cloud-Laufzeiten erstellen und bereitstellen wie Compute Engine, Google Kubernetes Engine GKE Enterprise und Cloud Functions.
Compute Engine-MIGs ermöglichen Ihnen den Betrieb Anwendungen auf mehreren identischen virtuellen Maschinen (VMs) erstellt. Sie können Ihre Skalierbare und hochverfügbare Arbeitslasten durch Nutzung automatisierter MIGs Dienste, einschließlich: Autoscaling, automatische Reparatur, regional (mehrere Zonen) Bereitstellung und automatische Updates. Kontinuierliche Blau/Grün-Bereitstellung verwenden erfahren Sie, wie Sie den Nutzertraffic schrittweise von einer verwalteten Instanzgruppe übertragen (blau) zu einer anderen MIG (grün), die beide in der Produktion ausgeführt werden.
Designübersicht
Das folgende Diagramm zeigt das Blau/Grün-Bereitstellungsmodell, das vom Code verwendet wird in diesem Dokument beschriebene Beispiel:
Auf übergeordneter Ebene 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 Traffic von Endnutzern entweder an den blauen oder grünen Pool von VM-Instanzen.
- Ein blauer Load Balancer, der Traffic von QA-Entwicklern und zum Pool der Blue-VM-Instanz hinzu.
- Ein grüner Load Balancer, der Traffic von QA-Entwicklern und an den Instanzpool „Green“ zu arbeiten.
- Zwei Nutzergruppen:
- Endnutzer mit Zugriff auf das Blau/Grün-Lastenausgleichsmodul, das entweder zum blauen oder zum grünen Instanzpool.
- QA-Entwickler und -Entwickler, die Zugriff auf beide Gruppen von Pools für zu Entwicklungs- und Testzwecken. Sie können sowohl auf das blaue als auch auf das Green Load Balancer, der sie an den Pool der blauen Instanz und den Grüner Instanzpool.
Die blauen und grünen VM-Pools sind als Compute Engine-MIGs implementiert. Externe IP-Adressen werden über externe HTTP(s) an die VMs in der MIG weitergeleitet Load Balancern. Im Codebeispiel in diesem Dokument wird Terraform verwendet, um um diese Infrastruktur zu konfigurieren.
Das folgende Diagramm veranschaulicht die Entwicklervorgänge, die in der Bereitstellung:
Im obigen Diagramm stellen die roten Pfeile den Bootstrapping-Ablauf dar, erfolgt, wenn Sie die Bereitstellungsinfrastruktur zum ersten Mal einrichten und der blaue Pfeile stellen den GitOps-Ablauf dar, der bei jeder Bereitstellung stattfindet.
Zum Einrichten dieser Infrastruktur führen Sie ein Setupskript aus, das den Bootstrap startet und richtet die Komponenten für den GitOps-Ablauf ein.
Das Setupskript führt eine Cloud Build-Pipeline aus, die den folgende Vorgänge:
- Erstellt ein Repository in Cloud Source Repositories
mit dem Namen
copy-of-gcp-mig-simple
und kopiert den Quellcode aus GitHub Beispiel-Repository in das Repository in Cloud Source Repositories. - Es werden zwei Cloud Build-Trigger mit dem Namen erstellt.
apply
unddestroy
.
Der Trigger apply
ist an eine Terraform-Datei namens main.tfvars
im
Cloud Source Repositories erstellen. Diese Datei enthält die Terraform-Variablen, die für
die blauen und die grünen Load Balancer.
Aktualisieren Sie die Variablen in der Datei main.tfvars
, um die Bereitstellung einzurichten.
Der Trigger apply
führt eine Cloud Build-Pipeline aus, die
tf_apply
und führt die folgenden Vorgänge aus:
- Es werden zwei Compute Engine-MIGs erstellt (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 verwaltete Instanzgruppe) der verwalteten Instanzgruppe), den drei Load-Balancern (blau, grün und der Splitter) sowie drei öffentliche IP-Adressen.
- Gibt die IP-Adressen aus, mit denen Sie die bereitgestellten Daten sehen können in den blauen und grünen Instanzen.
Der Trigger zum Löschen wird manuell ausgelöst, um alle Ressourcen zu löschen, die von den Trigger „Apply“ (Anwenden) an.
Lernziele
Mit Cloud Build und Terraform einen externen HTTP(S)-Ladevorgang einrichten Balancern mit Back-Ends von Compute Engine-VM-Instanzgruppen.
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.
- 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.
-
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
- 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.
-
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
Testen
Führen Sie das Setup-Skript 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.
Die Ausführung des Skripts ist in wenigen Sekunden abgeschlossen.
Öffnen Sie in der Google Cloud Console den Cloud Build-Build-Verlauf. Seite:
Klicken Sie auf den neuesten Build.
Sie sehen die Seite Build-Details mit einem Cloud Build- eine Pipeline mit drei Build-Schritten: Im ersten Build-Schritt wird ein Repository in Cloud Source Repositories wird im zweiten Schritt der Inhalt des Beispiels geklont. Repository in GitHub zu Cloud Source Repositories hinzufügen. Im dritten Schritt werden Build-Trigger.
Ö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 ein Commit mit die Beschreibung
A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git
das von Cloud Build erstellt wurde, um ein Repository mit dem Namencopy-of-gcp-mig-simple
.Öffnen Sie die Cloud Build-Seite Trigger:
Aktualisieren Sie die Datei
infra/main.tfvars
, um den Bereitstellungsprozess zu starten:Erstellen Sie im Terminalfenster einen Ordner mit dem Namen
deploy-compute-engine
: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
Rufen Sie das geklonte Verzeichnis auf:
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
Durch Änderungen an
infra/main.tfvars
wird die Ausführung vonapply
ausgelöst. Trigger, der das Deployment startet.
Öffnen Sie Cloud Source Repositories:
Klicken Sie in der Liste der Repositories auf
copy-of-gcp-mig-simple
.Das Commit mit der Beschreibung
Promote green
wird in der Verlauf.Öffnen Sie die Seite Build-Verlauf, um die Ausführung des Triggers
apply
anzusehen in der Google Cloud Console:Öffnen Sie die Seite Build-Details, indem Sie auf den ersten Build klicken.
Sie sehen die Triggerpipeline
apply
mit zwei Build-Schritten. Das erste den Build-Schritt führt Terraform apply aus, um die Compute Engine zu erstellen und Ressourcen für die Bereitstellung ausgleichen können. Der zweite Build-Schritt wird gedruckt die IP-Adresse, unter der Sie die ausgeführte Anwendung sehen können.Öffnen Sie die IP-Adresse der grünen MIG in einem Browser. Sie sehen dann Screenshot der Bereitstellung:
Rufen Sie die Compute Engine-Seite Instanzgruppe auf, um das Blau und das Grüne Instanzgruppen:
Ö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 anzuzeigen:
Sie sehen zwei Build-Trigger mit den Namen apply
und destroy
. Der apply
-Trigger
ist an die Datei infra/main.tfvars
im Zweig main
angehängt. Dieser Trigger
wird bei jeder Aktualisierung der Datei ausgeführt. Der destroy
-Trigger ist ein manueller
auslösen.
Code verstehen
Der Quellcode für dieses Codebeispiel enthält:
- Quellcode, der sich auf das Setup-Skript bezieht.
- Quellcode für die Cloud Build-Pipelines.
- Quellcode, der sich auf die Terraform-Vorlagen bezieht.
Einrichtungsskript
setup.sh
ist das Setup-Skript, das den Bootstrap-Prozess ausführt und das
für die Blau/Grün-Bereitstellung. Das Skript führt Folgendes aus:
Betriebsabläufe:
- Aktiviert Cloud Build, Resource Manager, Compute Engine und Cloud Source Repositories APIs.
- Gewährt die IAM-Rolle
roles/editor
für das Cloud Build-Dienstkonto in Ihrem Projekt. Diese Rolle ist damit Cloud Build die erforderlichen GitOps-Komponenten für die Bereitstellung - Gewährt die IAM-Rolle
roles/source.admin
für das Cloud Build-Dienstkonto in Ihrem Projekt. Diese Rolle ist erforderlich, damit das Cloud Build-Dienstkonto die Cloud Source Repositories in Ihrem Projekt und klonen Sie den Inhalt des Beispiels GitHub-Repository zu Ihren Cloud Source Repositories hinzufügen. Generiert eine Cloud Build-Pipeline mit dem Namen
bootstrap.cloudbuild.yaml
enthalten, die:- Erstellt ein neues Repository in Cloud Source Repositories.
- Es kopiert den Quellcode aus dem GitHub-Beispiel-Repository in den neue Repository in Cloud Source Repositories.
- Erstellt die Build-Trigger zum Anwenden und Löschen.
Cloud Build-Pipelines
apply.cloudbuild.yaml
und destroy.cloudbuild.yaml
sind die
Cloud Build-Konfigurationsdateien, mit denen das Setupskript die
für den GitOps-Ablauf. apply.cloudbuild.yaml
enthält zwei Build-Schritte:
tf_apply build
-Build-Schritt, der die Funktion aufrufttf_install_in_cloud_build_step
, zum Installieren von Terraform.tf_apply
erstellt die im GitOps-Ablauf verwendeten Ressourcen. Die Funktionentf_install_in_cloud_build_step
undtf_apply
sind definiert inbash_utils.sh
und der Build-Schritt nutzt den Befehlsource
für den Aufruf .describe_deployment
-Build-Schritt, der die Funktion aufruftdescribe_deployment
, die die IP-Adressen der Last ausgibt Balancern.
destroy.cloudbuild.yaml
ruft tf_destroy
auf, wodurch alle Ressourcen gelöscht werden.
erstellt von tf_apply
.
Mit den 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 rufen die Funktionen mit dem Befehl source
auf.
Der folgende Code zeigt die Funktion tf_install_in_cloud_build_step
, die
definiert in bash_utils.sh
. Die Build-Konfigurationsdateien rufen diese Funktion auf,
Terraform direkt zu installieren. Es wird ein Cloud Storage-Bucket erstellt,
notieren Sie sich den Terraform-Status.
Das folgende Code-Snippet zeigt die Funktion tf_apply
, die in
bash_utils.sh
. Zuerst wird terraform init
aufgerufen, wodurch alle Module und
benutzerdefinierte Bibliotheken und führt dann terraform apply
aus,
main.tfvars
-Datei.
Das folgende Code-Snippet zeigt die Funktion describe_deployment
,
definiert in bash_utils.sh
. gcloud compute addresses describe
wird zum Abrufen
die IP-Adressen der
Load-Balancer anhand des Namens aus und gibt sie aus.
Das folgende Code-Snippet zeigt die Funktion tf_destroy
, die in
bash_utils.sh
. Sie ruft terraform init
auf, wodurch alle Module und benutzerdefinierten
Bibliotheken und führt dann terraform destroy
aus, um die Terraform-Variablen zu entladen.
Terraform-Vorlagen
Alle Terraform-Konfigurationsdateien und -Variablen finden Sie in der
copy-of-gcp-mig-simple/infra/
-Ordner.
main.tf
: Dies ist die Terraform-Konfigurationsdatei.main.tfvars
: Diese Datei definiert die Terraform-Variablen.mig/
undsplitter/
: Diese Ordner enthalten die Module, die die Load Balancern. Der Ordnermig/
enthält die Terraform-Konfigurationsdatei definiert die MIG für die blauen und grünen Load-Balancer. Das blaue und Die grünen MIGs sind identisch, daher werden sie einmal definiert und für die blauen und die grünen Objekte instanziiert. Die Terraform-Konfiguration 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 bestimmen, welche Anwendungsversion bereitgestellt wird
Blau und Grün sowie eine Variable für die aktive Farbe: Blau oder
Grün. Änderungen an dieser Datei lösen die Bereitstellung aus.
Das folgende Code-Snippet stammt von infra/main.tf
. In diesem Snippet 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. Alle von Terraform erstellten Objekte werden Variable vorangestellt, sodass mehrere Versionen der Anwendung im selben Projekt bereitgestellt werden und die Objektnamen sich nicht Sonstiges.
- 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 der
Splitter-Modul. Dieses Modul übernimmt die aktive Farbe,
weiß, welche MIG die Anwendung bereitstellen soll.
Mit dem folgenden Code-Snippet aus infra/main.tf
werden zwei identische Module definiert
für blaue und grüne MIGs. Dabei werden die Farbe, das Netzwerk und das Subnetzwerk
die im Splitter-Modul definiert sind.
Die Datei splitter/main.tf
definiert die Objekte, die für den
Splitter-MIG. Das folgende Code-Snippet von splitter/main.tf
enthält
enthält die Logik für den Wechsel zwischen der grünen und der blauen MIG. Es wird durch
dem Dienst google_compute_region_backend_service
, der Traffic weiterleiten kann,
Zwei Back-End-Regionen: var.instance_group_blue
oder var.instance_group_green
.
capacity_scaler
definiert, welcher Anteil des Traffics weitergeleitet wird.
Mit dem folgenden Code werden 100% des Traffics zur angegebenen Farbe weitergeleitet. Sie können jedoch können Sie diesen Code für das Canary-Deployment aktualisieren, um den Traffic die Nutzenden.
In der Datei mig/main.tf
sind die Objekte definiert, die zum Blau und Grün gehören.
MIGs. Das folgende Code-Snippet aus dieser Datei definiert die Compute Engine
Instanzvorlage zum Erstellen der VM-Pools. Beachten Sie, dass diese Instanz
Das Terraform-Lebenszyklusattribut der Vorlage ist auf create_before_destroy
festgelegt.
Das liegt daran, dass Sie beim Aktualisieren der Version des Pools nicht die Methode
Vorlage zum Erstellen der neuen Version der Pools, wenn diese noch von
der vorherigen Version des Pools. Wenn jedoch die ältere Version des Pools
vor dem Erstellen der neuen Vorlage gelöscht wurde,
die Pools ausgefallen sind. Um dies zu vermeiden, legen wir für den Terraform-Lebenszyklus
create_before_destroy
, 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 Compute Engine-Ressourcen, die vom Apply-Trigger erstellt wurden:
Öffnen Sie die Cloud Build-Seite Trigger:
Suchen Sie in der Tabelle Trigger die Zeile mit dem Befehl delete. und klicken Sie auf Ausführen. Wenn der Trigger die Ausführung abgeschlossen hat, Ressourcen, die vom apply-Trigger erstellt wurden, werden gelöscht.
Löschen Sie die beim Bootstrapping erstellten Ressourcen. Führen Sie dazu folgenden Befehl aus: im Terminalfenster:
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