Infrastruktur als Code mit Terraform, Jenkins und GitOps verwalten

In dieser Anleitung wird erläutert, wie Sie Infrastruktur als Code mit Terraform und Jenkins unter Verwendung der beliebten GitOps-Methode verwalten. Die Anleitung richtet sich an Entwickler und Operatoren, die nach Best Practices suchen, um Infrastruktur auf dieselbe Weise zu verwalten wie ihre Softwareanwendungen. In diesem Artikel wird davon ausgegangen, dass Sie mit Terraform, Jenkins, GitHub, Google Kubernetes Engine (GKE) und Google Cloud vertraut sind.

Architektur

Bei der in dieser Anleitung verwendeten Architektur werden zur Darstellung von tatsächlichen Entwicklungs- und Produktionsumgebungen die GitHub-Zweige dev und prod genutzt. Diese Umgebungen sind durch die VPC-Netzwerke (Virtual Private Cloud) dev und prod in einem Google Cloud-Projekt definiert.

Infrastrukturvorschlag

Wie das folgende Architekturdiagramm zeigt, beginnt der Prozess, sobald ein Entwickler oder Operator einen Infrastrukturvorschlag an einen nicht geschützten GitHub-Zweig richtet. Dabei handelt es sich in der Regel um einen Featurezweig. Gegebenenfalls kann dieser Featurezweig über eine Pull-Anfrage (PR) als dev-Zweig in der Entwicklungsumgebung übernommen werden. Jenkins löst dann automatisch einen Job aus, um die Validierungspipeline auszuführen. Dieser Job führt den Befehl terraform plan aus, meldet das Validierungsergebnis an GitHub und enthält einen Link zu einem ausführlichen Infrastrukturänderungsbericht. Dieser Schritt ist entscheidend, da Sie mögliche Änderungen zusammen mit Mitbearbeitern prüfen und Folge-Commits hinzufügen können, bevor die Änderungen im dev-Zweig zusammengeführt werden.

Architektur mit GitOps-Verfahren zum Verwalten von Terraform-Ausführungen

Dev-Bereitstellung

Wenn der Validierungsprozess erfolgreich ist und Sie die vorgeschlagenen Infrastrukturänderungen genehmigen, können Sie die Pull-Anfrage mit dem dev-Zweig zusammenführen. Das folgende Diagramm zeigt diesen Vorgang.

Pull-Anfrage mit dem

Sobald die Zusammenführung abgeschlossen ist, löst Jenkins einen weiteren Job zum Ausführen der Bereitstellungspipeline aus. In diesem Szenario wendet der Job in der Entwicklungsumgebung Terraform-Manifeste an, um den gewünschten Zustand zu erreichen. Dieser Schritt ist wichtig, da Sie damit den Terraform-Code testen können, bevor Sie ihn für die Produktion übernehmen.

Prod-Bereitstellung

Nachdem Sie einen Test durchgeführt haben und bereit sind, die Änderungen für die Produktion zu übernehmen, müssen Sie den dev-Zweig mit dem prod-Zweig zusammenführen, um die Installation der Infrastruktur in der Produktionsumgebung auszulösen. Das folgende Diagramm zeigt diesen Vorgang.

Zusammenführen des

Beim Erstellen der Pull-Anfrage wird derselbe Validierungsvorgang durchgeführt. Dieser Prozess ermöglicht es Ihrem Betriebsteam, die vorgeschlagenen Änderungen an der Produktion zu prüfen und zu genehmigen.

