Containeranwendungen mit einer CI/CD-Pipeline entwickeln und bereitstellen

Last reviewed 2022-11-18 UTC

In diesem Bereitstellungsleitfaden wird beschrieben, wie Sie ein System für Entwicklung, Continuous Integration (CI) und Continuous Delivery (CD) mit einem integrierten Satz von Google Cloud-Tools einrichten und verwenden. Mit diesem System können Sie Anwendungen in Google Kubernetes Engine (GKE) entwickeln und bereitstellen.

In diesem Leitfaden erfahren Sie, wie Sie die Architektur erstellen, die in der Bereitstellungspipeline für die Entwicklung und Bereitstellung von Containeranwendungen beschrieben ist.

Dieser Bereitstellungsleitfaden richtet sich an Softwareentwickler und -betreiber. Dabei übernehmen Sie die folgenden Rollen:

  • Zuerst agieren Sie als Betreiber zum Einrichten der CI/CD-Pipeline. Die Hauptkomponenten dieser Pipeline sind Cloud Build, Artifact Registry und Cloud Deploy.
  • Anschließend agieren Sie als Entwickler, um eine Anwendung mit Cloud Code zu ändern. Wenn Sie als Entwickler agieren, sehen Sie die integrierten Funktionen, die diese Pipeline bietet.
  • Schließlich agieren Sie als Betreiber und führen die Schritte zum Bereitstellen einer Anwendung in der Produktion aus.

In diesem Bereitstellungsleitfaden wird davon ausgegangen, dass Sie mit dem Ausführen von gcloud-Befehlen in Google Cloud und mit dem Bereitstellen von Anwendungscontainern in GKE vertraut sind.

Architektur

Das folgende Diagramm zeigt die in diesem Bereitstellungsleitfaden verwendeten Ressourcen:

System mit Cloud Code, Cloud Build, Artifact Registry, Cloud Deploy und GKE entwickeln und bereitstellen

Weitere Informationen zu den in dieser Architektur verwendeten Komponenten finden Sie unter Bereitstellungspipeline zum Entwickeln und Bereitstellen von Containeranwendungen.

Lernziele

Als Betreiber tun Sie Folgendes:

  • Richten Sie die CI-Pipeline und die CD-Pipeline ein. Diese Konfiguration umfasst Folgendes:
    • Richten Sie die erforderlichen Berechtigungen ein.
    • Erstellen Sie die GKE-Cluster für die Staging- und die Produktionsumgebung.
    • Erstellen Sie in Cloud Source Repositories ein Repository für den Quellcode.
    • Erstellen Sie in Artifact Registry ein Repository für den Anwendungscontainer.
    • Erstellen Sie einen Cloud Build-Trigger im Haupt-GitHub-Repository.
    • Erstellen Sie eine Cloud Deploy-Bereitstellungspipeline und Ziele. Die Ziele sind die Staging- und die Produktionsumgebung.
  • Starten Sie den CI/CD-Prozess für die Bereitstellung für das Staging und stufen Sie dann zur Produktion hoch.

Als Entwickler nehmen Sie eine Änderung an der Anwendung vor. Gehen Sie dazu so vor:

  • Klonen Sie das Repository für die Arbeit mit einer vorkonfigurierten Entwicklungsumgebung.
  • Nehmen Sie in Ihrem Entwicklerarbeitsbereich eine Änderung an der Anwendung vor.
  • Erstellen Sie die Änderung und testen Sie sie. Die Tests enthalten einen Validierungstest für die Governance.
  • Sehen Sie sich die Änderung in einem Entwicklungscluster an und validieren Sie sie. Dieser Cluster wird mit minikube ausgeführt.
  • Übernehmen Sie die Änderung in das Haupt-Repository.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweis

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

    Go to project selector

  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  3. Enable the Artifact Registry, Cloud Build, Cloud Deploy, Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, and Service Networking APIs.

    Enable the APIs

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

Umgebung vorbereiten

In diesem Abschnitt agieren Sie als Anwendungsbetreiber und tun Folgendes:

  • Richten Sie die erforderlichen Berechtigungen ein.
  • Erstellen Sie die GKE-Cluster für die Staging- und die Produktionsumgebung.
  • Klonen Sie das Quell-Repository.
  • Erstellen Sie in Cloud Source Repositories ein Repository für den Quellcode.
  • Erstellen Sie in Artifact Registry ein Repository für die Containeranwendung.

