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 Dienst für die kontinuierliche Einbindung von Google Cloud , 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:

• Versionsverwaltung
• Continuous Integration
• Continuous Delivery
• Kontinuierliche Tests

Architektur

In dieser Anleitung werden GitOps-Verfahren zum Verwalten von Terraform-Ausführungen angewendet. Beachten Sie, dass die Secure Source Manager-Zweige dev und prod verwendet werden, um tatsächliche Umgebungen darzustellen. Diese Umgebungen werden durch die VPC-Netzwerke (Virtual Private Cloud) dev und 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

• Richten Sie Ihre Secure Source Manager-Instanz und Ihr Repository ein.
• 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:

• Cloud Build
• Cloud Storage
• Compute Engine

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

Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach 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.

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

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

   Cloud Shell aktivieren

   Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

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

3. Aktivieren Sie die erforderlichen APIs:

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   Dieser Schritt kann einige Minuten dauern.
4. 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:

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 verschiedene Zweige für verschiedene Umgebungen verwenden:

• 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.
• Feature-Zweige ähnlich 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. Erstellen Sie ein leeres Secure Source Manager-Repository. Initialisieren Sie das Repository nicht.

2. Fügen Sie den Secure Source Manager-Authentifizierungshelfer mit dem folgenden Befehl zu Ihrer globalen git config hinzu:

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

   Der Authentifizierungshelfer 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 ersten Einrichtung 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 Branch dev und wechseln Sie zu ihm.

   git checkout dev
   

7. Pushen Sie das geklonte Repository mit dem folgenden Befehl in Ihr Repository:

   git push -u google --all
   

8. Wiederholen Sie die beiden vorherigen Schritte für den Zweig prod.

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 verwendet, um Code in verschiedenen Umgebungen freizugeben.

• 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 Beispiel-Build-Konfigurationsdatei 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 Zweig 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-Anfragen.
   3. Klicken Sie auf New pull request (Neue Pull-Anfrage).
   4. Wählen Sie im Feld Zusammenführen in: den Branch prod aus.
   5. Wählen Sie im Feld Abrufen von: den Zweig dev aus.
   6. Prüfen Sie die Änderungen und klicken Sie dann auf Neue Pull-Anfrage.
   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.

      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-Zweig, in dem Sie Ihre Ä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 den Branches dev und prod zusammen, indem Sie für jeden Branch Merge-Anfragen öffnen und senden.

Berechtigungen für Ihr 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. Dabei wird normalerweise Zugriff mit den geringsten Berechtigungen bereitgestellt.

Hinweis :Das Cloud Build-Standarddienstkonto, das zum Ausführen von Builds verwendet wird, wird geändert. Als Best Practice empfehlen wir, dass Sie Ihr eigenes Dienstkonto angeben, um Ihre Builds auszuführen. Weitere Informationen finden Sie unter Änderung des Cloud Build-Dienstkontos.

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 Branch-Name geprüft, um festzustellen, ob Änderungen an den Umgebungen dev oder prod vorgenommen werden müssen.

1. Aktivieren und richten Sie Cloud Build in Ihrem Projekt ein.

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

   Seite "Trigger" aufrufen

3. Wählen Sie Ihr Projekt oben auf der Seite im Drop-down-Menü der Projektauswahl 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 den Trigger aus. Wenn in der Build-Konfigurationsdatei, die mit Ihrem Trigger verknüpft ist, ein privater Pool angegeben ist, muss die Region, die Sie für den Trigger auswählen, mit der Region des privaten Pools übereinstimmen.

     Hinweis :Wenn Sie einen privaten Pool verwenden, müssen Sie externe IP-Adressen zuweisen, damit Ihr privater Pool auf das öffentliche Internet zugreifen kann. Weitere Informationen finden Sie unter Neuen privaten Pool erstellen.

     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 Repository-Ereignis aus, um den Trigger aufzurufen.

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

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

     • Neues Secret verwenden, wenn Sie ein neues Secret mit Cloud Build generieren möchten. Klicken Sie auf Secret erstellen, um das 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-Agent [e-mail] möglicherweise manuell die Rolle Secret Manager Secret Accessor zuweisen.

     Weitere Informationen finden Sie unter Dem 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 den Button Editor öffnen, um die Build-Konfigurationsdatei zu bearbeiten.

