Diese Seite wurde von der Cloud Translation API übersetzt.

Für Compute Engine bereitstellen

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:

Blau/Grün-Modell

Auf übergeordneter Ebene umfasst dieses Modell die folgenden Komponenten:

Zwei Compute Engine-VM-Pools: Blau und Grün.
Drei externe HTTP(S)-Load-Balancer: <ph type="x-smartling-placeholder">
- 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: <ph type="x-smartling-placeholder">
- 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 Lastenausgleichsmodule. 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:

Developer Operations-Ablauf

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 und destroy.

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. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

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

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.

Installieren Sie die Google Cloud CLI.

Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

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:

Seite „Build-Verlauf“ öffnen
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:

Cloud Source Repositories öffnen
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 Namen copy-of-gcp-mig-simple.
Öffnen Sie die Cloud Build-Seite Trigger:

Zur Seite "Trigger"

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.

Aktualisieren Sie die Datei infra/main.tfvars, um den Bereitstellungsprozess zu starten:
1. Erstellen Sie im Terminalfenster einen Ordner mit dem Namen deploy-compute-engine:
```
mkdir ~/deploy-compute-engine
cd ~/deploy-compute-engine
```
2. Klonen Sie das copy-of-gcp-mig-simple-Repo:
```
gcloud source repos clone copy-of-mig-blue-green
```
3. Rufen Sie das geklonte Verzeichnis auf:
```
cd ./copy-of-mig-blue-green
```
4. Aktualisieren Sie infra/main.tfvars, um Blau durch Grün zu ersetzen:
```
sed -i'' -e 's/blue/green/g' infra/main.tfvars
```
5. Fügen Sie die aktualisierte Datei hinzu:
```
git add .
```
6. Führen Sie mit der Datei ein Commit durch:
```
git commit -m "Promote green"
```
7. Übertragen Sie die Datei per Push:
```
git push
```
  Durch Änderungen an infra/main.tfvars wird die Ausführung von apply ausgelöst. Trigger, der das Deployment startet.
Öffnen Sie Cloud Source Repositories:

Cloud Source Repositories öffnen
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:

Seite „Build-Verlauf“ öffnen
Öffnen Sie die Seite Build-Details, indem Sie auf den ersten Build klicken.

Sie sehen die Triggerpipeline apply mit zwei Build-Schritten. Die 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:

Zur Seite "Instanzgruppe"
Öffnen Sie die Seite VM-Instanzen, um die vier VM-Instanzen zu sehen:

Zur Seite "VM-Instanzen"
Öffnen Sie die Seite Externe IP-Adressen, um die drei Load-Balancer anzuzeigen:

Zur Seite „Externe IP-Adressen“

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 dem 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.

set -e

BLUE='\033[1;34m'
RED='\033[1;31m'
GREEN='\033[1;32m'
NC='\033[0m'

echo -e "\n${GREEN}######################################################"
echo -e "#                                                    #"
echo -e "#  Zero-Downtime Blue/Green VM Deployments Using     #"
echo -e "#  Managed Instance Groups, Cloud Build & Terraform  #"
echo -e "#                                                    #"
echo -e "######################################################${NC}\n"

echo -e "\nSTARTED ${GREEN}setup.sh:${NC}"

echo -e "\nIt's ${RED}safe to re-run${NC} this script to ${RED}recreate${NC} all resources.\n"
echo "> Checking GCP CLI tool is installed"
gcloud --version > /dev/null 2>&1

readonly EXPLICIT_PROJECT_ID="$1"
readonly EXPLICIT_CONSENT="$2"

if [ -z "$EXPLICIT_PROJECT_ID" ]; then
    echo "> No explicit project id provided, trying to infer"
    PROJECT_ID="$(gcloud config get-value project)"
else
    PROJECT_ID="$EXPLICIT_PROJECT_ID"
fi

if [ -z "$PROJECT_ID" ]; then
    echo "ERROR: GCP project id was not provided as parameter and could not be inferred"
    exit 1
else
    readonly PROJECT_NUM="$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')"
    if [ -z "$PROJECT_NUM" ]; then
        echo "ERROR: GCP project number could not be determined"
        exit 1
    fi
    echo -e "\nYou are about to:"
    echo -e "  * modify project ${RED}${PROJECT_ID}/${PROJECT_NUM}${NC}"
    echo -e "  * ${RED}enable${NC} various GCP APIs"
    echo -e "  * make Cloud Build ${RED}editor${NC} of your project"
    echo -e "  * ${RED}execute${NC} Cloud Builds and Terraform plans to create"
    echo -e "  * ${RED}4 VMs${NC}, ${RED}3 load balancers${NC}, ${RED}3 public IP addresses${NC}"
    echo -e "  * incur ${RED}charges${NC} in your billing account as a result\n"
fi