Ziele

  • GitHub-Repository einrichten
  • Remote-Zustandsspeicher von Terraform erstellen
  • GKE-Cluster erstellen und Jenkins installieren
  • 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.

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

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. Konfigurieren Sie in Cloud Shell Ihre Projekt-ID und legen Sie Ihren GitHub-Nutzernamen und Ihre E-Mail-Adresse fest:
    PROJECT_ID=PROJECT_ID
    GITHUB_USER=YOUR_GITHUB_USER
    GITHUB_EMAIL=YOUR_EMAIL_ADDRESS
    gcloud config set project $PROJECT_ID
    

    Wenn Sie bisher nicht über Cloud Shell auf GitHub zugegriffen haben, können Sie so die Konfiguration Ihres Nutzernamens und Ihrer E-Mail-Adresse vornehmen:

    git config --global user.email "$GITHUB_EMAIL"
    git config --global user.name "$GITHUB_USER"
    

    GitHub 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 GitHub-Repository zum Definieren der Cloud-Infrastruktur. Sie orchestrieren diese Infrastruktur mithilfe unterschiedlicher Zweige, 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-Zweig mit dem prod-Zweig zusammen.

Zuerst müssen Sie das Repository solutions-terraform-jenkins-gitops abzweigen.

  1. Wechseln Sie in GitHub zum Repository solutions-terraform-jenkins-gitops.
  2. Klicken Sie auf Fork.

    Repository in GitHub abzweigen

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

  3. Klonen Sie in Cloud Shell dieses verzweigte Repository:

    cd ~
    git clone https://github.com/$GITHUB_USER/solutions-terraform-jenkins-gitops.git
    cd ~/solutions-terraform-jenkins-gitops
    

    Der Code in diesem Repository ist folgendermaßen aufgebaut:

    • Ordner example-pipelines/: Enthält Unterordner mit der in dieser Anleitung verwendeten Beispielpipeline.
    • example-create/: Enthält Terraform-Code zum Erstellen einer virtuellen Maschine in Ihrer Umgebung.
    • environments/: Enthält die Umgebungsordner dev und prod mit Back-End-Konfigurationen und Links zu Dateien aus dem Ordner example-create/.
    • Ordner jenkins-gke/: Enthält Skripts, die zum Bereitstellen von Jenkins in einem neuen GKE-Cluster erforderlich sind.
    • tf-gke/: Enthält den Terraform-Code zum Bereitstellen in GKE und zum Installieren von Jenkins und seiner abhängigen Ressourcen.

Remote-Zustandsspeicher von Terraform erstellen

Der Terraform-Zustand wird standardmäßig lokal gespeichert. Es empfiehlt sich jedoch, den Zustand im zentralen Remote-Speicher zu speichern, auf den Sie von jedem System aus zugreifen können. Mit diesem Ansatz können Sie vermeiden, dass mehrere Kopien auf verschiedenen Systemen erstellt werden, was bei der Infrastruktur zu einer nicht übereinstimmenden Konfiguration und einem abweichenden Zustand führen kann.

In diesem Abschnitt konfigurieren Sie einen Cloud Storage-Bucket, in dem der Remote-Zustand von Terraform gespeichert wird.

  1. Erstellen Sie in Cloud Shell einen Cloud Storage-Bucket.

    gsutil mb gs://${PROJECT_ID}-tfstate
    
  2. Aktivieren Sie die Objektversionsverwaltung, um den Verlauf Ihrer Zustände zu speichern:

    gsutil versioning set on gs://${PROJECT_ID}-tfstate
    
  3. Ersetzen Sie den Platzhalter PROJECT_ID in den Dateien terraform.tfvars und backend.tf durch Ihre Projekt-ID:

    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./example-pipelines/environments/*/terraform.tfvars
    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./example-pipelines/environments/*/backend.tf
    
    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./jenkins-gke/tf-gke/terraform.tfvars
    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./jenkins-gke/tf-gke/backend.tf
    
  4. Prüfen Sie, ob alle Dateien aktualisiert wurden:

    git status
    

    Die Ausgabe sieht so aus:

    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:   example-pipelines/environments/dev/backend.tf
            modified:   example-pipelines/environments/dev/terraform.tfvars
            modified:   example-pipelines/environments/prod/backend.tf
            modified:   example-pipelines/environments/prod/terraform.tfvars
            modified:   jenkins-gke/tf-gke/backend.tf
            modified:   jenkins-gke/tf-gke/terraform.tfvars
    
  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 möglicherweise authentifizieren, um die vorherigen Änderungen vorzunehmen.

