Für Compute Engine bereitstellen

In diesem Leitfaden wird beschrieben, wie Sie mit Cloud Build und Terraform Blau/Grün-Bereitstellungen ohne Ausfallzeiten in verwalteten Compute Engine-Instanzgruppen (Managed Instance Groups, MIGs) durchfü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 Run-Funktionen.

Mit Compute Engine-MIGs können Sie Anwendungen auf mehreren identischen 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 Modell für die kontinuierliche Blau/Grün-Bereitstellung lernen Sie, wie Sie den Nutzer-Traffic schrittweise von einer MIG (blau) zu einer anderen MIG (grün) übertragen, die beide in der Produktion ausgeführt werden.

Hinweis

  • Aktivieren Sie die APIs für Cloud Build, Cloud Run, Artifact Registry und Resource Manager, falls sie noch nicht aktiviert sind.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

    APIs aktivieren

  • Halten Sie den Quellcode Ihrer Anwendung bereit. Ihr Quellcode muss in einem Repository wie GitHub oder Bitbucket gespeichert sein.

  • Zum Ausführen der gcloud-Befehle auf dieser Seite müssen Sie die Google Cloud CLI installieren.

Erforderliche IAM-Berechtigungen (Identity and Access Management)

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Build Berechtigungen auf:

    Zu den Berechtigungen

  2. Legen Sie für Ihr angegebenes Cloud Build-Dienstkonto oder Standard-Cloud Build-Dienstkonto den Status der folgenden Rollen auf Aktiviert fest:

    • Compute-Instanzadministrator v1 (roles/compute.instanceAdmin): Ermöglicht Cloud Build, neue Instanzen in Compute Engine bereitzustellen.
    • Storage-Administrator (roles/storage.admin): Ermöglicht das Lesen und Schreiben in Cloud Storage.
    • Artifact Registry-Autor (roles/artifactregistry.writer): Ermöglicht das Abrufen von Bildern aus und das Schreiben in Artifact Registry.
    • Logs Writer (roles/logging.logWriter): Ermöglicht das Schreiben von Logeinträgen in Cloud Logging.
    • Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor): Ermöglicht Ihrem Dienstkonto, Builds auszuführen.

Designübersicht

Das folgende Diagramm zeigt das Blau/Grün-Bereitstellungsmodell, das vom in diesem Dokument beschriebenen Codebeispiel verwendet wird:

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:
    • Ein Blue-Green-Load-Balancer, der Traffic von Endnutzern entweder an den blauen oder den grünen Pool von VM-Instanzen weiterleitet.
    • Ein blauer Load Balancer, der Traffic von QA-Engineers und Entwicklern an den blauen VM-Instanzpool weiterleitet.
    • Ein grüner Load Balancer, der Traffic von QA-Engineern und Entwicklern an den grünen Instanzpool weiterleitet.
  • Zwei Nutzergruppen:
    • Endnutzer, die Zugriff auf den Blau/Grün-Load-Balancer haben, der sie entweder zum blauen oder zum grünen Instanzpool weiterleitet.
    • QA-Engineers und Entwickler, die für Entwicklungs- und Testzwecke Zugriff auf beide Gruppen benötigen. Sie können sowohl auf den blauen als auch auf den grünen Load-Balancer zugreifen, wodurch sie an den blauen bzw. den grünen Instanzpool weitergeleitet werden.

Die VM-Pools „Blau“ und „Grün“ 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 Codebeispiel in diesem Dokument wird Terraform verwendet, um diese Infrastruktur zu konfigurieren.

Das folgende Diagramm veranschaulicht die Entwicklervorgänge, die bei der Bereitstellung stattfinden:

Ablauf für Entwickler

Im vorherigen Diagramm stellen die roten Pfeile den Bootstrapping-Ablauf dar, der bei der erstmaligen Einrichtung der Bereitstellungsinfrastruktur stattfindet. Die blauen Pfeile stellen den GitOps-Ablauf dar, der bei jeder Bereitstellung stattfindet.

