CI/CD so konfigurieren, dass Terraform-Konfiguration als Code gespeichert wird

In dieser Anleitung wird erläutert, wie Sie mit der gängigen GitOps-Methode die Infrastruktur als Code in Terraform und Cloud Build verwalten. Der Begriff GitOps wurde zuerst von Weaveworks geprägt und sein Schlüsselkonzept ist die Verwendung eines Git-Repositorys zum Speichern des gewünschten Umgebungsstatus. Terraform ist ein Open-Source-Tool von HashiCorp, mit dem die Cloud-Infrastruktur mithilfe von Code vorhersehbar erstellt, geändert und verbessert werden kann. In dieser Anleitung verwenden Sie Cloud Build, einen Google Cloud Dienst für die kontinuierliche Einbindung, um Terraform-Manifestdateien automatisch auf Ihre Umgebung anzuwenden.

Die Anleitung richtet sich an Entwickler und Operatoren, die nach einer eleganten Strategie suchen, um vorhersehbare Änderungen an der Infrastruktur vorzunehmen. In diesem Artikel wird davon ausgegangen, dass Sie mit Google Cloudund Linux vertraut sind.

Die State of DevOps-Berichte haben Faktoren aufgezeigt, die die Leistung bei der Softwarebereitstellung beeinflussen. Diese Anleitung hilft Ihnen bei den folgenden Faktoren:

Architektur

In dieser Anleitung werden GitOps-Methoden zum Verwalten von Terraform-Ausführungen angewendet. Dabei werden die Secure Source Manager-Branches dev und prod zur Darstellung der tatsächlichen Umgebungen verwendet. Diese Umgebungen werden durch die VPC-Netzwerke (Virtual Private Cloud) dev bzw. prod in einemGoogle Cloud -Projekt definiert.

Der Prozess beginnt, wenn Sie Terraform-Code an den dev- oder prod-Branch per Push übertragen. In diesem Szenario wird Cloud Build ausgelöst und wendet anschließend Terraform-Manifeste an, um den gewünschten Status in der jeweiligen Umgebung zu erreichen. Wenn Sie Terraform-Code dagegen in einen anderen Branch per Push übertragen, z. B. in einen Feature-Branch, wird mit Cloud Build terraform plan ausgeführt. Es wird aber nichts auf eine Umgebung angewendet.

Im Idealfall müssen Entwickler oder Operatoren Infrastrukturvorschläge an Entwicklungs- oder Feature-Branches richten und diese dann über Pull-Anfragen senden. So können Sie mögliche Änderungen mit Mitarbeitern diskutieren und überprüfen und Folge-Commits hinzufügen, bevor die Änderungen im Basis-Branch zusammengeführt werden.

Wenn es keine Bedenken gibt, müssen Sie zuerst die Änderungen im dev-Branch zusammenführen. Diese Zusammenführung löst eine Infrastrukturbereitstellung in der dev-Umgebung aus, sodass Sie diese Umgebung testen können. Nachdem Sie die Bereitstellung zufriedenstellend getestet haben, müssen Sie den dev-Branch mit dem prod-Branch zusammenführen, um die Installation der Infrastruktur in der Produktionsumgebung auszulösen.