9. Kopieren Sie den Inhalt der 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 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 beiden 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 Ihren dev- oder prod-Zweigen 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.

   Hinweis: Hook-IDs müssen der Namenskonvention für Ressourcen entsprechen. Sie dürfen nur Kleinbuchstaben, Ziffern oder Bindestriche enthalten, müssen mit einem Buchstaben beginnen und können nach dem Erstellen des Webhooks nicht mehr geändert werden.

5. Geben Sie im Feld 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 in der Google Cloud Console die Seite Trigger.

      Seite "Trigger" aufrufen

   2. Klicken Sie auf den Trigger.

   3. Klicken Sie im Bereich Webhook-URL auf 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 preisgegeben werden, entfernen Sie sie am 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, der mit dem Fragezeichen ?key=... beginnt, 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.

   Hinweis :Wenn Sie einen Webhook hinzufügen oder bearbeiten, kann die Länge von Sensitive Query String von der eingegebenen Länge abweichen. Das ist normal, da Platzhalterstrings verwendet werden, um die Sicherheit zu gewährleisten.

Umgebungskonfiguration in einem neuen Feature-Branch ändern

1. Sie müssen sich im Branch dev befinden:

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

2. Neueste Änderungen abrufen:

   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 Seite Verlauf von Cloud Build:

   Verlauf öffnen

8. Klicken Sie auf den Build, um weitere Informationen aufzurufen, einschließlich der Ausgabe des 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 Bereich haben Sie eine Codeänderung an einen neuen Branch gesendet, es wurden also keine Infrastrukturbereitstellungen auf Ihr Google Cloud -Projekt angewendet.

- 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 können Sie den gewünschten Status auf Ihre dev-Umgebung anwenden.

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 Abrufen von: den Branch bug-fix aus.
5. Klicken Sie auf New pull request (Neue Pull-Anfrage).
6. Klicken Sie auf Pull-Anfrage erstellen.
7. Klicken Sie auf Merge pull request (Pull-Anfrage zusammenführen) und dann noch einmal auf Merge pull request (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 Storage-Bucket für den Terraform-Zustand. 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-Anfragen.
3. Klicken Sie auf New pull request (Neue Pull-Anfrage).
4. Wählen Sie für merge into: (Zusammenführen in:) den Zweig prod 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. Wählen Sie für title einen Titel wie „Promoting networking changes“ aus und klicken Sie auf Create pull request.

8. Prüfen Sie die vorgeschlagenen Änderungen und klicken Sie dann auf Pull-Anfrage zusammenführen.

   Das Datum und die Repository-URL werden im 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, in dem der Terraform-Zustand gespeichert ist. 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

Nach Abschluss der Anleitung können Sie die von Ihnen inGoogle Cloud erstellten Ressourcen bereinigen, damit Ihnen diese nicht weiter in Rechnung gestellt werden.

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, zum Beispiel eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt 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.

1. Wechseln Sie in der Google Cloud -Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte

• Mit den Vorlagen für das Cloud Foundation Toolkit für Unternehmen schnell eine wiederholbare Grundlage inGoogle Clouderstellen
• Video Repeatable Google Cloud Environments at Scale With Cloud Build Infra-As-Code Pipelines von der Next'19 über den in dieser Anleitung beschriebenen GitOps-Workflow
• Anleitung Kontinuierliche Bereitstellung gemäß GitOps mit Cloud Build
• Erweiterte Cloud Build-Features: Reihenfolge von Build-Schritten konfigurieren, Artefakte erstellen, testen und bereitstellen, Benutzerdefinierte Build-Schritte erstellen
• Blog Ensuring scale and compliance of your Terraform Deployment with Cloud Build lesen
• Ressourcen zu DevOps
• Mehr über die DevOps-Ressourcen aus dieser Anleitung erfahren:
  • Versionsverwaltung
  • Continuous Integration
  • Continuous Delivery
  • Kontinuierliche Tests
• Über den DevOps Quick Check erfahren, wo Sie im Vergleich zum Rest der Branche stehen