Um diese Infrastruktur einzurichten, führen Sie ein Setupscript aus, das den Bootstrap-Prozess startet und die Komponenten für den GitOps-Ablauf einrichtet.

Das Setupscript führt eine Cloud Build-Pipeline aus, die die folgenden Vorgänge ausführt:

  • Erstellt ein Repository in Cloud Source Repositories mit dem Namen copy-of-gcp-mig-simple und kopiert den Quellcode aus dem GitHub-Beispielrepository in das Repository in Cloud Source Repositories.
  • Erstellt zwei Cloud Build-Trigger mit den Namen apply und destroy.

Der apply-Trigger ist an eine Terraform-Datei namens main.tfvars in Cloud Source Repositories angehängt. Diese Datei enthält die Terraform-Variablen, die die blauen und grünen Load Balancer darstellen.

Um die Bereitstellung einzurichten, 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:

  • Erstellt zwei Compute Engine-MIGs (eine für „green“ und eine für „blue“), vier Compute Engine-VM-Instanzen (zwei für die „green“-MIG und zwei für die „blue“-MIG), die drei Load Balancer („blue“, „green“ und „splitter“) und drei öffentliche IP-Adressen.
  • Gibt die IP-Adressen aus, mit denen Sie die bereitgestellten Anwendungen in den blauen und grünen Instanzen aufrufen können.

Der „destroy“-Trigger wird manuell ausgelöst, um alle Ressourcen zu löschen, die vom „apply“-Trigger erstellt wurden.

Ziele

  • Mit Cloud Build und Terraform können Sie 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.

Neuen Nutzern von Google Cloud 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.

Hinweis

  1. Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch 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.

  2. Installieren Sie die Google Cloud CLI.

  3. Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

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

    gcloud init

  5. Erstellen Sie ein Google Cloud Projekt oder wählen Sie eines aus.

    Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind

    • Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
    • Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Weitere Informationen zum Zuweisen von Rollen

    • So 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 Projekts in Google Cloud .

  6. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Projekt aktiviert ist.

  7. Aktivieren Sie die Cloud Build API, die Cloud Run API, die Artifact Registry API und die Resource Manager API, falls sie noch nicht aktiviert sind:

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen 

    gcloud services enable cloudbuild.googleapis.com run.googleapis.com artifactregistry.googleapis.com cloudresourcemanager.googleapis.com

  8. Installieren Sie die Google Cloud CLI.

  9. Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

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

    gcloud init

  11. Erstellen Sie ein Google Cloud Projekt oder wählen Sie eines aus.

    Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind

    • Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
    • Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Weitere Informationen zum Zuweisen von Rollen

    • So 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 Projekts in Google Cloud .

  12. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Projekt aktiviert ist.

  13. Aktivieren Sie die Cloud Build API, die Cloud Run API, die Artifact Registry API und die Resource Manager API, falls sie noch nicht aktiviert sind:

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen 

    gcloud services enable cloudbuild.googleapis.com run.googleapis.com artifactregistry.googleapis.com cloudresourcemanager.googleapis.com
    14.