Ziele

  • Secure Source Manager-Instanz und -Repository einrichten
  • Terraform so konfigurieren, dass der Status in einem Cloud Storage-Bucket gespeichert wird
  • Berechtigungen für Cloud Build-Dienstkonto erteilen
  • Verbinden Sie Cloud Build mit Ihrem Secure Source Manager-Repository.
  • Umgebungskonfiguration in einem Feature-Branch ändern
  • Änderungen an der Entwicklungsumgebung übernehmen
  • Änderungen an der Produktionsumgebung übernehmen

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

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

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  7. Rufen Sie in Cloud Shell die ID des soeben ausgewählten Projekts ab: 
    gcloud config get-value project
     Wenn dieser Befehl keine Projekt-ID zurückgibt, konfigurieren Sie Cloud Shell so, dass Ihr Projekt verwendet wird. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID. 
    gcloud config set project PROJECT_ID
  8. Aktivieren Sie die erforderlichen APIs: 
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com
     Dieser Schritt kann einige Minuten dauern.
  9. Wenn Sie Git noch nie über Cloud Shell verwendet haben, konfigurieren Sie es mit Ihrem Namen und Ihrer E-Mail-Adresse:
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
    Git verwendet diese Informationen, um Sie als Ersteller der Commits zu identifizieren, die Sie in Cloud Shell erstellen:

    10. Secure Source Manager-Repository einrichten

    In dieser Anleitung verwenden Sie ein einzelnes Secure Source Manager-Repository, um Ihre Cloud-Infrastruktur zu definieren. Sie orchestrieren diese Infrastruktur, indem Sie unterschiedliche Branches haben, die unterschiedlichen Umgebungen entsprechen:

    • Der dev-Branch enthält die neuesten Änderungen, die auf die Entwicklungsumgebung angewendet werden.
    • Der prod-Branch enthält die neuesten Änderungen, die auf die Produktionsumgebung angewendet werden.
    • Funktionszweige wie feature_x werden verwendet, um Änderungen vorzunehmen, bevor sie in die Zweige dev oder prod übertragen werden.

    Mit dieser Infrastruktur können Sie jederzeit auf das Repository verweisen, um zu erfahren, welche Konfiguration in den einzelnen Umgebungen erwartet wird, und um neue Änderungen vorzuschlagen, die zuerst in der dev-Umgebung zusammengeführt werden. Anschließend übernehmen Sie die Änderungen. Dazu führen Sie den dev-Branch mit dem nachfolgenden prod-Branch zusammen.

    1. Leeres Secure Source Manager-Repository erstellen – das Repository darf nicht initialisiert werden.

    2. Fügen Sie den Authentifizierungshelfer für Secure Source Manager zu Ihrem globalen git config hinzu, indem Sie den folgenden Befehl ausführen:

      git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh

      Der Authentifizierungs-Helper verwendet die gcloud CLI, um IhreGoogle Cloud -Anmeldedaten abzurufen, wenn Sie Git-Befehle mit Secure Source Manager verwenden.

    3. Führen Sie den folgenden gcloud CLI-Befehl aus, um sich nach der Ersteinrichtung der Anmeldedaten noch einmal zu authentifizieren:

      gcloud auth login

    4. Klonen Sie das Repository solutions-terraform-cloudbuild-gitops in Ihre lokale Shell oder Arbeitsumgebung:

      git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git

    5. Fügen Sie Ihr Secure Source Manager-Repository als Upstream-Repository hinzu.

      git remote add google HTTPS_REPO_URL

      Dabei ist HTTPS_REP_URL die HTTPS-URL für Ihr Secure Source Manager-Repository. Sie finden die URL oben auf der Repository-Seite in der Secure Source Manager-Weboberfläche.

    6. Erstellen Sie den dev-Branch und wechseln Sie zu ihm.

      git checkout dev

    7. Übertragen Sie das geklonte Repository mit dem folgenden Befehl per Push in Ihr Repository:

      git push -u google --all

    8. Wiederholen Sie die beiden vorherigen Schritte für Ihren prod-Branch.

    Der Code in diesem Repository ist folgendermaßen aufgebaut:

    • Der environments/-Ordner enthält Unterordner, die Umgebungen wie dev und prod darstellen. Diese bieten eine logische Trennung zwischen Arbeitslasten in verschiedenen Reife-, Entwicklungs- bzw. Produktionsphasen. Obwohl es sich empfiehlt, diese Umgebungen möglichst ähnlich zu gestalten, verfügt jeder Unterordner über eine eigene Terraform-Konfiguration, um sicherzustellen, dass sie bei Bedarf eindeutige Einstellungen haben.

    • Der Ordner modules/ enthält Inline-Terraform-Module. Diese Module stellen logische Gruppierungen verwandter Ressourcen dar und werden zur gemeinsamen Nutzung von Code in verschiedenen Umgebungen verwendet.

    • Die Datei cloudbuild.yaml ist eine Build-Konfigurationsdatei, die Anweisungen für Cloud Build enthält, z. B. zum Ausführen von Aufgaben basierend auf einer Reihe von Schritten. Diese Datei gibt eine bedingte Ausführung abhängig von dem Branch an, von dem Cloud Build den Code abruft. Beispiel:

      • Für die dev- und prod-Branches werden folgende Schritte ausgeführt:

        1. terraform init
        2. terraform plan
        3. terraform apply

      • Für alle anderen Branches werden folgende Schritte ausgeführt:

        1. terraform init für alle environments-Unterordner
        2. terraform plan für alle environments-Unterordner

    Um sicherzustellen, dass die vorgeschlagenen Änderungen für jede Umgebung geeignet sind, werden terraform init und terraform plan für alle environments-Unterordner ausgeführt. Bevor Sie die Pull-Anfrage zusammenführen, können Sie die Pläne prüfen, um beispielsweise zu vermeiden, dass einer nicht autorisierten Entität Zugriff gewährt wird.

    Build-Konfigurationsdatei ändern

    Damit die Beispielkonfigurationsdatei für die Erstellung mit Secure Source Manager funktioniert, müssen Sie die folgenden Änderungen vornehmen:

    • Fügen Sie einen Schritt zum Klonen Ihres Repositorys hinzu.
    • Fügen Sie einen Schritt hinzu, um den Zweignamen abzurufen und einer Variablen zuzuweisen.

    Bearbeiten Sie die Build-Konfigurationsdatei im Branch dev:

    1. Wechseln Sie zum Branch dev:

      git checkout dev

    2. Öffnen Sie die Datei cloudbuild.yaml und ersetzen Sie den Inhalt durch Folgendes:

      # Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