GKE-Cluster erstellen und Jenkins installieren

In diesem Abschnitt verwenden Sie Terraform und Helm, um Ihre Umgebung für die Verwaltung der Infrastruktur als Code einzurichten. Zuerst konfigurieren Sie mit Terraform und dem Cloud Foundations Toolkit eine Virtual Private Cloud, einen GKE-Cluster und Workload Identity. Anschließend installieren Sie Jenkins mithilfe von Helm in dieser Umgebung.

Bevor Sie mit dem Ausführen von Terraform-Befehlen beginnen, müssen Sie ein persönliches GitHub-Zugriffstoken erstellen. Dieses Token ist erforderlich, damit Jenkins auf Ihr verzweigtes Repository zugreifen kann.

Persönliches GitHub-Zugriffstoken erstellen

  1. Melden Sie sich bei GitHub an.
  2. Klicken Sie auf Ihr Profilbild und dann auf Settings.
  3. Klicken Sie auf Developer settings und dann auf Personal access tokens.
  4. Klicken Sie auf Generate new token und geben Sie im Feld Note eine Beschreibung für das Token ein. Wählen Sie den Bereich repo aus.
  5. Klicken Sie auf Generate token und kopieren Sie das neu erstellte Token in die Zwischenablage.

    Token generieren und in die Zwischenablage kopieren

  6. Speichern Sie das Token in Cloud Shell in der Variablen GITHUB_TOKEN. Dieser Variableninhalt wird später als Secret in Ihrem GKE-Cluster gespeichert.

    GITHUB_TOKEN="NEWLY_CREATED_TOKEN"
    

GKE-Cluster erstellen und Jenkins installieren

Jetzt erstellen Sie den GKE-Cluster. Dieser Cluster enthält eine Workload Identity (jenkins-wi-jenkins@PROJECT_ID.iam.gserviceaccount.com), mit der Sie Jenkins die Berechtigungen geben können, die für die Seite Dienstkonten in der Cloud Console erforderlich sind. Aufgrund der verbesserten Sicherheitseigenschaften und -verwaltung empfehlen wir die Verwendung von Workload Identity, um in GKE auf Google Cloud-Dienste zuzugreifen.

Zum Verwalten der Google Cloud-Infrastruktur als Code muss Jenkins sich für die Verwendung von Google Cloud APIs authentifizieren. In den folgenden Schritten konfiguriert Terraform das Kubernetes-Dienstkonto (KSA), das von Jenkins als Google-Dienstkonto (GSA) verwendet wird. Mit dieser Konfiguration kann Jenkins beim Zugriff auf Google Cloud APIs automatisch als GSA authentifiziert werden.