Berechtigungen einrichten

In diesem Abschnitt gewähren Sie die Berechtigungen, die zum Einrichten der CI/CD-Pipeline erforderlich sind.

  1. Wenn Sie in einer neuen Instanz des Cloud Shell-Editors arbeiten, geben Sie das Projekt an, das für diesen Bereitstellungsleitfaden verwendet werden soll:

    gcloud config set project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID des Projekts, das Sie die für diesen Bereitstellungsleitfaden ausgewählt oder erstellt wurden.

    Klicken Sie auf Autorisieren, wenn ein Dialogfeld angezeigt wird.

  2. Prüfen Sie, ob das Compute Engine-Standarddienstkonto die erforderlichen Berechtigungen hat, um Jobs in Cloud Deploy auszuführen und Container aus Artifact Registry abzurufen. Cloud Build und Cloud Deploy verwenden dieses Standarddienstkonto.

    Dieses Dienstkonto hat möglicherweise bereits die erforderlichen Berechtigungen. Dadurch werden die erforderlichen Berechtigungen für Projekte gewährt, die automatische Rollenzuweisungen für Standarddienstkonten deaktivieren.

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/clouddeploy.jobRunner"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/artifactregistry.reader"

  3. Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung, Bereitstellungen mit Cloud Deploy aufzurufen und die Bereitstellungspipeline und die Zieldefinitionen zu aktualisieren:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
    --role="roles/clouddeploy.operator"

    Weitere Informationen zu dieser IAM-Rolle finden Sie unter der Rolle clouddeploy.operator.

  4. Erteilen Sie dem Dienstkonto von Cloud Build und Cloud Deploy die Berechtigung zum Bereitstellen in GKE:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/container.admin"

    Weitere Informationen zu dieser IAM-Rolle finden Sie unter der Rolle container.admin.

  5. Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigungen zum Aufrufen von Cloud Deploy-Vorgängen:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
    --role="roles/iam.serviceAccountUser"

    Wenn Cloud Build Cloud Deploy aufruft, verwendet es ein Compute Engine-Dienstkonto, um einen Release zu erstellen. Aus diesem Grund ist diese Berechtigung erforderlich.

    Weitere Informationen zu dieser IAM-Rolle finden Sie unter der Rolle iam.serviceAccountUser.

Sie haben jetzt die Berechtigungen gewährt, die für die CI/CD-Pipeline erforderlich sind.

GKE-Cluster erstellen

In diesem Abschnitt erstellen Sie die Staging- und die Produktionsumgebung, die beide GKE-Cluster sind. Sie müssen den Entwicklungscluster hier nicht einrichten, da er minikube verwendet.

  1. Erstellen Sie den Staging- und den Produktionscluster:

    gcloud container clusters create-auto staging \
    --region us-central1 \
    --project=$(gcloud config get-value project) \
    --async

gcloud container clusters create-auto prod \
    --region us-central1 \
    --project=$(gcloud config get-value project) \
    --async

    Im Staging-Cluster testen Sie Änderungen an Ihrem Code. Nachdem Sie geprüft haben, dass die Bereitstellung in der Staging-Phase keine negativen Auswirkungen auf die Anwendung hat, nehmen Sie die Bereitstellung in der Produktion vor.

  2. Führen Sie den folgenden Befehl aus und prüfen Sie, ob die Ausgabe STATUS: RUNNING für den Staging- und den Produktionscluster enthält:

    gcloud container clusters list

  3. Rufen Sie die Anmeldedaten für Ihre kubeconfig-Dateien für den Staging- und den Produktionscluster ab.

    gcloud container clusters get-credentials staging --region us-central1

gcloud container clusters get-credentials prod --region us-central1

    Sie verwenden diese Anmeldedaten, um mit den GKE-Clustern zu interagieren, um beispielsweise zu prüfen, dass eine Anwendung ordnungsgemäß ausgeführt wird.

Sie haben jetzt die GKE-Cluster für die Staging- und die Produktionsumgebung erstellt.

IDE öffnen und Repository klonen