steps:
- id: 'clone repository'
  name: 'gcr.io/cloud-builders/git'
  args:
  - clone
  - '${_REPO_URL}'
  - .
- id: 'branch name'
  name: gcr.io/cloud-builders/git
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      git checkout ${branch}
      echo "***********************"
      git branch --show-current
      echo "***********************"

- id: 'tf init'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
   branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform init
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFORM INIT ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform init || exit 1
          cd ../../
        done
      fi

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

- id: 'tf apply'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '${branch}' does not represent an official environment."
        echo "*******************************************************************************"
      fi

    3. Prüfen Sie, ob die Datei geändert wurde.

      git status

    4. Führen Sie einen Commit durch und übertragen Sie die Änderungen:

      git add --all
git commit -m "Modify build config file."
git push google dev

    5. Öffnen Sie eine Pull-Anfrage, um Ihre Änderungen schnell in den prod-Branch zu übertragen.

      1. Rufen Sie in der Secure Source Manager-Weboberfläche Ihr Repository auf.
      2. Klicken Sie auf den Tab Pull requests (Pull-Anfragen).
      3. Klicken Sie auf New pull request (Neue Pull-Anfrage).
      4. Wählen Sie im Feld Zusammenführen in den Zweig prod aus.
      5. Wählen Sie im Feld pull from: den Zweig dev aus.
      6. Sehen Sie sich die Änderungen an und klicken Sie dann auf New pull request (Neuer Pull-Request).
      7. Klicken Sie auf Pull-Anfrage erstellen.
      8. Klicken Sie auf Merge pull request (Pull-Anfrage zusammenführen).

      9. Klicken Sie noch einmal auf Merge pull request (Pull-Anfrage zusammenführen).

        Die Änderungen werden in Ihren prod-Zweig zusammengeführt.

    Terraform so konfigurieren, dass der Status in einem Cloud Storage-Bucket gespeichert wird

    Standardmäßig speichert Terraform den Status lokal in einer Datei mit dem Namen terraform.tfstate. Diese Standardkonfiguration kann die Verwendung von Terraform für Teams erschweren, insbesondere wenn viele Nutzer Terraform gleichzeitig ausführen und jeder Computer ein eigenes Verständnis der aktuellen Infrastruktur hat.

    Zur Vermeidung solcher Probleme wird in diesem Bereich ein Remotestatus konfiguriert, der auf einen Cloud Storage-Bucket verweist. Der Remote-Status ist ein Feature der Back-Ends und wird in dieser Anleitung in den backend.tf-Dateien konfiguriert. Beispiel:

    # Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

    In den folgenden Schritten erstellen Sie einen Cloud Storage-Bucket und ändern einige Dateien so, dass sie auf Ihren neuen Bucket und Ihr Google Cloud -Projekt verweisen.

    1. Erstellen Sie in Cloud Shell den Cloud Storage-Bucket:

      PROJECT_ID=$(gcloud config get-value project)