Testen

  1. Führen Sie das Setupscript aus dem Google-Codebeispiel-Repository aus: 

    bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)

  2. Wenn das Setupscript Sie um die Nutzereinwilligung bittet, geben Sie yes ein.

    Die Ausführung des Skripts dauert nur wenige Sekunden.

  3. Öffnen Sie in der Google Cloud Console die Cloud Build-Seite Build-Verlauf:

    Seite „Build-Verlauf“ öffnen

  4. Klicken Sie auf den neuesten Build.

    Die Seite Build-Details wird angezeigt. Sie enthält eine Cloud Build-Pipeline mit drei Build-Schritten: Im ersten Build-Schritt wird ein Repository in Cloud Source Repositories erstellt, im zweiten Schritt werden die Inhalte des Beispiel-Repositorys in GitHub in Cloud Source Repositories geklont und im dritten Schritt werden zwei Build-Trigger hinzugefügt.

  5. Cloud Source Repositories öffnen:

    Cloud Source Repositories öffnen

  6. 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 mit dem Namen copy-of-gcp-mig-simple zu erstellen.

  7. Öffnen Sie die Cloud Build-Seite Trigger:

    Zur Seite "Trigger"

    8. Es werden zwei Build-Trigger mit den Namen apply und destroy angezeigt. Der apply-Trigger ist an die Datei infra/main.tfvars im Branch main angehängt. Dieser Trigger wird jedes Mal ausgeführt, wenn die Datei aktualisiert wird. Der destroy-Trigger ist ein manueller Trigger.

  8. So starten Sie die Bereitstellung:infra/main.tfvars

    1. Erstellen Sie im Terminalfenster einen Ordner mit dem Namen deploy-compute-engine und wechseln Sie in diesen Ordner:

      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. Wechseln Sie zum geklonten Verzeichnis:

      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

      Wenn Sie Änderungen an infra/main.tfvars vornehmen, wird die Ausführung des Triggers apply ausgelöst, wodurch die Bereitstellung gestartet wird.

  9. Cloud Source Repositories öffnen:

    Cloud Source Repositories öffnen

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

  11. So rufen Sie die Ausführung des apply-Triggers auf: Öffnen Sie in der Google Cloud Console die Seite Build-Verlauf:

    Seite „Build-Verlauf“ öffnen

  12. Öffnen Sie die Seite Build-Details, indem Sie auf den ersten Build klicken.

    Die Pipeline mit dem apply-Trigger und zwei Build-Schritten wird angezeigt. Im ersten Build-Schritt wird „terraform apply“ ausgeführt, 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 die Anwendung ausgeführt wird.

  13. Öffnen Sie die IP-Adresse, die der grünen MIG entspricht, in einem Browser. Sie sehen einen Screenshot ähnlich dem folgenden, der die Bereitstellung zeigt:

    Bereitstellung

  14. Rufen Sie die Compute Engine-Seite Instanzgruppe auf, um die blauen und grünen Instanzgruppen zu sehen:

    Seite „Instanzgruppe“ öffnen

  15. Öffnen Sie die Seite VM-Instanzen, um die vier VM-Instanzen zu sehen:

    Seite „VM-Instanz“ öffnen

  16. Öffnen Sie die Seite Externe IP-Adressen, um die drei Load Balancer zu sehen:

    Seite „Externe IP-Adressen“ aufrufen

Code verstehen

Der Quellcode für dieses Codebeispiel umfasst:

  • Quellcode für das Einrichtungsskript.
  • Quellcode für die Cloud Build-Pipelines.
  • Quellcode für die Terraform-Vorlagen.

Setup script

setup.sh ist das Setupscript, 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:

  • Aktiviert die APIs Cloud Build, Resource Manager, Compute Engine und Cloud Source Repositories.
  • Weist 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.
  • Weist dem Cloud Build-Dienstkonto in Ihrem Projekt die IAM-Rolle roles/source.admin zu. 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-Beispielrepositorys in Ihre Cloud Source Repositories zu klonen.

  • Generiert inline eine Cloud Build-Pipeline mit dem Namen bootstrap.cloudbuild.yaml, die:

    • Erstellt ein neues Repository in Cloud Source Repositories.
    • Kopiert den Quellcode aus dem GitHub-Beispielrepository in das neue Repository in Cloud Source Repositories.
    • Erstellt die Build-Trigger „apply“ und „destroy“.
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, die das Setupscript verwendet, um die Ressourcen für den GitOps-Ablauf einzurichten. apply.cloudbuild.yaml enthält zwei Build-Schritte:

  • tf_apply build-Build-Schritt, der die Funktion tf_install_in_cloud_build_step aufruft, mit der Terraform installiert wird. tf_apply zum Erstellen der im GitOps-Ablauf verwendeten Ressourcen. Die Funktionen tf_install_in_cloud_build_step und tf_apply sind in bash_utils.sh definiert und der Build-Schritt verwendet den Befehl source, um sie aufzurufen.
  • describe_deployment-Build-Schritt, der die Funktion describe_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 wird der Befehl source verwendet, um die Funktionen aufzurufen.

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 in bash_utils.sh definiert ist. Diese Funktion wird von den Build-Konfigurationsdateien aufgerufen, um Terraform im laufenden Betrieb zu installieren. Es wird ein Cloud Storage-Bucket erstellt, um den Terraform-Status aufzuzeichnen.

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

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

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 definiert ist. Darin wird terraform init aufgerufen, wodurch alle Module und benutzerdefinierten Bibliotheken geladen werden. Anschließend wird terraform destroy ausgeführt, wodurch die Terraform-Variablen entladen werden.

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 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/ und splitter/: Diese Ordner enthalten die Module, die die Load Balancer definieren. Der Ordner mig/ enthält die Terraform-Konfigurationsdatei, in der die MIG für die blauen und grünen Load-Balancer definiert ist. Die blauen und grünen MIGs sind identisch. Sie werden daher einmal definiert und für die blauen und grünen Objekte instanziiert. Die Terraform-Konfigurationsdatei für den Splitter-Load-Balancer befindet sich im Ordner splitter/ .