So klonen Sie das Repository und rufen die Anwendung in Ihrer Entwicklungsumgebung auf:

  1. Klonen Sie das GitHub-Repository in Cloud Shell.

    In Cloud Shell öffnen

  2. Klicken Sie auf Bestätigen.

    Der Cloud Shell-Editor wird geöffnet und klont das Beispiel-Repository.

    Sie können sich den Anwendungscode jetzt im Cloud Shell-Editor ansehen.

  3. Geben Sie das Projekt an, das für diesen Bereitstellungsleitfaden verwendet werden soll:

    gcloud config set project PROJECT_ID

    Klicken Sie auf Autorisieren, wenn ein Dialogfeld angezeigt wird.

Sie haben nun den Quellcode für die Anwendung in Ihrer Entwicklungsumgebung.

Dieses Quell-Repository enthält die Cloud Build- und Cloud Deploy-Dateien, die für die CI/CD-Pipeline erforderlich sind.

Repositories für den Quellcode und die Container erstellen

In diesem Abschnitt richten Sie in Cloud Source Repositories ein Repository für den Quellcode und in Artifact Registry ein Repository ein, um die von der CI/CD-Pipeline erstellten Container zu speichern.

  1. Erstellen Sie in Cloud Source Repositories ein Repository, um den Quellcode zu speichern und mit dem CI/CD-Prozess zu verknüpfen:

    gcloud source repos create cicd-sample

  2. Achten Sie darauf, dass die Cloud Deploy-Konfigurationen auf das richtige Projekt ausgerichtet sind:

    sed -i s/project-id-placeholder/$(gcloud config get-value project)/g deploy/*
git config --global credential.https://source.developers.google.com.helper gcloud.sh
git remote add google https://source.developers.google.com/p/$(gcloud config get-value project)/r/cicd-sample

  3. Übertragen Sie den Quellcode per Push an das Repository:

    git push --all google

  4. Erstellen Sie ein Image-Repository in Artifact Registry:

    gcloud artifacts repositories create cicd-sample-repo \
    --repository-format=Docker \
    --location us-central1

Sie haben jetzt ein Repository für den Quellcode in Cloud Source Repositories und ein Repository für den Anwendungscontainer in Artifact Registry. Mit dem Cloud Source Repositories-Repository können Sie den Quellcode klonen und mit der CI/CD-Pipeline verbinden.

CI/CD-Pipeline konfigurieren

In diesem Abschnitt agieren Sie als Anwendungsbetreiber und konfigurieren die CI/CD-Pipeline. Die Pipeline verwendet Cloud Build für CI und Cloud Deploy für CD. Die Schritte der Pipeline werden im Cloud Build-Trigger definiert.

  1. Erstellen Sie einen Cloud Storage-Bucket für Cloud Build, um die Datei artifacts.json zu speichern (die die von Skaffold für jeden Build generierten Artefakte verfolgt):

    gcloud storage buckets create gs://$(gcloud config get-value project)-gceme-artifacts/

    Es empfiehlt sich, die Datei artifacts.json jedes Builds an einem zentralen Ort zu speichern, da sie Rückverfolgbarkeit ermöglicht und die Fehlerbehebung vereinfacht.

  2. Prüfen Sie die Datei cloudbuild.yaml, die den Cloud Build-Trigger definiert und im geklonten Quell-Repository bereits konfiguriert ist.

    Diese Datei definiert den Trigger, der immer dann aufgerufen wird, wenn es einen neuen Push an den Hauptzweig des Quellcode-Repositorys gibt.

    Die folgenden Schritte für die CI/CD-Pipeline sind in der cloudbuild.yaml-Datei:

    • Cloud Build verwendet Skaffold, um den Anwendungscontainer zu erstellen.

    • Cloud Build platziert die Datei artifacts.json des Builds im Cloud Storage-Bucket.

    • Cloud Build platziert den Anwendungscontainer in Artifact Registry.

    • Cloud Build führt Tests für den Anwendungscontainer aus.

    • Der Befehl gcloud deploy apply registriert die folgenden Dateien beim Cloud Deploy-Dienst:

      • deploy/pipeline.yaml, was die Bereitstellungspipeline ist
      • deploy/staging.yaml und deploy/prod.yaml, wobei es sich um die Zieldateien handelt

      Wenn die Dateien registriert sind, erstellt Cloud Deploy die Pipeline und die Ziele, sofern sie noch nicht vorhanden sind, oder erstellt sie neu, wenn die Konfiguration geändert wurde. Die Ziele sind die Staging- und die Produktionsumgebung.

    • Cloud Deploy erstellt einen neuen Release für die Bereitstellungspipeline.

      Dieser Release verweist auf den Anwendungscontainer, der im CI-Prozess erstellt und getestet wurde.

    • Cloud Deploy stellt den Release in der Staging-Umgebung bereit.

    Die Bereitstellungspipeline und die Ziele werden von Cloud Deploy verwaltet und vom Quellcode entkoppelt. Durch diese Entkopplung müssen Sie die Bereitstellungspipeline und die Zieldateien nicht aktualisieren, wenn eine Änderung am Quellcode der Anwendung vorgenommen wird.

  3. Erstellen Sie den Cloud Build-Trigger:

    gcloud beta builds triggers create cloud-source-repositories \
    --name="cicd-sample-main" \
    --repo="cicd-sample" \
    --branch-pattern="main" \
    --build-config="cloudbuild.yaml"

    Dieser Trigger weist Cloud Build an, das Quell-Repository zu überwachen und die Datei cloudbuild.yaml zu verwenden, um auf Änderungen am Repository zu reagieren. Dieser Trigger wird aufgerufen, wenn ein neuer Push an den Hauptzweig auftritt.

  4. Rufen Sie in der Google Cloud Console die Seite Cloud Build auf.

    Zu Cloud Build

    Beachten Sie, dass für Ihre Anwendung keine Builds vorhanden sind.

Sie haben nun die CI- und CD-Pipelines eingerichtet und einen Trigger im Hauptzweig des Repositorys erstellt.

Anwendung im Entwicklerarbeitsbereich ändern

In diesem Abschnitt agieren Sie als Anwendungsentwickler.

Bei der Entwicklung Ihrer Anwendung nehmen Sie mithilfe von Cloud Code als Entwicklungsarbeitsbereich iterative Änderungen an der Anwendung vor und prüfen diese:

  • Nehmen Sie eine Änderung an der Anwendung vor.
  • Erstellen und testen Sie den neuen Code.
  • Stellen Sie die Anwendung im minikube-Cluster bereit und prüfen Sie die Änderungen für den Nutzer.
  • Senden Sie die Änderung an das Haupt-Repository.

Wenn diese Änderung im Haupt-Repository übernommen wird, startet der Cloud Build-Trigger die CI/CD-Pipeline.

Anwendung erstellen, testen und ausführen

In diesem Abschnitt erstellen und testen Sie Ihre Anwendung, stellen Sie bereit und greifen darauf zu.

Verwenden Sie dieselbe Instanz des Cloud Shell-Editors, die Sie im vorherigen Abschnitt verwendet haben. Wenn Sie den Editor geschlossen haben, öffnen Sie in Ihrem Browser den Cloud Shell-Editor, indem Sie ide.cloud.google.com aufrufen.

  1. Starten Sie im Terminal minikube:

    minikube start

    Minikube richtet einen lokalen Kubernetes-Cluster in Cloud Shell ein. Dieser Einrichtungsvorgang dauert einige Minuten. Nach Abschluss wird der minikube-Prozess in der Cloud Shell-Instanz im Hintergrund ausgeführt.

  2. Wählen Sie im Bereich unten im Cloud Shell-Editor Cloud Code aus.

  3. Wählen Sie im schmalen Feld, das zwischen dem Terminal und dem Editor angezeigt wird, In Kubernetes ausführen aus.

    Wenn die Eingabeaufforderung Use current context (minikube) to run the app? angezeigt wird, klicken Sie auf Ja.

    Dieser Befehl erstellt den Quellcode und führt Tests aus. Dies kann einige Minuten dauern. Die Tests umfassen Unittests und einen vorkonfigurierten Validierungsschritt, mit dem die für die Bereitstellungsumgebung festgelegten Regeln geprüft werden. Dadurch wird sichergestellt, dass Sie vor Bereitstellungsproblemen gewarnt werden, auch wenn Sie noch in Ihrer Entwicklungsumgebung arbeiten.

    Auf dem Tab Ausgabe wird der Skaffold-Fortschritt beim Erstellen und Bereitstellen Ihrer Anwendung angezeigt.

    Lassen Sie diesen Tab in diesem Abschnitt geöffnet.

    Wenn der Build und die Tests abgeschlossen sind, wird auf dem Tab Ausgabe Update succeeded angezeigt und es werden zwei URLs angezeigt.

    Wenn Sie Ihre Anwendung erstellen und testen, streamt Cloud Code die Logs und URLs auf dem Tab Ausgabe. Wenn Sie Änderungen vornehmen und Tests in der Entwicklungsumgebung ausführen, können Sie die Version der Anwendung in Ihrer Entwicklungsumgebung sehen und prüfen, ob sie ordnungsgemäß funktioniert.

    Die Ausgabe gibt auch Watching for changes... an, was bedeutet, dass der Überwachungsmodus aktiviert ist. Während sich Cloud Code im Beobachtungsmodus befindet, erkennt der Dienst alle gespeicherten Änderungen in Ihrem Repository und erstellt die Anwendung mit den neuesten Änderungen automatisch neu.

  4. Halten Sie im Cloud Code-Terminal den Mauszeiger über die erste URL in der Ausgabe (http://localhost:8080).

  5. Wählen Sie in der angezeigten Kurzinfo die Option Webvorschau öffnen aus.

    Im Hintergrund führt Cloud Code automatisch eine Portweiterleitung des Traffic zum cicd-sample-Dienst durch, der in minikube ausgeführt wird.

  6. Aktualisieren Sie die Seite in Ihrem Browser.

    Die Zahl neben Zähler erhöht sich, was darauf hinweist, dass die Anwendung auf Ihre Aktualisierung reagiert.

    Lassen Sie diese Seite in Ihrem Browser geöffnet, damit Sie die Anwendung sehen können, wenn Sie Änderungen in Ihrer lokalen Umgebung vornehmen.

Sie haben Ihre Anwendung jetzt in der Entwicklungsumgebung erstellt und getestet. Sie haben die Anwendung in dem in minikube ausgeführten Entwicklungscluster bereitgestellt und sich das nutzerbezogene Verhalten der Anwendung angesehen.

Änderungen vornehmen

In diesem Abschnitt nehmen Sie eine Änderung an der Anwendung vor und sehen sich die Änderung an, während die Anwendung im Entwicklungscluster ausgeführt wird.

  1. Öffnen Sie im Cloud Shell-Editor die Datei index.html.

  2. Suchen Sie nach dem String Sample App Info und ändern Sie ihn in sample app info, sodass der Titel jetzt Kleinbuchstaben verwendet.

    Die Datei wird automatisch gespeichert und löst eine Neuerstellung des Anwendungscontainers aus.

    Cloud Code erkennt die Änderung und stellt die Anwendung automatisch noch einmal bereit. Auf dem Tab Ausgabe wird Update initiated angezeigt. Diese erneute Bereitstellung dauert einige Minuten.

    Dieses Feature zum automatischen erneuten Bereitstellen ist für jede Anwendung verfügbar, die in einem Kubernetes-Cluster ausgeführt wird.

  3. Wenn der Build abgeschlossen ist, rufen Sie Ihren Browser die Seite auf, wo die Anwendung geöffnet ist, und aktualisieren Sie die Seite.

    Beachten Sie bei der Aktualisierung, dass der Text jetzt Kleinbuchstaben verwendet.

Diese Konfiguration ermöglicht ein automatisches Aktualisieren für jede Architektur mit beliebigen Komponenten. Wenn Sie Cloud Code und minikube verwenden, gibt es für alles, was in Kubernetes ausgeführt wird, diese Hot-Reload-Funktion für den Code.

Sie können Fehler in Anwendungen beheben, die in einem Kubernetes-Cluster in Cloud Code bereitgestellt werden. Diese Schritte werden in diesem Bereitstellungsleitfaden nicht behandelt, aber weitere Informationen finden Sie unter Kubernetes-Anwendung debuggen

Commit für Code durchführen

Nachdem Sie nun eine Änderung an der Anwendung vorgenommen haben, können Sie den Code mit Commit speichern.

  1. Konfigurieren Sie Ihre git-Identität:

    git config --global user.email "YOU@EXAMPLE.COM"
git config --global user.name "NAME"

    Dabei gilt:

    • YOU@EXAMPLE.COM: die E-Mail-Adresse, die mit Ihrem GitHub-Konto verbunden ist.
    • NAME: der Name, der mit Ihrem GitHub-Konto verbunden ist.

  2. Führen Sie vom Terminal aus einen Commit für den Code aus:

    git add .
git commit -m "use lowercase for: sample app info"

    Hier müssen Sie den Befehl git push nicht ausführen. Das kommt später.

In der Entwicklungsumgebung haben Sie jetzt eine Änderung an der Anwendung vorgenommen, die Änderung erstellt und getestet und das nutzerbezogene Verhalten dieser Änderungen überprüft. Die Tests in der Entwicklungsumgebung umfassen Governance-Prüfungen, mit denen Sie Probleme beheben können, die Probleme in der Produktionsumgebung verursachen.

Wenn Sie in diesem Bereitstellungsleitfaden den Code per Commit an das Haupt-Repository übergeben, wird kein Code Review durchgeführt. Der Code Review oder die Änderungsgenehmigung ist jedoch ein empfohlener Prozess für die Softwareentwicklung.

Weitere Informationen zu den Best Practices für die Änderungsgenehmigung finden Sie unter Änderungsgenehmigung optimieren.

Änderung in der Produktion bereitstellen

In diesem Abschnitt agieren Sie als Anwendungsbetreiber und tun Folgendes:

  • CI/CD-Pipeline auslösen, die den Release in der Staging-Umgebung bereitstellt
  • Release zur Produktion hochstufen und genehmigen

CI/CD-Pipeline starten und für das Staging bereitstellen

In diesem Abschnitt starten Sie die CI/CD-Pipeline durch Aufrufen des Cloud Build-Triggers. Dieser Trigger wird aufgerufen, wenn eine Änderung per Commit an das Haupt-Repository übergeben wird. Sie können das CI-System auch mit einem manuellen Trigger initiieren.

  1. Führen Sie im Cloud Shell-Editor den folgenden Befehl aus, um einen Build auszulösen:

    git push google

    Dieser Build enthält die Änderung, die Sie an cicd-sample vorgenommen haben.

  2. Kehren Sie zum Cloud Build-Dashboard zurück und sehen Sie, dass ein Build erstellt wird.

  3. Klicken Sie im Build-Log rechts auf Wird ausgeführt: cicd-sample – cicd-sample-main und suchen Sie nach dem blauen Text, der den Anfang und das Ende jedes Schritts angibt.

    Schritt 0 zeigt die Ausgabe der skaffold build- und skaffold test-Anweisungen aus der Datei cloudbuild.yaml. Die Build- und Testaufgaben in Schritt 0 (dem CI-Teil der Pipeline) wurden abgeschlossen, sodass jetzt die Bereitstellungsaufgaben von Schritt 1 (dem CD-Teil der Pipeline) ausgeführt werden.

    Dieser Schritt wird mit der folgenden Meldung abgeschlossen:

    Created Cloud Deploy rollout ROLLOUT_NAME in target staging

  4. Öffnen Sie die Cloud Deploy-Seite für Bereitstellungspipelines und klicken Sie auf die Pipeline cicd-sample delivery.

    Die Anwendung wird in der Staging-Umgebung bereitgestellt, aber nicht in der Produktion.

  5. Prüfen Sie, ob die Anwendung in der Staging-Umgebung ordnungsgemäß funktioniert:

    kubectl proxy --port 8001 --context gke_$(gcloud config get-value project)_us-central1_staging

    Dieser Befehl richtet einen kubectl-Proxy für den Zugriff auf die Anwendung ein.

  6. Greifen Sie über Cloud Shell auf die Anwendung zu:

    1. Öffnen Sie im Cloud Shell-Editor einen neuen Terminaltab.

    2. Senden Sie eine Anfrage an localhost, um einen Zähler zu erhöhen:

      curl -s http://localhost:8001/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter

      Sie können diesen Befehl mehrmals ausführen und jedes Mal beobachten, wie sich der Zählerwert erhöht.

      Beachten Sie beim Aufrufen der Anwendung, dass der geänderte Text in der Version der Anwendung vorliegt, die Sie für das Staging bereitgestellt haben.

    3. Schließen Sie diesen zweiten Tab.

    4. Drücken Sie im ersten Tab Control+C, um den Proxy zu beenden.

Sie haben jetzt den Cloud Build-Trigger aufgerufen, um den CI-Prozess zu starten. Dazu gehört das Erstellen der Anwendung, das Bereitstellen der Anwendung in der Staging-Umgebung und das Ausführen von Tests, um zu prüfen, ob die Anwendung in der Staging-Umgebung funktioniert.

Der CI-Prozess ist erfolgreich, wenn die Code-Builds und -Tests in der Staging-Umgebung erfolgreich sind. Der Erfolg des CI-Prozesses initiiert dann das CD-System in Cloud Deploy.

Release zur Produktion hochstufen

In diesem Abschnitt stufen Sie den Release vom Staging zur Produktion hoch. Das Produktionsziel ist so vorkonfiguriert, dass eine Genehmigung erforderlich ist. Sie genehmigen es also manuell.

Für Ihre eigene CI/CD-Pipeline können Sie eine Bereitstellungsstrategie verwenden, die die Bereitstellung schrittweise startet, bevor Sie eine vollständige Bereitstellung in der Produktion durchführen. Wenn Sie die Bereitstellung schrittweise starten, können Sie Probleme leichter erkennen und bei Bedarf einen früheren Release wiederherstellen.

So stufen Sie den Release zur Produktion hoch:

  1. Öffnen Sie die Cloud Deploy-Übersicht für Bereitstellungspipelines und wählen Sie die Pipeline cicd-sample aus.

  2. Stufen Sie die Bereitstellung vom Staging zur Produktion hoch. Führen Sie dazu die folgenden Schritte aus:

    1. Klicken Sie im Pipelinediagramm oben auf der Seite im Staging-Feld auf die blaue Schaltfläche Hochstufen.

    2. Klicken Sie im angezeigten Fenster unten auf die Schaltfläche Hochstufen.

    Die Bereitstellung wird noch nicht in der Produktion ausgeführt. Sie wartet auf die erforderliche manuelle Genehmigung.

  3. Genehmigen Sie die Bereitstellung manuell:

    1. Klicken Sie in der Pipelinevisualisierung auf die Schaltfläche Prüfen zwischen den Staging- und Produktionsfeldern.

    2. Klicken Sie im angezeigten Fenster auf die Schaltfläche Prüfen.

    3. Klicken Sie im nächsten Fenster auf Genehmigen.

    4. Kehren Sie zur Cloud Deploy-Übersicht für Bereitstellungspipelines zurück und wählen Sie die Pipeline cicd-sample aus.

  4. Sobald die Pipelinevisualisierung das Produktionsfeld grün anzeigt hat (Roll-out war also erfolgreich), prüfen Sie, ob die Anwendung in der Produktion funktioniert. Richten Sie dazu einen kubectl-Proxy ein, den Sie für den Zugriff auf die Anwendung verwenden:

    kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prod

  5. Greifen Sie über Cloud Shell auf die Anwendung zu:

    1. Öffnen Sie im Cloud Shell-Editor einen neuen Terminaltab.

    2. Erhöhen Sie den Zähler:

      curl -s http://localhost:8002/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter

      Sie können diesen Befehl mehrmals ausführen und jedes Mal beobachten, wie sich der Zählerwert erhöht.

    3. Schließen Sie diesen zweiten Terminaltab.

    4. Drücken Sie im ersten Tab Control+C, um den Proxy zu beenden.

Sie haben jetzt die Produktionsbereitstellung hochgestuft und genehmigt. Die Anwendung mit Ihrer letzten Änderung wird jetzt in der Produktion ausgeführt.

Bereinigen

Damit Ihrem Google Cloud-Konto die in diesem Bereitstellungsleitfaden verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder das Projekt löschen, das die Ressourcen enthält, oder das Projekt beibehalten und die einzelnen Ressourcen löschen.

Option 1: Projekt löschen

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

    Go to Manage resources

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

Option 2: Einzelne Ressourcen löschen

  1. Löschen Sie die Cloud Deploy-Pipeline:

    gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --force

  2. Löschen Sie den Cloud Build-Trigger:

    gcloud beta builds triggers delete cicd-sample-main

  3. Löschen Sie den Staging- und den Produktionscluster:

    gcloud container clusters delete staging

gcloud container clusters delete prod

  4. Löschen Sie das Repository in Cloud Source Repositories:

    gcloud source repos delete cicd-sample

  5. Löschen Sie die Cloud Storage-Buckets.

    gcloud storage rm -r gs://$(gcloud config get-value project)-gceme-artifacts/

gcloud storage rm -r gs://$(gcloud config get-value project)_clouddeploy/

  6. Löschen Sie das Repository in Artifact Registry:

    gcloud artifacts repositories delete cicd-sample-repo \
    --location us-central1

Nächste Schritte