gcloud storage buckets create gs://${PROJECT_ID}-tfstate

    2. Aktivieren Sie die Objektversionsverwaltung, um den Verlauf Ihrer Bereitstellungen zu speichern:

      gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning

      Durch das Aktivieren der Objektversionsverwaltung werden die Speicherkosten erhöht. Dies können Sie umgehen, indem Sie die Verwaltung des Objektlebenszyklus so konfigurieren, dass frühere Statusversionen gelöscht werden.

    3. Erstellen Sie einen neuen cloud-storage-bucket-Branch, in dem Sie die Änderungen vornehmen können:

      cd ~/solutions-terraform-cloudbuild-gitops
git checkout -b cloud-storage-bucket

    4. Ersetzen Sie den Platzhalter PROJECT_ID durch die Projekt-ID in den Dateien terraform.tfvars und backend.tf:

      sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

      Unter OS X oder macOS müssen Sie möglicherweise nach sed -i so zwei Anführungszeichen hinzufügen (""):

      sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

    5. Prüfen Sie, ob alle Dateien aktualisiert wurden:

      git status

      Sie erhalten folgende Ausgabe:

      On branch cloud-storage-bucket
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
       modified:   environments/dev/backend.tf
       modified:   environments/dev/terraform.tfvars
       modified:   environments/prod/backend.tf
       modified:   environments/prod/terraform.tfvars
no changes added to commit (use "git add" and/or "git commit -a")

    6. Führen Sie einen Commit durch und übertragen Sie die Änderungen:

      git add --all