if [ "$EXPLICIT_CONSENT" == "yes" ]; then
  echo "Proceeding under explicit consent"
  readonly CONSENT="$EXPLICIT_CONSENT"
else
    echo -e "Enter ${BLUE}'yes'${NC} if you want to proceed:"
    read CONSENT
fi

if [ "$CONSENT" != "yes" ]; then
    echo -e "\nERROR: Aborted by user"
    exit 1
else
    echo -e "\n......................................................"
    echo -e "\n> Received user consent"
fi

#
# Executes action with one randomly delayed retry.
#
function do_with_retry {
    COMMAND="$@"
    echo "Trying $COMMAND"
    (eval $COMMAND && echo "Success on first try") || ( \
        echo "Waiting few seconds to retry" &&
        sleep 10 && \
        echo "Retrying $COMMAND" && \
        eval $COMMAND \
    )
}

echo "> Enabling required APIs"
# Some of these can be enabled later with Terraform, but I personally
# prefer to do all API enablement in one place with gcloud.
gcloud services enable \
    --project=$PROJECT_ID \
    cloudbuild.googleapis.com \
    cloudresourcemanager.googleapis.com \
    compute.googleapis.com \
    sourcerepo.googleapis.com \
    --no-user-output-enabled \
    --quiet

echo "> Adding Cloud Build to roles/editor"
gcloud projects add-iam-policy-binding \
    "$PROJECT_ID" \
    --member="serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com" \
    --role='roles/editor' \
    --condition=None \
    --no-user-output-enabled \
    --quiet

echo "> Adding Cloud Build to roles/source.admin"
gcloud projects add-iam-policy-binding \
    "$PROJECT_ID" \
    --member="serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com" \
    --condition=None \
    --role='roles/source.admin' \
    --no-user-output-enabled \
    --quiet

echo "> Configuring bootstrap job"
rm -rf "./bootstrap.cloudbuild.yaml"
cat <<'EOT_BOOT' > "./bootstrap.cloudbuild.yaml"
tags:
- "mig-blue-green-bootstrapping"
steps:
- id: create_new_cloud_source_repo
  name: "gcr.io/cloud-builders/gcloud"
  script: |
    #!/bin/bash
    set -e

    echo "(Re)Creating source code repository"

    gcloud source repos delete \
        "copy-of-mig-blue-green" \
        --quiet || true

    gcloud source repos create \
        "copy-of-mig-blue-green" \
        --quiet