Das folgende Code-Snippet zeigt den Inhalt von infra/main.tfvars. Sie enthält drei Variablen: zwei, die bestimmen, welche Anwendungsversion in den blauen und 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.

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

Das Folgende ist 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.
  • Eine Variable ist für den Namespace definiert. Alle von Terraform erstellten Objekte haben diese Variable als Präfix, 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 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 des Splittermoduls. In diesem Modul wird die aktive Farbe verwendet, damit der Splitter-Load-Balancer weiß, in welcher verwalteten Instanzgruppe die Anwendung bereitgestellt werden 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
}

Im folgenden Code-Snippet aus infra/main.tf werden zwei identische Module für blaue und grüne MIGs definiert. Es werden die Farbe, das Netzwerk und das Subnetzwerk verwendet, die im Splittermodul 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
}

In der Datei splitter/main.tf werden die Objekte definiert, die für die Splitter-MIG erstellt werden. Das Folgende ist ein Code-Snippet aus splitter/main.tf, das die Logik für den Wechsel zwischen dem grünen und dem blauen MIG enthält. Er wird vom Dienst google_compute_region_backend_service unterstützt, der Traffic an zwei Backend-Regionen weiterleiten kann: var.instance_group_blue oder var.instance_group_green. Mit capacity_scaler wird festgelegt, wie viel Traffic weitergeleitet werden soll.

Mit dem folgenden Code wird 100% des Traffics an die angegebene Farbe weitergeleitet. Sie können diesen Code jedoch für die Canary-Bereitstellung aktualisieren, um den Traffic an eine Teilmenge der Nutzer weiterzuleiten.

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

Die Datei mig/main.tf definiert die Objekte für die MIGs „Blau“ und „Grün“. Im folgenden Code-Snippet aus dieser Datei wird die Compute Engine-Instanzvorlage definiert, die zum Erstellen der VM-Pools verwendet wird. Für diese Instanzvorlage ist das Terraform-Lebenszyklusattribut auf create_before_destroy festgelegt. Das liegt daran, dass Sie beim Aktualisieren der Version des Pools die Vorlage nicht verwenden können, um die neue Version der Pools zu erstellen, wenn sie noch von der vorherigen Version des Pools verwendet wird. Wenn die ältere Version des Pools jedoch vor dem Erstellen der neuen Vorlage zerstört wird, gibt es einen Zeitraum, in dem die Pools nicht verfügbar sind. Um dies zu vermeiden, setzen wir den Terraform-Lebenszyklus auf create_before_destroy, sodass 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

  1. 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 nach der Zeile für den Trigger destroy und klicken Sie auf Ausführen. Wenn der Trigger ausgeführt wurde, werden die Ressourcen gelöscht, die durch den apply-Trigger erstellt wurden.

  2. Löschen Sie die Ressourcen, die während des Bootstrapping erstellt wurden, indem Sie den folgenden Befehl in Ihrem Terminalfenster ausführen:

    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

Nächste Schritte