git commit -m "Update project IDs and buckets"
git push google -u cloud-storage-bucket

      Der neue Branch cloud-storage-bucket wird in Ihr Repository übertragen.

    7. Führen Sie Ihre cloud-storage-bucket-Änderungen in Ihre dev- und prod-Zweige zusammen, indem Sie für jeden Zweig Merge-Anfragen öffnen und senden.

    Berechtigungen für Cloud Build-Dienstkonto erteilen

    Damit das Cloud Build-Dienstkonto Terraform-Skripts zur Verwaltung von Google Cloud Ressourcen ausführen darf, müssen Sie ihm den entsprechenden Zugriff auf Ihr Projekt gewähren. Der Einfachheit halber wird in dieser Anleitung der Zugriff für den Projektbearbeiter gewährt. In Produktionsumgebungen sollten Sie die Best Practices für die IT-Sicherheit Ihres Unternehmens befolgen. Das bedeutet normalerweise, den Zugriff mit den geringsten Berechtigungen zu gewähren.

    1. Die E-Mail-Adresse des Cloud Build-Dienstkontos finden Sie auf der Cloud Build-Seite unter Einstellungen.

      Zu den Cloud Build-Einstellungen

    2. Kopieren Sie den Wert der E-Mail-Adresse des Dienstkontos.

    3. Gewähren Sie den erforderlichen Zugriff auf Ihr Cloud Build-Dienstkonto:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member serviceAccount:CLOUDBUILD_SA --role roles/editor

      Ersetzen Sie Folgendes:

      • PROJECT_ID durch Ihre Projekt-ID,
      • CLOUDBUILD_SA durch die E-Mail-Adresse des Cloud Build-Dienstkontos.

    Mit Cloud Build verbinden

    Wenn Sie Cloud Build bei einem Push in einen beliebigen Zweig auslösen möchten, richten Sie einen Secure Source Manager-Webhook ein. In der Build-Konfigurationsdatei wird der Branchname geprüft, um festzustellen, ob Änderungen an den Umgebungen dev oder prod vorgenommen werden müssen.

    1. Cloud Build in Ihrem Projekt aktivieren und einrichten

    2. Öffnen Sie die Seite Trigger in der Google Cloud Console.

      Seite "Trigger" aufrufen

    3. Wählen Sie oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

    4. Klicken Sie auf Öffnen.

    5. Klicken Sie auf Trigger erstellen.

    6. Geben Sie die folgenden Triggereinstellungen ein:

      • Name: trigger-on-push

      • Region: Wählen Sie die Region für Ihren Trigger aus. Wenn in der mit Ihrem Trigger verknüpften Build-Konfigurationsdatei ein privater Pool angegeben ist, muss die für den Trigger ausgewählte Region mit der Region des privaten Pools übereinstimmen.

        Wenn Sie global als Region auswählen, verwendet Cloud Build die in Ihrer Build-Konfigurationsdatei angegebene Region, um den Build auszuführen. Dies kann entweder die Region des privaten Pools sein, wenn Sie einen privaten Pool in Ihrer Build-Konfigurationsdatei angeben, oder der globale Standardpool, wenn Sie keinen privaten Pool angeben.

      • Beschreibung (optional): Geben Sie eine Beschreibung für den Trigger ein.

      • Ereignis: Wählen Sie Webhook-Ereignis als das Repository-Ereignis aus, das den Trigger auslösen soll.

        Wenn Secret Manager nicht installiert ist, werden Sie aufgefordert, Secret Manager zu aktivieren.

      • Webhook-URL: Wählen Sie eine der folgenden Optionen aus:

        • Wählen Sie Neues Secret verwenden aus, wenn Sie ein neues Secret mit Cloud Build generieren möchten. Klicken Sie auf Secret erstellen, um Ihr Secret zu erstellen.
        • Vorhandenes Secret verwenden oder eigenes erstellen, wenn Sie ein vorhandenes Secret verwenden möchten. Geben Sie das Secret und die Version in die Drop-down-Auswahlfelder ein.

        Wenn Sie ein vorhandenes Secret verwenden, müssen Sie dem Cloud Build-Dienst-Agenten service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com möglicherweise die Rolle Zugriffsperson für Secret Manager-Secret manuell zuweisen.

        Weitere Informationen finden Sie unter Cloud Build-Dienst-Agent eine Rolle zuweisen.

    7. Klicken Sie auf URL-Vorschau anzeigen und notieren Sie sich die URL. Sie benötigen diese URL, um den Webhook in Secure Source Manager einzurichten.

      • Konfiguration: Wählen Sie für Typ die Option Cloud Build-Konfigurationsdatei (YAML oder JSON) und für Speicherort die Option Inline aus.

    8. Klicken Sie auf die Schaltfläche Editor öffnen, um die Build-Konfigurationsdatei zu bearbeiten.

    9. Kopieren Sie den Inhalt Ihrer Datei cloudbuild.yaml in den Editor.

      Wie bereits erwähnt, weist diese Pipeline abhängig vom abgerufenen Branch unterschiedliches Verhalten auf. Der Build prüft, ob die Variable ${branch} mit einem Umgebungsordner übereinstimmt. Wenn ja, führt Cloud Build den terraform plan für diese Umgebung aus. Andernfalls führt Cloud Build terraform plan für alle Umgebungen aus, damit die vorgeschlagene Änderung auf jeden Fall für alle Umgebungen geeignet ist. Wenn einer dieser Pläne nicht ausgeführt werden kann, schlägt der Build fehl.

      - id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

      Der Befehl terraform apply wird für Umgebungs-Branches ausgeführt. In allen anderen Fällen wird er jedoch vollständig ignoriert.

    10. Klicken Sie auf + Variable hinzufügen und fügen Sie die folgenden zwei Substitutionsvariablen hinzu:

      • Variable: _REPO_URL, Wert:$(body.repository.clone_url)
      • Variable: _REF, Wert:$(body.ref)

    11. Klicken Sie auf Erstellen.

    Webhook in Secure Source Manager einrichten

    Erstellen Sie einen Webhook, um Builds bei Push-Vorgängen in Ihre dev- oder prod-Branches auszulösen.

    1. Rufen Sie in der Secure Source Manager-Weboberfläche das Repository auf, für das Sie einen Webhook erstellen möchten.
    2. Klicken Sie auf Einstellungen.
    3. Klicken Sie auf Webhooks und dann auf Webhook hinzufügen.

    4. Geben Sie im Feld Hook-ID eine ID für den Webhook ein.

    5. Geben Sie im Feld Target URL (Ziel-URL) die Webhook-URL ein, die Sie beim Einrichten eines Webhook-Triggers in Cloud Build kopiert haben.

      So finden Sie die Webhook-URL:

      1. Öffnen Sie die Seite Trigger in der Google Cloud Console.

        Seite "Trigger" aufrufen

      2. Klicken Sie auf den Trigger.

      3. Klicken Sie im Bereich Webhook URL (Webhook-URL) auf Show URL preview (URL-Vorschau anzeigen) und kopieren Sie die URL.

    6. Die Webhook-URL enthält die Schlüssel- und Secret-Werte, die Sie beim Erstellen des Cloud Build-Triggers eingegeben haben. Um zu verhindern, dass diese Werte weitergegeben werden, entfernen Sie sie vom Ende der Ziel-URL und kopieren Sie sie in das Feld Sensibler Abfragestring.

      Wenn Sie Ihren Schlüssel und Ihr Secret in Ihrer Webhook-URL finden möchten, suchen Sie nach dem Text, der mit key= beginnt.

      Beispiel: Bei der folgenden URL: https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

      Kopieren Sie den Teil ab dem Fragezeichen ?key=... aus dem Feld Ziel-URL und entfernen Sie ihn. Entfernen Sie dann das ursprüngliche Fragezeichen und verschieben Sie den verbleibenden Teil key=... in das Feld Sensibler Abfragestring.

    7. Klicken Sie auf Add webhook (Webhook hinzufügen).

    8. Der Webhook wird auf der Seite Webhooks angezeigt.

    Umgebungskonfiguration in einem neuen Feature-Branch ändern

    1. Prüfen Sie, ob Sie sich im dev-Branch befinden:

      cd ~/solutions-terraform-cloudbuild-gitops
