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

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.

Infrastruktur mit Entwicklungs- und Produktumgebungen

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 dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

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.

Vorbereitung

  1. Melden Sie sich bei Ihrem Google-Konto an.

    Wenn Sie noch kein Konto haben, melden Sie sich hier für ein neues Konto an.

  2. Wählen Sie in der Cloud Console auf der Seite für die Projektauswahl ein Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

  4. Aktivieren Sie Cloud Shell in der Cloud Console.

    Cloud Shell aktivieren

    Unten in der Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Cloud SDK einschließlich des gcloud-Befehlszeilentools vorinstalliert ist. Die Werte sind bereits für Ihr aktuelles Projekt festgelegt. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  5. 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
  6. Aktivieren Sie die erforderlichen APIs:
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
    Dieser Schritt kann einige Minuten dauern.
  7. 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.

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

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.

    Repository verzweigen

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

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

terraform init und terraform plan werden für alle environments-Unterordner ausgeführt, damit die vorgeschlagenen Änderungen für alle Umgebungen gelten. So können Sie vor dem Zusammenführen der Pull-Anfrage die Pläne überprüfen, um sicherzustellen, dass z. B. einer nicht autorisierten Entität keine Zugriffsrechte erteilt werden.

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)
    gsutil mb gs://${PROJECT_ID}-tfstate
    
  2. Aktivieren Sie die Objektversionsverwaltung, um den Verlauf Ihrer Bereitstellungen zu speichern:

    gsutil versioning set on gs://${PROJECT_ID}-tfstate
    

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

  3. 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
    
  4. 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")
    
  5. 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.gserviceaccount.com"
    
  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

  2. Wenn Sie zum ersten Mal eine Anwendung in GitHub konfigurieren, klicken Sie auf Setup with Google Cloud Build (Mit Google Cloud Build einrichten). Klicken Sie ansonsten auf Edit your plan, wählen Sie Ihre Zahlungsinformationen aus und klicken Sie auf der Seite Edit your plan auf Grant this app access.

  3. Wählen Sie auf der Seite Install Google Cloud Build die Option Only select repositories aus und geben Sie your-user/solutions-terraform-cloudbuild-gitops ein, um eine Verbindung zu Ihrem verzweigten Repository herzustellen.

  4. Klicken Sie auf Installieren.

  5. Melden Sie sich in Google Cloud an.

    Die Seite Authorization wird angezeigt. Sie werden aufgefordert, die GitHub-Anwendung "Cloud Build" zu autorisieren, eine Verbindung zu Google Cloud herzustellen.

    In Google Cloud anmelden

  6. Klicken Sie auf Google Cloud Build durch GoogleCloudBuild autorisieren.

    Sie werden zur Cloud Console weitergeleitet.

  7. Wählen Sie das Google Cloud-Projekt aus, an dem Sie gerade arbeiten.

  8. Wenn Sie den Nutzungsbedingungen zustimmen, klicken Sie das Kästchen an und klicken Sie dann auf Next.

  9. Wählen Sie im Schritt Repository selection die Option your-user/solutions-terraform-cloudbuild-gitops aus, um eine Verbindung zu Ihrem Google Cloud-Projekt herzustellen, und klicken Sie dann auf Connect.

  10. Klicken Sie auf Done und dann auf Connect.

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.
  2. Prüfen Sie, ob Sie sich im dev-Branch befinden.

    Sicherstellen, dass Sie im dev-Branch sind

  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 15 den Tippfehler "http-server**2**" 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 Create a new branch for this commit aus.

  6. Klicken Sie auf Propose file change (Dateiänderung 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 und warten Sie, bis die Prüfung grün wird.

    Alle Prüfungen in einer Pull-Anfrage anzeigen

  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.

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 einen terraform plan für alle Umgebungen aus, damit die vorgeschlagene Änderung für alle gültig ist. Wenn einer dieser Pläne nicht ausgeführt werden kann, schlägt auch der Build fehl.

- id: 'tf plan'
  name: 'hashicorp/terraform:0.11.14'
  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 "*************** 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:0.11.14'
  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 oficial 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.
  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. Wählen Sie unter Branch name pattern (Branch-Namensmuster) die Option dev aus.
  6. Wählen Sie unter Rule settings (Regeleinstellungen) die Option Require status checks to pass before merging (Statusprüfungen müssen vor dem Zusammenführen bestanden werden) aus. Klicken Sie dann unter Status checks found in the last week for this repository (Statusprüfungen der letzten Woche für dieses Repository) auf Build.
  7. Klicken Sie auf Create (Erstellen).
  8. Wiederholen Sie die Schritte 5 bis 8 und setzen Sie das Branch name pattern (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.
  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).

    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.

    Diese Bereitstellung kann einige Sekunden dauern, um die VM zu starten und die Firewallregel zu übernehmen. Am Ende wird jedoch Umgebung: dev im Webbrowser angezeigt.

Ä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.
  2. Klicken Sie auf New pull request (Neue Pull-Anfrage).
  3. Wählen Sie für base repository (Basis-Repository) das soeben verzweigte Repository aus.
  4. Wählen Sie für base (Basis) die Option prod und für compare (Vergleichen) die Option dev aus.
  5. Klicken Sie auf Create pull request.
  6. Wählen Sie für title einen Titel wie Promoting networking changes aus und klicken Sie auf Create pull request.
  7. Prüfen Sie die vorgeschlagenen Änderungen, einschließlich der terraform plan-Details von Cloud Build, und klicken Sie dann auf Merge pull request.
  8. Klicken Sie auf Confirm merge.
  9. Öffnen Sie in der Cloud Console die Seite Build-Verlauf, um zu sehen, wie Ihre Änderungen in der Produktionsumgebung angewendet werden:

    Zur Cloud Build-Seite

  10. 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
    
  11. Kopieren Sie external-ip-value und öffnen Sie die Adresse in einem Webbrowser.

    Bei dieser Bereitstellung kann es einige Sekunden dauern, bis die VM gestartet und die Firewallregel übernommen wird. Am Ende wird jedoch Umgebung: prod im Webbrowser angezeigt.

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 in Google Cloud erstellten Ressourcen bereinigen, damit Ihnen diese nicht weiter in Rechnung gestellt werden.

Projekt löschen

  1. Wechseln Sie in der 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 Beenden, um das Projekt zu löschen.

Weitere Informationen