Infrastruktur als Code mit Terraform, Cloud Build und GitOps verwalten

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 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 Cloud, Linux und GitHub 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

Über das folgende Architekturdiagramm wird veranschaulicht, wie in dieser Anleitung GitOps-Methoden zum Verwalten von Terraform-Ausführungen angewendet werden. Dabei werden die GitHub-Branches dev und prod zur Darstellung der tatsächlichen Umgebungen verwendet. Diese Umgebungen werden von VPC-Netzwerken (Virtual Private Cloud) – dev bzw. prod – in ein Google Cloud-Projekt definiert.

Hinweis: Der Einfachheit halber werden in dieser Anleitung nur dev- und prod-Umgebungen mit VPCs implementiert. Sie können dieses Verhalten erweitern, um weitere Umgebungen bereitzustellen und bei Bedarf Projekte in Ihrer Organisationshierarchie zu erstellen.

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 nicht geschützte Branches richten und diese dann über Pull-Anfragen senden. Die später in dieser Anleitung beschriebene Cloud Build GitHub-Anwendung löst automatisch die Build-Jobs aus und verknüpft die terraform plan-Berichte mit diesen Pull-Anfragen. 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

• GitHub-Repository einrichten
• Terraform so konfigurieren, dass der Status in einem Cloud Storage-Bucket gespeichert wird
• Berechtigungen für Cloud Build-Dienstkonto erteilen
• Cloud Build mit GitHub-Repository verbinden
• 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 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.

Voraussetzungen

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

   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

2. Make sure that billing is enabled for your Google Cloud project.

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

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

5. Aktivieren Sie die erforderlichen APIs:

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

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

GitHub-Repository einrichten

In dieser Anleitung verwenden Sie ein einziges Git-Repository zur Definition der Cloudinfrastruktur. 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.

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.

Zuerst verzweigen Sie das Repository solutions-terraform-cloudbuild-gitops.

1. Rufen Sie in GitHub https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git auf.

2. Klicken Sie in der rechten oberen Ecke der Seite auf Fork.

   

   Jetzt haben Sie eine Kopie des Repositorys solutions-terraform-cloudbuild-gitops mit Quelldateien.