git checkout dev

    2. Laden Sie die letzten Änderungen herunter:

      git pull

    3. Erstellen Sie einen bug-fix-Zweig, um die Umgebungskonfiguration zu ändern.

      git checkout -b bug-fix

    4. Öffnen Sie modules/firewall/main.tf zum Bearbeiten.

    5. Korrigieren Sie in Zeile 30 den Tippfehler "http-server2" im Feld target_tags.

      Der Wert muss "http-server" betragen.

    6. Führen Sie einen Commit durch und übertragen Sie die Änderungen:

      git add --all
git commit -m "Fix typo."
git push google -u bug-fix

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

      Zur Seite „Verlauf“

    8. Klicken Sie auf Build, um weitere Informationen aufzurufen, einschließlich der Ausgabe von terraform plan.

    Der Cloud Build-Job hat die in der cloudbuild.yaml-Datei definierte Pipeline ausgeführt. Wie bereits erwähnt, weist diese Pipeline abhängig vom abgerufenen Branch unterschiedliches Verhalten auf. Der Build prüft, ob die Variable ${branch} mit einem Umgebungsordner übereinstimmt. Wenn ja, führt Cloud Build den terraform plan für diese Umgebung aus. Andernfalls führt Cloud Build terraform plan für alle Umgebungen aus, damit die vorgeschlagene Änderung auf jeden Fall für alle Umgebungen geeignet ist. Wenn einer dieser Pläne nicht ausgeführt werden kann, schlägt der Build fehl.

    - id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

    Ebenso wird der Befehl terraform apply für Umgebungs-Branches ausgeführt. In allen anderen Fällen wird er jedoch vollständig ignoriert. In diesem Abschnitt haben Sie eine Codeänderung an einen neuen Branch gesendet, sodass keine Infrastrukturbereitstellungen auf Ihr Google Cloud -Projekt angewendet wurden.

    - id: 'tf apply' name: 'hashicorp/terraform:1.0.0' entrypoint: 'sh' args: - '-c' - | branch=$(basename "$_REF") if [ -d "environments/${branch}/" ]; then cd environments/${branch} terraform apply -auto-approve else echo "***************************** SKIPPING APPLYING *******************************" echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

    Änderungen an der Entwicklungsumgebung übernehmen

    Jetzt wird der gewünschte Status auf Ihre dev-Umgebung angewandt.

    1. Rufen Sie in der Secure Source Manager-Weboberfläche Ihr Repository auf.
    2. Klicken Sie auf New pull request (Neue Pull-Anfrage).
    3. Wählen Sie im Feld Zusammenführen in: Ihren dev-Zweig aus.
    4. Wählen Sie im Feld pull from: (ziehen von:) den bug-fix-Zweig aus.
    5. Klicken Sie auf New pull request (Neue Pull-Anfrage).
    6. Klicken Sie auf Pull-Anfrage erstellen.
    7. Klicken Sie auf Pull-Anfrage zusammenführen und dann noch einmal auf Pull-Anfrage zusammenführen.

    8. Prüfen Sie, ob ein neuer Cloud Build ausgelöst wurde:

      Zur Cloud Build-Seite

    9. Öffnen Sie den Build und überprüfen Sie die Protokolle.

      Wenn der Build abgeschlossen ist, sehen Sie in etwa Folgendes:

      Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = dev-allow-http