Der Einfachheit halber gewähren Sie in dieser Anleitung den Zugriff als Projektbearbeiter. Da diese Rolle jedoch viele Berechtigungen umfasst, müssen Sie sich in Produktionsumgebungen an die Best Practices Ihres Unternehmens für die IT-Sicherheit halten. Das bedeutet normalerweise, den Zugriff mit den geringsten Berechtigungen zu gewähren.

  1. Installieren Sie Terraform in Cloud Shell:

    wget https://releases.hashicorp.com/terraform/0.12.24/terraform_0.12.24_linux_amd64.zip
    unzip terraform_0.12.24_linux_amd64.zip
    sudo mv terraform /usr/local/bin/
    rm terraform_0.12.24_linux_amd64.zip
    
  2. Erstellen Sie den GKE-Cluster und installieren Sie Jenkins:

    cd jenkins-gke/tf-gke/
    terraform init
    terraform plan --var "github_username=$GITHUB_USER" --var "github_token=$GITHUB_TOKEN"
    terraform apply --auto-approve --var "github_username=$GITHUB_USER" --var "github_token=$GITHUB_TOKEN"
    

    Dieser Vorgang kann einige Minuten dauern. Die Ausgabe sieht etwa so aus:

    Apply complete! Resources: 28 added, 0 changed, 0 destroyed.
    
    Outputs:
    
    ca_certificate = LS0tLS1CRU..
    client_token = <sensitive>
    cluster_name = jenkins
    gcp_service_account_email = jenkins-wi-jenkins@PROJECT_ID.iam.gserviceaccount.com
    jenkins_k8s_config_secrets = jenkins-k8s-config
    jenkins_project_id = PROJECT_ID
    k8s_service_account_name = jenkins-wi-jenkins
    kubernetes_endpoint = <sensitive>
    service_account = tf-gke-jenkins-k253@PROJECT_ID.iam.gserviceaccount.com
    zone = us-east4-a
    

    Wenn Jenkins im neu erstellten GKE-Cluster bereitgestellt wird, wird das Jenkins-Basisverzeichnis gemäß der Dokumentation zum Helm-Diagramm in einem nichtflüchtigen Volume gespeichert. Diese Bereitstellung umfasst außerdem eine Pipeline für mehrere Zweige, die mit example-pipelines/environments/Jenkinsfile vorkonfiguriert ist. Dieser wird bei Pull-Anfragen ausgelöst und zu den Zweigen dev und prod zusammengeführt.

  3. Wechseln Sie zurück zum Hauptordner:

    cd ../..
    
  4. Rufen Sie die soeben erstellten Cluster-Anmeldedaten ab:

    gcloud container clusters get-credentials jenkins --zone=us-east4-a --project=${PROJECT_ID}
    
  5. Rufen Sie die Jenkins-URL und -Anmeldedaten ab:

    JENKINS_IP=$(kubectl get service jenkins -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    JENKINS_PASSWORD=$(kubectl get secret jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo
    printf "Jenkins url: http://$JENKINS_IP\nJenkins user: admin\nJenkins password: $JENKINS_PASSWORD\n"
    
  6. Melden Sie sich mit den ausgegebenen Informationen aus dem vorherigen Schritt bei Jenkins an.

  7. Konfigurieren Sie den Jenkins-Speicherort so, dass GitHub Links erstellen kann, die direkt zu Ihren Builds führen. Klicken Sie auf Manage Jenkins > Configure System und legen Sie im Feld Jenkins URL Ihre Jenkins-URL fest.

Umgebungskonfiguration in einem neuen Feature-Branch ändern

Der Großteil Ihrer Umgebung ist jetzt konfiguriert. Sie können nun einige Codeänderungen vornehmen.

  1. Erstellen Sie in Cloud Shell einen neuen Featurezweig, in dem Sie arbeiten können, ohne dass dies Auswirkungen auf andere Personen in Ihrem Team hat:

    git checkout -b change-vm-name
    
  2. Ändern Sie den Namen der virtuellen Maschine:

    cd example-pipelines/example-create
    sed -i.bak "s/\${var.environment}-001/\${var.environment}-new/g" main.tf
    

    Sie ändern die Datei main.tf im Ordner example-create. Diese Datei ist über die Umgebungsordner dev und prod verknüpft. Das bedeutet, dass Ihre Änderung in beide Umgebungen übertragen wird.

  3. Übertragen Sie die Codeänderung in den GitHub-Featurezweig:

    git commit -am "change vm name"
    git push --set-upstream origin change-vm-name
    
  4. Wechseln Sie in GitHub zur Hauptseite des verzweigten Repositorys.

  5. Klicken Sie auf den Tab Pull requests für Ihr Repository und dann auf New pull request.

  6. Wählen Sie als base repository Ihr verzweigtes Repository aus.

    Pull-Anfrage für das Basis-Repository erstellen

  7. Wählen Sie für base die Option dev und für compare die Option change-vm-name aus.

    Basis auswählen und Verzweigungen vergleichen

  8. Klicken Sie auf Create pull request.

  9. Sobald Ihre Pull-Anfrage geöffnet ist, wird automatisch ein Jenkins-Job initiiert. Es kann etwa eine Minute dauern, bis Jenkins die neue Pull-Anfrage bestätigt. Klicken Sie auf Show all checks (Alle Prüfungen anzeigen) und warten Sie, bis die Prüfung grün wird.

    Warten, bis das Häkchen grün wird

  10. Klicken Sie für weitere Informationen, einschließlich der Ausgabe des Befehls terraform plan, auf Details.

    Weitere Details zu den Ergebnissen, einschließlich der Ausgabe von

Der Jenkins-Job hat die unter Jenkinsfile definierte Pipeline ausgeführt. Diese Pipeline verhält sich je nach abgerufenem Zweig unterschiedlich. Der Build prüft, ob die Variable TARGET_ENV mit einem Umgebungsordner übereinstimmt. Ist dies der Fall, führt Jenkins für diese Umgebung terraform plan aus. Andernfalls führt Jenkins für alle Umgebungen terraform plan aus, damit die vorgeschlagene Änderung für alle Umgebungen gültig ist. Wenn einer dieser Pläne nicht ausgeführt werden kann, schlägt der Build fehl.

terraform plan wird für alle example-pipelines/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 prüfen, damit Sie beispielsweise keiner nicht autorisierten Entität Zugriffsrechte erteilen.

Hier ist der terraform plan-Code im JENKINSFILE:

stage('TF plan') {
  when { anyOf {branch "prod";branch "dev";changeRequest() } }
  steps {
    container('terraform') {
      sh '''
      if [[ $CHANGE_TARGET ]]; then
        TARGET_ENV=$CHANGE_TARGET
      else
        TARGET_ENV=$BRANCH_NAME
      fi

      if [ -d "example-pipelines/environments/${TARGET_ENV}/" ]; then
        cd example-pipelines/environments/${TARGET_ENV}
        terraform plan
      else
        for dir in example-pipelines/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 Umgebungszweige ausgeführt. In allen anderen Fällen wird er jedoch ignoriert. In diesem Abschnitt haben Sie eine Codeänderung an einen neuen Zweig gesendet, es wurden also keine Infrastrukturbereitstellungen auf Ihr Cloud-Projekt angewendet.

Hier ist der terraform apply-Code im JENKINSFILE:

stage('TF Apply') {
  when { anyOf {branch "prod";branch "dev" } }
  steps {
    container('terraform') {
      sh '''
      TARGET_ENV=$BRANCH_NAME

      if [ -d "example-pipelines/environments/${TARGET_ENV}/" ]; then
        cd example-pipelines/environments/${TARGET_ENV}
        terraform apply -input=false -auto-approve
      else
        echo "*************** SKIPPING APPLY ******************"
        echo "Branch '$TARGET_ENV' does not represent an official environment."
        echo "*************************************************"
      fi'''
    }
  }
}

Erfolgreiche Ausführung von Jenkins vor dem Zusammenführen der Zweige erzwingen

Sie können dafür sorgen, dass nur dann eine Zusammenführung erfolgt, wenn der Jenkins-Job erfolgreich ausgeführt wurde.

  1. Wechseln Sie in GitHub zur Hauptseite des verzweigten Repositorys.
  2. Klicken Sie unter dem Repository-Namen auf Settings.
  3. Klicken Sie auf Branches.
  4. Klicken Sie bei Branch protection rules auf Add rule.
  5. Geben Sie im Feld Branch name pattern dev ein.
  6. Wählen Sie unter Protect matching branches die Option Require status checks to pass before merging und dann continuous-integration/jenkins/pr-merge aus.

    Optional: Aktivieren Sie die Optionen Require pull request reviews before merging und Include administrators, wenn Sie verhindern möchten, dass in der Produktion nicht geprüfte und nicht autorisierte Pull-Anfragen zusammengeführt werden.

  7. Klicken Sie auf Create.

  8. Wiederholen Sie die Schritte 4 bis 7 und setzen Sie Branch name pattern auf prod.

Diese Konfiguration ist wichtig, um die Zweige dev und prod zu schützen. Das bedeutet, dass zuerst Commits in einen anderen Zweig übertragen werden müssen und erst danach im geschützten Zweig zusammengeführt werden. In dieser Anleitung muss für den Schutz die Ausführung des Jenkins-Jobs erfolgreich sein, damit die Zusammenführung zulässig ist. In der neu erstellten Pull-Anfrage können Sie erkennen, ob Ihre Konfiguration angewendet wurde. Achten Sie auf die grünen Häkchen.

Prüfen, ob die Konfiguration angewendet wurde

Änderungen an der Entwicklungsumgebung übernehmen

Sie haben eine Pull-Anfrage, die noch zusammengeführt werden muss. Jetzt können Sie den gewünschten Zustand auf Ihre dev-Umgebung anwenden.

  1. Wechseln Sie in GitHub zur Hauptseite des verzweigten Repositorys.
  2. Klicken Sie unter Ihrem Repository-Namen auf Pull requests.
  3. Klicken Sie auf die Pull-Anfrage, die Sie erstellt haben.
  4. Klicken Sie auf Merge pull request (Pull-Anfrage zusammenführen) und dann auf Confirm merge (Zusammenführen bestätigen).

    Pull-Anfrage zusammenführen und bestätigen

  5. Klicken Sie in Jenkins auf Open Blue Ocean. Prüfen Sie dann im Projekt terraform-jenkins-create-demo mit mehreren Zweigen im Tab Branches das Statussymbol. So können Sie feststellen, ob ein neuer dev-Job ausgelöst wurde. Bis zum Start kann es etwa eine Minute dauern.

    Prüfen, ob ein neuer **dev**-Job ausgelöst wurde

  6. Rufen Sie in der Cloud Console die Seite VM-Instanzen auf und prüfen Sie, ob die VM mit dem neuen Namen vorhanden ist.

    Zu "VM-Instanzen"

    Prüfen, ob die VM mit dem neuen Namen vorhanden ist

Änderungen an der Produktionsumgebung übernehmen

Nachdem Sie Ihre Entwicklungsumgebung getestet haben, können Sie den Infrastrukturcode für die Produktion übernehmen.

  1. Wechseln Sie in GitHub zur Hauptseite des verzweigten Repositorys.
  2. Klicken Sie auf New pull request (Neue Pull-Anfrage).
  3. Wählen Sie für base repository das verzweigte Repository aus.

    Verzweigtes Repository auswählen

  4. Wählen Sie für base die Option prod und für compare die Option dev aus.

    Verzweigte Repositories für

  5. Klicken Sie auf Create pull request.

  6. Geben Sie unter title einen Titel wie Promoting vm name change ein und klicken Sie auf Create pull request.

  7. Warten Sie, bis das Häkchen grün ist. Dies kann eine oder zwei Minuten dauern. Klicken Sie dann neben continuous-integration/jenkins/pr-merge auf den Link Details.

    Warten, bis das Häkchen grün wird

  8. Wählen Sie in Jenkins TF Plan aus und prüfen Sie die vorgeschlagenen Änderungen in den Logs.

    Die vorgeschlagenen Änderungen in den Logs prüfen

  9. Wenn die vorgeschlagenen Änderungen korrekt sind, klicken Sie in GitHub auf Merge pull request und dann auf Confirm merge.

  10. Öffnen Sie in der Cloud Console die Seite VM-Instanzen und prüfen Sie, ob Ihre Produktions-VM bereitgestellt wurde.

    VM-Instanzen

    Prüfen, ob die Produktions-VM bereitgestellt wurde

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

  • Bereitstellungen für separate Anwendungsfälle hinzufügen
  • Weitere Umgebungen erstellen, die Ihren Anforderungen entsprechen
  • Ein Projekt pro Umgebung anstelle einer VPC pro Umgebung verwenden

Bereinigen

So vermeiden Sie, dass Ihr Google Cloud Platform-Konto für die in dieser Anleitung genutzten Ressourcen unnötig mit Gebühren belastet wird:

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