- id: copy_demo_source_into_new_cloud_source_repo
  name: "gcr.io/cloud-builders/gcloud"
  env:
    - "PROJECT_ID=$PROJECT_ID"
    - "PROJECT_NUMBER=$PROJECT_NUMBER"
  script: |
    #!/bin/bash
    set -e

    readonly GIT_REPO="https://github.com/GoogleCloudPlatform/cloud-build-samples.git"

    echo "Cloning demo source repo"
    mkdir /workspace/from/
    cd /workspace/from/
    git clone $GIT_REPO ./original
    cd ./original

    echo "Cloning new empty repo"
    mkdir /workspace/to/
    cd /workspace/to/
    gcloud source repos clone \
        "copy-of-mig-blue-green"
    cd ./copy-of-mig-blue-green

    echo "Making a copy"
    cp -r /workspace/from/original/mig-blue-green/* ./

    echo "Setting git identity"
    git config user.email \
        "$PROJECT_NUMBER@cloudbuild.gserviceaccount.com"
    git config user.name \
        "Cloud Build"

    echo "Commit & push"
    git add .
    git commit \
        -m "A copy of $GIT_REPO"
    git push

- id: add_pipeline_triggers
  name: "gcr.io/cloud-builders/gcloud"
  env:
    - "PROJECT_ID=$PROJECT_ID"
  script: |
    #!/bin/bash
    set -e

    echo "(Re)Creating destroy trigger"
    gcloud builds triggers delete "destroy" --quiet || true
    gcloud builds triggers create manual \
        --name="destroy" \
        --repo="https://source.developers.google.com/p/$PROJECT_ID/r/copy-of-mig-blue-green" \
        --branch="master" \
        --build-config="pipelines/destroy.cloudbuild.yaml" \
        --repo-type=CLOUD_SOURCE_REPOSITORIES \
        --quiet

    echo "(Re)Creating apply trigger"
    gcloud builds triggers delete "apply" --quiet || true
    gcloud builds triggers create cloud-source-repositories \
        --name="apply" \
        --repo="copy-of-mig-blue-green" \
        --branch-pattern="master" \
        --build-config="pipelines/apply.cloudbuild.yaml" \
        --included-files="infra/main.tfvars" \
        --quiet

EOT_BOOT

echo "> Waiting API enablement propagation"
do_with_retry "(gcloud builds list --project "$PROJECT_ID" --quiet && gcloud compute instances list --project "$PROJECT_ID" --quiet && gcloud source repos list --project "$PROJECT_ID" --quiet) > /dev/null 2>&1" > /dev/null 2>&1

echo "> Executing bootstrap job"
gcloud beta builds submit \
    --project "$PROJECT_ID" \
    --config ./bootstrap.cloudbuild.yaml \
    --no-source \
    --no-user-output-enabled \
    --quiet
rm ./bootstrap.cloudbuild.yaml

echo -e "\n${GREEN}All done. Now you can:${NC}"
echo -e "  * manually run 'apply' and 'destroy' triggers to manage deployment lifecycle"
echo -e "  * commit change to 'infra/main.tfvars' and see 'apply' pipeline trigger automatically"

echo -e "\n${GREEN}Few key links:${NC}"
echo -e "  * Dashboard: https://console.cloud.google.com/home/dashboard?project=$PROJECT_ID"
echo -e "  * Repo: https://source.cloud.google.com/$PROJECT_ID/copy-of-mig-blue-green"
echo -e "  * Cloud Build Triggers: https://console.cloud.google.com/cloud-build/triggers;region=global?project=$PROJECT_ID"
echo -e "  * Cloud Build History: https://console.cloud.google.com/cloud-build/builds?project=$PROJECT_ID"

echo -e "\n............................."

echo -e "\n${GREEN}COMPLETED!${NC}"

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 aufruft tf_install_in_cloud_build_step, zum Installieren von Terraform. tf_apply erstellt die im GitOps-Ablauf verwendeten Ressourcen. Die Funktionen tf_install_in_cloud_build_step und tf_apply sind definiert in bash_utils.sh und der Build-Schritt nutzt den Befehl source für den Aufruf .
describe_deployment-Build-Schritt, der die Funktion aufruft describe_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.

steps:
  - id: run-terraform-apply
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      tf_install_in_cloud_build_step
      tf_apply

  - id: describe-deployment
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      describe_deployment

tags:
  - "mig-blue-green-apply"

steps:
  - id: run-terraform-destroy
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      tf_install_in_cloud_build_step
      tf_destroy

tags:
  - "mig-blue-green-destroy"

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.

function tf_install_in_cloud_build_step {
    echo "Installing deps"
    apt update
    apt install \
        unzip \
        wget \
        -y

    echo "Manually installing Terraform"
    wget https://releases.hashicorp.com/terraform/1.3.4/terraform_1.3.4_linux_386.zip
    unzip -q terraform_1.3.4_linux_386.zip
    mv ./terraform /usr/bin/
    rm -rf terraform_1.3.4_linux_386.zip

    echo "Verifying installation"
    terraform -v

    echo "Creating Terraform state storage bucket $BUCKET_NAME"
    gcloud storage buckets create \
        "gs://$BUCKET_NAME" || echo "Already exists..."

    echo "Configure Terraform provider and state bucket"
cat <<EOT_PROVIDER_TF > "/workspace/infra/provider.tf"
terraform {
  required_version = ">= 0.13"
  backend "gcs" {
    bucket = "$BUCKET_NAME"
  }
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 3.77, < 5.0"
    }
  }
}
EOT_PROVIDER_TF

    echo "$(cat /workspace/infra/provider.tf)"
}

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.

function tf_apply {
    echo "Running Terraform init"
    terraform \
        -chdir="$TF_CHDIR" \
        init

    echo "Running Terraform apply"
    terraform \
        -chdir="$TF_CHDIR" \
        apply \
        -auto-approve \
        -var project="$PROJECT_ID" \
        -var-file="main.tfvars"
}

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.

function describe_deployment {
    NS="ns1-"
    echo -e "Deployment configuration:\n$(cat infra/main.tfvars)"
    echo -e \
      "Here is how to connect to:" \
      "\n\t* active color MIG: http://$(gcloud compute addresses describe ${NS}splitter-address-name --region=us-west1 --format='value(address)')/" \
      "\n\t* blue color MIG: http://$(gcloud compute addresses describe ${NS}blue-address-name --region=us-west1 --format='value(address)')/" \
      "\n\t* green color MIG: http://$(gcloud compute addresses describe ${NS}green-address-name --region=us-west1 --format='value(address)')/"
    echo "Good luck!"
}

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.

function tf_destroy {
    echo "Running Terraform init"
    terraform \
        -chdir="$TF_CHDIR" \
        init

    echo "Running Terraform destroy"
    terraform \
        -chdir="$TF_CHDIR" \
        destroy \
        -auto-approve \
        -var project="$PROJECT_ID" \
        -var-file="main.tfvars"
}

Terraform-Vorlagen

Alle Terraform-Konfigurationsdateien und -Variablen finden Sie in der Ordner „copy-of-gcp-mig-simple/infra/“.

main.tf: Dies ist die Terraform-Konfigurationsdatei.
main.tfvars: Diese Datei definiert die Terraform-Variablen.
mig/ und splitter/: Diese Ordner enthalten die Module, die die Lastenausgleichsmodule. Der Ordner mig/ 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 Ordner splitter/ .

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.

MIG_VER_BLUE     = "v1"
MIG_VER_GREEN    = "v1"
MIG_ACTIVE_COLOR = "blue"

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 und MIG_ACTIVE_COLOR sind die Bindungen für die Variablen in der Datei infra/main.tfvars.

variable "project" {
  type        = string
  description = "GCP project we are working in."
}

provider "google" {
  project = var.project
  region  = "us-west1"
  zone    = "us-west1-a"
}

variable "ns" {
  type        = string
  default     = "ns1-"
  description = "The namespace used for all resources in this plan."
}

variable "MIG_VER_BLUE" {
  type        = string
  description = "Version tag for 'blue' deployment."
}

variable "MIG_VER_GREEN" {
  type        = string
  description = "Version tag for 'green' deployment."
}

variable "MIG_ACTIVE_COLOR" {
  type        = string
  description = "Active color (blue | green)."
}

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.

module "splitter-lb" {
  source               = "./splitter"
  project              = var.project
  ns                   = "${var.ns}splitter-"
  active_color         = var.MIG_ACTIVE_COLOR
  instance_group_blue  = module.blue.google_compute_instance_group_manager_default.instance_group
  instance_group_green = module.green.google_compute_instance_group_manager_default.instance_group
}

Mit dem folgenden Code-Snippet aus infra/main.tf werden zwei identische Module definiert für blaue und grüne MIGs. Sie berücksichtigt die Farbe, das Netzwerk und das Subnetzwerk. die im Splitter-Modul definiert sind.

module "blue" {
  source                               = "./mig"
  project                              = var.project
  app_version                          = var.MIG_VER_BLUE
  ns                                   = var.ns
  color                                = "blue"
  google_compute_network               = module.splitter-lb.google_compute_network
  google_compute_subnetwork            = module.splitter-lb.google_compute_subnetwork_default
  google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only
}

module "green" {
  source                               = "./mig"
  project                              = var.project
  app_version                          = var.MIG_VER_GREEN
  ns                                   = var.ns
  color                                = "green"
  google_compute_network               = module.splitter-lb.google_compute_network
  google_compute_subnetwork            = module.splitter-lb.google_compute_subnetwork_default
  google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only
}

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.

resource "google_compute_region_backend_service" "default" {
  name                  = local.l7-xlb-backend-service
  region                = "us-west1"
  load_balancing_scheme = "EXTERNAL_MANAGED"
  health_checks         = [google_compute_region_health_check.default.id]
  protocol              = "HTTP"
  session_affinity      = "NONE"
  timeout_sec           = 30
  backend {
    group           = var.instance_group_blue
    balancing_mode  = "UTILIZATION"
    capacity_scaler = var.active_color == "blue" ? 1 : 0
  }
  backend {
    group           = var.instance_group_green
    balancing_mode  = "UTILIZATION"
    capacity_scaler = var.active_color == "green" ? 1 : 0
  }
}

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.

resource "google_compute_instance_template" "default" {
  name = local.l7-xlb-backend-template
  disk {
    auto_delete  = true
    boot         = true
    device_name  = "persistent-disk-0"
    mode         = "READ_WRITE"
    source_image = "projects/debian-cloud/global/images/family/debian-10"
    type         = "PERSISTENT"
  }
  labels = {
    managed-by-cnrm = "true"
  }
  machine_type = "n1-standard-1"
  metadata = {
    startup-script = <<EOF
    #! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    sudo echo "<html><body style='font-family: Arial; margin: 64px; background-color: light${var.color};'><h3>Hello, World!<br><br>version: ${var.app_version}<br>ns: ${var.ns}<br>hostname: $vm_hostname</h3></body></html>" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2
    EOF
  }
  network_interface {
    access_config {
      network_tier = "PREMIUM"
    }
    network    = var.google_compute_network.id
    subnetwork = var.google_compute_subnetwork.id
  }
  region = "us-west1"
  scheduling {
    automatic_restart   = true
    on_host_maintenance = "MIGRATE"
    provisioning_model  = "STANDARD"
  }
  tags = ["load-balanced-backend"]

  # NOTE: the name of this resource must be unique for every update;
  #       this is wy we have a app_version in the name; this way
  #       new resource has a different name vs old one and both can
  #       exists at the same time
  lifecycle {
    create_before_destroy = true
  }
}

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:
1. Öffnen Sie die Cloud Build-Seite Trigger:
  
  Zur Seite "Trigger"
2. 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

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Google Cloud-Projekt löschen:

gcloud projects delete PROJECT_ID