Step #3 - "tf apply": instance_name = dev-apache2-instance
Step #3 - "tf apply": network = dev
Step #3 - "tf apply": subnet = dev-subnet-01

    10. Kopieren Sie EXTERNAL_IP_VALUE und öffnen Sie die Adresse in einem Webbrowser.

      http://EXTERNAL_IP_VALUE

      Bei dieser Bereitstellung kann es einige Sekunden dauern, die VM zu starten und die Firewallregel zu übernehmen. Schließlich wird Umgebung: dev im Webbrowser angezeigt.

    11. Rufen Sie Cloud Storage auf:

      Zur Cloud Storage-Seite

    12. Wählen Sie Ihr Projekt aus.

    13. Klicken Sie auf den Bucket für den Terraform-Zustandsspeicher. Der Bucket-Name sieht so aus:

      PROJECT_ID-tfstate

    14. Klicken Sie auf env und dann auf dev, um die Terraform-Zustandsdatei aufzurufen.

    Änderungen an der Produktionsumgebung übernehmen

    Nachdem Sie Ihre Entwicklungsumgebung vollständig getestet haben, können Sie den Code der Infrastruktur für die Produktion übernehmen.

    1. Rufen Sie in der Secure Source Manager-Weboberfläche Ihr Repository auf.
    2. Klicken Sie auf den Tab Pull requests (Pull-Anfragen).
    3. Klicken Sie auf New pull request (Neue Pull-Anfrage).
    4. Wählen Sie für merge into: (zusammenführen in:) den prod-Zweig Ihres Repositorys aus.
    5. Wählen Sie für pull from (ziehen von) den dev-Zweig Ihres Repositorys aus.
    6. Klicken Sie auf New pull request (Neue Pull-Anfrage).
    7. Geben Sie für title (Titel) einen Titel ein, z. B. „Promoting networking changes“. Klicken Sie dann auf Create pull request (Pull-Anfrage erstellen).

    8. Prüfen Sie die vorgeschlagenen Änderungen und klicken Sie dann auf Merge pull request (Pull-Anfrage zusammenführen).

      Das Datum und die Repository-URL werden dem Kommentarfeld hinzugefügt.

    9. Klicken Sie zur Bestätigung noch einmal auf Pull-Anfrage zusammenführen.

    10. Öffnen Sie in der Google Cloud Console die Seite Build-Verlauf, um zu sehen, wie Ihre Änderungen in der Produktionsumgebung angewendet werden:

      Zur Cloud Build-Seite

    11. Warten Sie, bis der Build fertig ist, und überprüfen Sie dann die Protokolle.

      Am Ende der Logs sehen Sie in etwa Folgendes

      Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = prod-allow-http
Step #3 - "tf apply": instance_name = prod-apache2-instance
Step #3 - "tf apply": network = prod
Step #3 - "tf apply": subnet = prod-subnet-01

    12. Kopieren Sie EXTERNAL_IP_VALUE und öffnen Sie die Adresse in einem Webbrowser.

      http://EXTERNAL_IP_VALUE

      Bei dieser Bereitstellung kann es einige Sekunden dauern, die VM zu starten und die Firewallregel zu übernehmen. Schließlich wird Umgebung: prod im Webbrowser angezeigt.

    13. Rufen Sie Cloud Storage auf:

      Zur Cloud Storage-Seite

    14. Wählen Sie Ihr Projekt aus.

    15. Klicken Sie auf den Bucket für den Terraform-Zustandsspeicher. Der Bucket-Name sieht so aus:

      PROJECT_ID-tfstate

    16. Klicken Sie auf env und dann auf prod, um die Terraform-Zustandsdatei aufzurufen.

    Sie haben jetzt eine serverlose Infrastruktur-als-Code-Pipeline in Cloud Build konfiguriert. In Zukunft möchten Sie möglicherweise Folgendes ausprobieren:

    • Bereitstellungen für separate Anwendungsfälle hinzufügen
    • Zusätzliche Umgebungen erstellen, um Ihren Anforderungen gerecht zu werden
    • Ein Projekt pro Umgebung anstelle einer VPC pro Umgebung verwenden

    Bereinigen

    Bereinigen Sie nach Abschluss der Anleitung die aufGoogle Cloud erstellten Ressourcen, damit Ihnen diese nicht weiter in Rechnung gestellt werden.

    Projekt löschen

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

    Nächste Schritte