1. Klonen Sie in Cloud Shell dieses verzweigte Repository und ersetzen Sie YOUR_GITHUB_USERNAME durch Ihren GitHub-Nutzernamen:

   cd ~
   git clone https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops.git
   cd ~/solutions-terraform-cloudbuild-gitops
   

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.

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 backends 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)
   gsutil mb gs://${PROJECT_ID}-tfstate
   

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

   ```sh
   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   ```
   
   Enabling Object Versioning increases
   [storage costs](/storage/pricing){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" },
   which you can mitigate by configuring
   [Object Lifecycle Management](/storage/docs/lifecycle){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" } 
   to delete old state versions.
   

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

      cd ~/solutions-terraform-cloudbuild-gitops
      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/MacOS müssen Sie möglicherweise nach sed -i so zwei Anführungszeichen hinzufügen (""):

      cd ~/solutions-terraform-cloudbuild-gitops
      sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
      sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
      

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

      git status
      

      Sie erhalten folgende Ausgabe:

      On branch dev
      Your branch is up-to-date with 'origin/dev'.
      Changes not staged for commit:
       (use "git add <file>..." to update what will be committed)
       (use "git checkout -- <file>..." 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")
      

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

      git add --all
      git commit -m "Update project IDs and buckets"
      git push origin dev
      

      Abhängig von Ihrer GitHub-Konfiguration müssen Sie sich authentifizieren, um die vorherigen Änderungen vorzunehmen.

   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. Wenn die Rolle des Projektbearbeiters jedoch über eine umfassende Berechtigung verfügt, müssen Sie in Produktionsumgebungen die Best Practices für die IT-Sicherheit Ihres Unternehmens befolgen. Dabei wird normalerweise Zugriff mit den geringsten Berechtigungen bereitgestellt.

   1. Rufen Sie in Cloud Shell die E-Mail für das Cloud Build-Dienstkonto Ihres Projekts ab:

      CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
          --format 'value(projectNumber)')@cloudbuild."
      

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

   Cloud Build direkt mit GitHub-Repository verbinden

   In diesem Bereich erfahren Sie, wie Sie die GitHub-Anwendung "Cloud Build" installieren. Mit dieser Installation können Sie Ihr GitHub-Repository mit Ihrem Google Cloud-Projekt verbinden, sodass Cloud Build Ihre Terraform-Manifestdateien jedes Mal automatisch anwenden kann, wenn Sie einen neuen Branch erstellen oder den Code per Push an GitHub übertragen.

   Die folgenden Schritte enthalten eine Anleitung zur Installation der Anwendung nur für das Repository solutions-terraform-cloudbuild-gitops. Sie können die Anwendung aber auch für weitere oder alle Repositories installieren.

   1. Rufen Sie die GitHub Marketplace-Seite für die Cloud Build-Anwendung auf:

      Seite der Cloud Build-Anwendung öffnen

      • Wenn Sie zum ersten Mal eine Anwendung in GitHub konfigurieren, klicken Sie unten auf der Seite auf Mit Google Cloud Build einrichten. Klicken Sie dann auf Dieser App Zugriff auf Ihr GitHub-Konto gewähren.
      • Wenn Sie zum ersten Mal eine Anwendung in GitHub konfigurieren, klicken Sie auf Zugriff konfigurieren. Die Seite Anwendungen Ihres privaten Kontos wird geöffnet.

   2. Klicken Sie in der Cloud Build-Zeile auf Konfigurieren.

   3. Wählen Sie Nur Repositories auswählen und dann solutions-terraform-cloudbuild-gitops aus, um eine Verbindung zum Repository herzustellen.

   4. Klicken Sie auf Speichern oder Installieren. Das Schaltflächenlabel ändert sich je nach Workflow. Sie werden zu Google Cloud weitergeleitet, um die Installation fortzusetzen.

   5. Melden Sie sich mit Ihrem Google Cloud-Konto an. Autorisieren Sie die Cloud Build-Integration in GitHub, wenn Sie dazu aufgefordert werden.

   6. Wählen Sie auf der Seite Cloud Build Ihr Projekt aus. Ein Assistent wird angezeigt.

   7. Wählen Sie im Abschnitt Repository auswählen Ihr GitHub-Konto und das Repository solutions-terraform-cloudbuild-gitops aus.

   8. Wenn Sie mit den Nutzungsbedingungen einverstanden sind, klicken Sie das Kästchen an und dann auf Verbinden.

   9. Klicken Sie im Abschnitt Trigger erstellen auf Trigger erstellen:

      1. Fügen Sie einen Triggernamen hinzu, z. B. push-to-branch. Notieren Sie sich den Triggernamen, da Sie ihn später benötigen.
      2. Wählen Sie im Abschnitt Ereignis die Option Push zu Zweig aus.
      3. Wählen Sie im Abschnitt Quelle im Feld Zweig die Option .* aus.
      4. Klicken Sie auf Erstellen.

   Die GitHub-Anwendung "Cloud Build" ist jetzt konfiguriert und Ihr GitHub-Repository ist mit Ihrem Google Cloud-Projekt verknüpft. Ab jetzt lösen Änderungen am GitHub-Repository Cloud Build-Ausführungen aus, die die Ergebnisse mithilfe von GitHub-Prüfungen an GitHub zurückmelden.

   Umgebungskonfiguration in einem neuen Feature-Branch ändern

   Inzwischen haben Sie den größten Teil Ihrer Umgebung konfiguriert. Sie können nun einige Codeänderungen in Ihrer Entwicklungsumgebung vornehmen.

   1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops
      

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

   3. Wenn Sie die Datei zur Bearbeitung öffnen möchten, rufen Sie die Datei modules/firewall/main.tf auf und klicken Sie auf das Stiftsymbol.

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

      Der Wert muss "http-server" betragen.

   5. Fügen Sie unten auf der Seite eine Commit-Nachricht hinzu, z. B. „Fixing http firewall target“, und wählen Sie Neuen Branch für diesen Commit anlegen und eine Pull-Anfrage starten aus.

   6. Klicken Sie auf Änderungen vorschlagen.

   7. Klicken Sie auf der folgenden Seite auf Create pull request (Pull-Anfrage erstellen), um eine neue Pull-Anfrage mit Ihrer Änderung zu öffnen.

      Sobald Ihre Pull-Anfrage geöffnet ist, wird automatisch ein Cloud Build-Job initiiert.

   8. Klicken Sie auf Show all checks (Alle Prüfungen anzeigen) und warten Sie, bis die Prüfung grün wird.

      

   9. Klicken Sie für weitere Informationen auf Details. Hierzu gehört auch die Ausgabe des terraform plan unter dem Link View more details on Google Cloud Build.

   Führen Sie die Pull-Anfrage noch nicht zusammen.

   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_NAME 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'
     - | 
         if [ -d "environments/$BRANCH_NAME/" ]; then
           cd environments/$BRANCH_NAME
           terraform plan
         else
           for dir in environments/*/
           do 
             cd ${dir}   
             env=${dir%*/}
             env=${env#*/}  
             echo ""
             echo "*************** TERRAFORM 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'
     - | 
         if [ -d "environments/$BRANCH_NAME/" ]; then
           cd environments/$BRANCH_NAME      
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '$BRANCH_NAME' does not represent an official environment."
           echo "*******************************************************************************"
         fi

   Erfolg der Cloud Build-Ausführung vor dem Zusammenführen von Branches erzwingen

   Führen Sie die folgenden Schritte aus, um sicherzustellen, dass Zusammenführungen nur angewendet werden können, wenn die jeweiligen Cloud Build-Ausführungen erfolgreich sind:

   1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops
      

   2. Klicken Sie unter Ihrem Repository-Namen auf Settings (Einstellungen).

   3. Klicken Sie im linken Menü auf Branches.

   4. Klicken Sie unter Branch protection rules (Branch-Schutzregeln) auf Add rule (Regel hinzufügen).

   5. Geben Sie unter Branch-Namensmuster dev ein.

   6. Wählen Sie im Abschnitt Übereinstimmende Branches schützen die Option Statusprüfungen müssen vor dem Zusammenführen bestanden werden aus.

   7. Suchen Sie nach dem zuvor erstellten Cloud Build-Triggernamen.

   8. Klicken Sie auf Erstellen.

   9. Wiederholen Sie die Schritte 3 bis 7 und setzen Sie Branch-Namensmuster auf prod.

   Diese Konfiguration ist wichtig, um die Branches dev und prod zu schützen. Commits müssen also zuerst per Push an einen anderen Branch übertragen werden. Erst dann können diese im geschützten Branch zusammengeführt werden. In dieser Anleitung erfordert die Schutzeinstellung, dass die Cloud Build-Ausführung erfolgreich ist, damit die Zusammenführung zulässig ist.

   Änderungen an der Entwicklungsumgebung übernehmen

   Sie haben eine Pull-Anfrage, die noch zusammengeführt werden muss. Jetzt wird der gewünschte Status auf Ihre dev-Umgebung angewandt.

   1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops
      

   2. Klicken Sie unter Ihrem Repository-Namen auf Pull requests (Pull-Anfragen).

   3. Klicken Sie auf die Pull-Anfrage, die Sie eben erstellt haben.

   4. Klicken Sie auf Merge pull request (Pull-Anfrage zusammenführen) und dann auf Confirm merge (Zusammenführen bestätigen).

      

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

      Zur Cloud Build-Seite

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

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

   8. Rufen Sie in Ihrem Cloud Storage-Bucket die Terraform-Zustandsdatei auf.

      https://storage.cloud.google.com/PROJECT_ID-tfstate/env/dev/default.tfstate
      

   Ä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 GitHub die Hauptseite Ihres verzweigten Repositorys auf.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops
      

   2. Klicken Sie unter Ihrem Repository-Namen auf Pull requests (Pull-Anfragen).

   3. Klicken Sie auf New pull request (Neue Pull-Anfrage).

   4. Wählen Sie für base repository (Basis-Repository) das soeben verzweigte Repository aus.

   5. Wählen Sie für Basis die Option prod aus Ihrem eigenen Basis-Repository aus. Wählen Sie für Vergleichen die Option dev aus.

      

   6. Klicken Sie auf Create pull request.

   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, einschließlich der terraform plan-Details von Cloud Build, und klicken Sie dann auf Merge pull request.

   9. Klicken Sie auf Confirm merge (Zusammenführen bestätigen).

   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 in Ihrem Cloud Storage-Bucket die Terraform-Zustandsdatei auf.

       https://storage.cloud.google.com/PROJECT_ID-tfstate/env/prod/default.tfstate
       

   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

   Clean-up

   Nach Abschluss der Anleitung können Sie die von Ihnen in Google 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, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

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

   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.

   GitHub-Repository löschen

   Sie können verhindern, dass neue Pull-Anfragen an Ihr GitHub-Repository blockiert werden, indem Sie die Regeln für den Branch-Schutz löschen:

   1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.
   2. Klicken Sie unter Ihrem Repository-Namen auf Settings (Einstellungen).
   3. Klicken Sie im linken Menü auf Branches.
   4. Klicken Sie im Abschnitt Branch-Schutzregeln auf die Schaltfläche Löschen für die Zeilen dev und prod.

   Optional können Sie die Cloud Build-Anwendung vollständig von GitHub deinstallieren:

   1. Rufen Sie die GitHub-Einstellungen Anwendungen auf.

      Zur Seite „GitHub-Anwendungen“

   2. Klicken Sie im Tab Installierte GitHub-Anwendungen in der Zeile Cloud Build auf Konfigurieren. Klicken Sie dann im Abschnitt Gefahrenbereich in der Zeile Google Cloud Builder deinstallieren auf Deinstallieren.

      Oben auf der Seite wird die Meldung angezeigt: „Sie sind fertig. Ein Job wurde in die Warteschlange gestellt, um Google Cloud Build zu deinstallieren.“

   3. Klicken Sie auf dem Tab Autorisierte GitHub-Anwendungen in der Zeile Google Cloud Build auf Widerrufen und anschließend auf Ich verstehe, Zugriff widerrufen.

   Wenn Sie Ihr GitHub-Repository nicht behalten möchten:

   1. Wechseln Sie in GitHub zur Hauptseite des verzweigten Repositorys.
   2. Klicken Sie unter Ihrem Repository-Namen auf Settings (Einstellungen).
   3. Scrollen Sie nach unten zum Abschnitt Danger Zone.
   4. Klicken Sie auf Dieses Repository löschen und folgen Sie den Schritten zur Bestätigung.

   Nächste Schritte

   • Mit den Vorlagen für das Cloud Foundation Toolkit für Unternehmen schnell eine wiederholbare Grundlage in Google Cloud erstellen
   • 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
   • 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