Moderne CI/CD mit GKE: Entwickler-Workflow anwenden

Last reviewed 2023-09-11 UTC

Standard

---

In dieser Anleitung erfahren Sie, wie Sie mit Google Kubernetes Engine (GKE) eine neue Anwendung einrichten, ein Feature für die Anwendung entwickeln und diese mithilfe moderner CI/CD-Techniken (Continuous Integration/Continuous Delivery) für die Produktion bereitstellen.

Dieses Dokument ist Teil der folgenden Reihe:

• Moderne CI/CD mit GKE: Ein Softwarebereitstellungs-Framework
• Moderne CI/CD mit GKE: CI/CD-System erstellen (Referenzarchitektur)
• Moderne CI/CD mit GKE: Entwickler-Workflow anwenden (dieses Dokument)

In dieser Anleitung verwenden Sie Tools wie Skaffold, kustomize, Artifact Registry, Config Sync, Cloud Build und Cloud Deploy um Ihre Anwendung zu entwickeln, zu erstellen und bereitzustellen.

Dieses Dokument richtet sich an Unternehmensarchitekten und Anwendungsentwickler sowie IT-, DevOps- und Site Reliability Engineering-Teams (SRE). Erfahrung mit automatisierten Bereitstellungstools und -prozessen ist hilfreich, um die Konzepte in diesem Dokument zu verstehen.

Architektur

In dieser Anleitung richten Sie eine neue Anwendung ein. Anschließend entwickeln Sie ein neues Feature und stellen die Anwendung in Entwicklungs-, Staging- und Produktionsumgebungen bereit. Die Referenzarchitektur enthält die Infrastruktur und Tools, die zum Onboarding und zur Freigabe einer neuen Anwendung mit dem im folgenden Diagramm gezeigten Workflow erforderlich sind:

Der Workflow beginnt mit dem Code-Repository für CI und umfasst die folgenden Schritte:

1. Sie geben den Anwendungsquellcode über Ihre Anwendungs-Repositories frei.

2. Wenn Sie einen Commit für den Code ausführen und ihn in das Anwendungs-Repository übertragen, wird automatisch eine CI-Pipeline in Cloud Build ausgelöst. Der CI-Prozess erstellt ein Container-Image und überträgt es per Push in die Artifact Registry.

3. Der CI-Prozess erstellt auch einen CD-Release für die Anwendung in Cloud Deploy.

4. Die CD-Version generiert vollständig gerenderte Kubernetes-Manifeste für die Entwicklung mit skaffold und stellt sie im GKE-Cluster der Entwicklung bereit.

5. Der CD-Release wird dann von der Entwicklung zu einem Staging-Ziel hochgestuft, das vollständig gerenderte Staging-Manifeste generiert und im Staging-GKE-Cluster bereitstellt.

6. Anschließend wird der CD-Release vom Staging zur Produktion hochgestuft, der vollständig gerenderte Produktionsmanifeste generiert und in GKE-Produktionsclustern bereitstellt.

Weitere Informationen zu den Tools und die Infrastruktur für diesen Workflow finden Sie unter Moderne CI/CD mit GKE: CI-/CD-System erstellen.

Lernziele

• Neue Anwendung einrichten

• Stellen Sie die Anwendung in der Entwicklungsumgebung bereit.

• Entwickeln Sie ein neues Feature und stellen Sie es in der Entwicklungsumgebung bereit.

• Stufen Sie das neue Feature zum Staging hoch und geben Sie es dann in der Produktion frei.

• Testen Sie die Ausfallsicherheit.

Kosten

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

• Google Kubernetes Engine
• Google Kubernetes Engine (GKE) Enterprise edition for Config Sync
• Artifact Registry
• Cloud Build
• Cloud Deploy

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.

Hinweise

• Für diese Anleitung stellen Sie die Referenzarchitektur in dieser Reihe bereit.

Umgebung vorbereiten

1. Wenn Sie direkt über Moderne CI/CD mit GKE: CI-/CD-System erstellen fortfahren, fahren Sie mit dem nächsten Abschnitt fort. Wenn Sie jedoch eine neue Sitzung haben oder Ihre Sitzung abgelaufen ist, öffnen Sie Cloud Shell und legen das Projekt fest, in dem Sie die Infrastruktur für die Referenzarchitektur installiert haben:

   gcloud config set core/project PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.

Neue Anwendung einrichten

Die Referenzarchitektur enthält eine Anwendungs-Factory. Diese Factory ist eine Sammlung eines Git-Repositorys mit dem Namen application-factory-repo und den folgenden Cloud Build-Triggern:

• create-app
• tf-plan
• tf-apply
• create-team

Sie verwenden die Anwendungs-Factory, um eine neue Anwendung aus Starter-Repositories einzurichten. Das Onboarding von Anwendungen besteht aus den folgenden Schritten:

1. Anwendungsdefinition erstellen: Sie erstellen die Anwendungsdefinition in einer Terraform-Datei und speichern sie in application-factory-repo, was als Anwendungskatalog fungiert.

2. Anwendungsinfrastruktur erstellen: Sie führen Terraform in der Anwendungsdefinitionsdatei aus, um die Anwendungsinfrastruktur zu erstellen. Die Anwendungsinfrastruktur umfasst Folgendes:

   1. Eine Landing-Zone für die neue Anwendung umfasst die Definition des Namespace, des Dienstkontos und der Basisrichtlinien im Repository acm-gke-infrastructure-repo. Die Landing-Zone wird nur in einem GKE-Entwicklungscluster erstellt, während eine neue Anwendung eingerichtet wird. Damit wird die Blockierung der Entwickler aufgehoben, damit sie die Entwicklungsumgebung verwenden und mit der Iteration beginnen können. Die Landing-Zone in den Staging- und Produktionsclustern wird mit dem GitOps-Ansatz erstellt. Dieser Ansatz wird weiter unten in diesem Dokument erläutert, wenn Sie die Version in diesen Clustern hochstufen möchten.

   2. Das Infrastruktur-Repository des Infrastrukturstarter-Repositorys, das den Code zum Erstellen der CI-Pipeline in Cloud Build, der CD-Pipeline in Cloud Deploy und des Artifact Registry-Repositorys zum Speichern von Artefakten hostet.

   3. Ein Cloud Build-Trigger für die Infrastruktur, der den Code im Infrastruktur-Repository verwendet und basierend auf seiner Definition die Ressourcen erstellt.

   4. Ein Anwendungs-Repository aus dem Anwendungsstart-Repository, das den Quellcode der Anwendung hostet.

3. CI/CD-Ressourcen der Anwendung erstellen: Sie verwenden die Anwendungsinfrastruktur, um CI/CD-Ressourcen für die Anwendung zu erstellen.

Hinweis: Mit der Referenzarchitektur können Sie die gesamten Schritte zur Einrichtung und Bereitstellung von Anwendungen automatisieren. Damit Sie die Architektur besser verstehen, werden diese Schritte in diesem Dokument erläutert.

Erstellen Sie die Anwendungsdefinition:

Führen Sie den Trigger create-app aus, um eine Anwendungsdefinitionsdatei in application-factory-repo zu generieren. Die Definitionsdatei enthält die deklarative Definition der Ressourcen, die zum Erstellen einer Anwendung erforderlich sind.

1. Wechseln Sie in der Google Cloud Console zur Seite "Cloud Build".

   Zur Cloud Build-Seite

2. Klicken Sie auf create-app auslösen.

3. Klicken Sie auf URL-VORSCHAU ANZEIGEN, um die URL aufzurufen, die zum Aufrufen des Webhooks erforderlich ist.

4. Rufen Sie in Cloud Shell den Trigger auf. Stellen Sie dazu eine curl-Anfrage für die URL aus dem vorherigen Schritt und übergeben Sie die Parameter als Nutzlast.

   curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'
   

   Im vorherigen Codebeispiel:

   • Ersetzen Sie WEBHOOK_URL durch die vom Trigger abgerufene URL.

   • "app": "sample" gibt den Namen der Anwendung an.

   • "runtime": "python" weist die Anwendungs-Factory an, die Python-Vorlage zum Erstellen von Anwendungs-Repositories zu verwenden.

   • "trigger_type": "webhook" gibt den Typ der CI/CD-Pipelines für die Anwendung an.

   • "github_team": "" ist ein Team in GitHub, das den Repositories zugeordnet wird, die für die Anwendung erstellt werden. Da Sie noch kein GitHub-Team erstellt haben, übergeben Sie es als leeren String.

5. Prüfen Sie die Pipeline auf den Trigger create-app:

   Zur Seite „Cloud Build-Verlauf“

   Es gibt eine neue Pipeline für den create-app-Trigger. Wenn dies abgeschlossen ist, wird die Anwendungsdefinition in application-factory-repo erstellt.

6. Sehen Sie sich die Datei zur Anwendungsdefinition an:

   1. Rufen Sie in einem Webbrowser GitHub auf und melden Sie sich in Ihrem Konto an.

   2. Klicken Sie auf das Bildsymbol und dann auf Your organizations. Wählen Sie Ihre Organisation aus.

   3. Klicken Sie auf das Repository application-factory-repo, wechseln Sie zum Ordner apps/python und öffnen Sie die neue Datei namens sample.tf, die vom Trigger create-app erstellt wurde. Prüfen Sie die Datei. Diese Datei enthält Terraform-Code zum Erstellen einer neuen Anwendung.

Erstellen Sie die Anwendungsinfrastruktur:

Nachdem Sie die Anwendungsdefinition erstellt haben, führen Sie den Trigger tf-apply aus, um die Anwendungsinfrastruktur zu erstellen.

1. Führen Sie in der Google Cloud Console folgende Schritte aus:

   Zur Cloud Build-Seite

   Klicken Sie auf tf-apply-Trigger.

2. Klicken Sie auf "URL-VORSCHAU ANZEIGEN", um die URL aufzurufen, die zum Aufrufen des Webhooks erforderlich ist.

3. Rufen Sie den Trigger auf:

   curl "WEBHOOK_URL" -d '{}'
   

   Im vorherigen Codebeispiel:

   • Ersetzen Sie WEBHOOK_URL durch die vom Trigger abgerufene URL.

4. Prüfen Sie die Pipeline auf den Trigger tf-apply:

   Zur Seite „Cloud Build-Verlauf“

   Es gibt eine neue Pipeline für den tf-apply-Trigger. Warten Sie, bis der Vorgang abgeschlossen ist.

Dieser Trigger erstellt die Anwendungsinfrastruktur.

Prüfen Sie die Anwendungsinfrastruktur:

Sehen Sie sich die verschiedenen Komponenten der Anwendungsinfrastruktur an.

Landing-Zone

1. Rufen Sie Cloud Shell auf und legen Sie das Projekt fest.

   gcloud config set core/project PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.

2. Rufen Sie Anmeldedaten für den GKE-Entwicklungscluster ab.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

3. Prüfen Sie den Namespace der Anwendung. Der Namespace ist nach der Anwendung benannt.

   kubectl get namespaces sample
   

   Die Ausgabe sollte so aussehen:

   NAME     STATUS   AGE
   sample   Active   15m
   

4. Prüfen Sie das Dienstkonto im Namespace.

   kubectl get serviceaccounts -n sample
   

   Zusätzlich zum Standardkonto ist ein Dienstkonto vorhanden. Die Ausgabe sollte so aussehen:

   NAME         SECRETS   AGE
   default      0         15m
   sample-ksa   0         15m
   

Infrastruktur-Repository

Rufen Sie in einem Webbrowser GitHub auf und melden Sie sich in Ihrem Konto an. Klicken Sie unten auf das Bildsymbol. Klicken Sie anschließend auf Your organizations. Wählen Sie Ihre Organisation aus und klicken Sie auf das Repository sample-infra.

Dieses Repository hat vier Zweige: cicd-trigger, dev, staging und prod. Es enthält auch die vier Ordner „cicd-trigger“, „dev“, „staging“ und „prod“. Der Standardzweig ist cicd-trigger. Sie können den Code per Push in diesen Zweig übertragen, während andere Zweige Schutzregeln haben. Sie können also den Code nicht direkt in diese Zweige übertragen. Um den Code in diese Zweige zu übertragen, müssen Sie eine Pull-Anfrage erstellen. Der Ordner cicd-trigger enthält Code zum Erstellen von CI/CD-Ressourcen für die Anwendung, während die Ordner dev, staging und prod Code zum Erstellen der Infrastruktur für verschiedene Umgebungen der Anwendung haben.

Infrastruktur-Trigger

• Führen Sie in der Google Cloud Console folgende Schritte aus:

  Zur Cloud Build-Seite

  Es gibt einen neuen Trigger mit dem Namen deploy-infra-sample.

• Dieser Trigger ist mit dem Repository sample-infra verbunden. Wenn ein Code-Push an dieses Repository erfolgt, wird der Trigger aufgerufen und identifiziert den Zweig, in dem der Push erfolgt ist, und geht in den entsprechenden Ordner in diesem Zweig und führt Terraform dort aus. Wenn der Code beispielsweise in den Zweig cicd-trigger übertragen wird, führt der Trigger Terraform im Ordner "cicd-trigger" des Zweigs "cicd-trigger" aus. Wenn ein Push an den dev-Zweig erfolgt, führt der Trigger entsprechend Terraform im Entwicklungsordner des Entwicklungszweigs aus usw.

Anwendungs-Repository

• Rufen Sie GitHub auf und rufen Sie die Repositories unter Ihrer Organisation ab. Es gibt ein neues Repository mit dem Namen sample. Dieses Repository hostet den Quellcode und die Schritte zum Erstellen von Containern in Dockerfile, kustomize-Konfigurationen, die die erforderlichen Konfigurationen der Anwendung beschreiben, und skaffold.yaml, die die Bereitstellungsschritte definieren, die von Cloud Deploy für CD verwendet werden sollen.

CI-/CD-Ressourcen für Anwendungen erstellen

Nachdem Sie nun das Basisschema der Anwendung erstellt haben, führen Sie den Trigger deploy-infra-sample aus, um die CI-/CD-Ressourcen zu erstellen. Sie können den Trigger entweder manuell mit der Webhook-URL aufrufen oder einen Commit an das Git-Repository sample-infra senden.

1. Fügen Sie eine neue Zeile in einer Datei im Repository hinzu, um den Cloud Build-Trigger aufzurufen. Übertragen Sie die Änderungen anschließend per Push:

   1. Wenn Sie Git noch nie über Cloud Shell verwendet haben, konfigurieren Sie Git mit Ihrem Namen und Ihrer E-Mail-Adresse. Git verwendet diese Informationen, um Sie als Ersteller der Commits zu identifizieren, die Sie in Cloud Shell erstellen:

      git config --global user.email "GITHUB_EMAIL_ADDRESS"
      git config --global user.name "GITHUB_USERNAME"
      

      Ersetzen Sie Folgendes:

      • GITHUB_EMAIL_ADDRESS: die mit Ihrem GitHub-Konto verknüpfte E-Mail-Adresse
      • GITHUB_USERNAME: der mit Ihrem GitHub-Konto verknüpfte Nutzername

   2. Klonen Sie das Git-Repository sample-infra:

      git clone https://github.com/GITHUB_ORG/sample-infra
      
      cd sample-infra
      

      Ersetzen Sie Folgendes:

      • GITHUB_ORG durch Ihre GitHub-Organisation.

      Der Standardzweig cicd-trigger ist ausgecheckt.

   3. Fügen Sie der Datei „env/cicd-trigger/main.tf“ eine neue Zeile hinzu, führen Sie die Änderung durch und übertragen Sie sie per Push.

        echo "" >> env/cicd-trigger/main.tf
      

   4. Übernehmen Sie die Änderungen per Commit und übertragen Sie sie per Push:

      git add .
      git commit -m "A dummy commit to invoke the infrastrucutre trigger"
      git push
      cd ..
      

      Sobald die Änderungen per Push übertragen wurden, wird der Cloud Deploy-Trigger deploy-infra-sample gestartet.

2. Überwachen Sie den Status des Triggers:

   Rufen Sie die Seite "Cloud Build-Verlauf" auf, um die Pipeline aufzurufen und warten Sie, bis sie abgeschlossen ist.

CICD-Ressourcen einer Anwendung prüfen

Sehen Sie sich die verschiedenen CI/CD-Ressourcen an, die für die Anwendung erstellt wurden.

1. In der Google Cloud Console:

   Rufen Sie die Cloud Build-Seite auf und sehen Sie sich den deploy-app-sample-Trigger an.

   Dies ist der CI-Pipeline-Trigger. Es ist mit dem Anwendungscode-Repository sample verbunden. Der Trigger wird aufgerufen, wenn ein Push-Vorgang an das Anwendungs-Repository gesendet wird, und führt die Build-Schritte aus, wie in der Triggerkonfiguration festgelegt. Klicken Sie auf den Triggernamen und dann auf EDITOR ÖFFNEN, um die Schritte aufzurufen, die der Trigger beim Aufrufen ausführt.

2. Rufen Sie die Seite Artifact Registry auf und sehen Sie sich das neue Repository mit dem Namen sample an.

   Dieses Artefakt-Repository speichert die Artefakte der Anwendung.

3. Rufen Sie die Cloud Deploy-Pipelineseite auf und sehen Sie sich die Pipeline mit dem Namen sample an. Dies ist die kontinuierliche Deployment-Pipeline, die die Anwendung in den GKE-Clustern bereitstellt.

Anwendung in der Entwicklungsumgebung bereitstellen

Der Trigger deploy-app-sample ist mit dem Anwendungs-Repository namens sample verbunden. Sie können den Trigger entweder manuell mit der Webhook-URL oder über einen Push an das Anwendungs-Repository aufrufen.

1. Fügen Sie in einer Datei im Repository sample eine neue Zeile hinzu und übertragen Sie die Änderungen per Push, um den Cloud Build-Trigger aufzurufen:

   1. Klonen Sie das Git-Repository sample:

      In Cloud Shell:

      git clone https://github.com/GITHUB_ORG/sample
      
      cd sample
      

      Ersetzen Sie GITHUB_ORG durch Ihre GitHub-Organisation.

   2. Fügen Sie der Datei skaffold.yaml eine neue Zeile hinzu.

        echo "" >> skaffold.yaml
      

   3. Übernehmen Sie die Änderungen per Commit und übertragen Sie sie per Push:

      git add .
      git commit -m "A dummy commit to invoke CI/CD trigger"
      git push
      

   4. Sobald die Änderungen per Push übertragen wurden, wird der Cloud Deploy-Trigger deploy-app-sample gestartet.

2. Überwachen Sie den Status des Triggers:

   Rufen Sie die Seite "Cloud Build-Verlauf" auf, um die Pipeline aufzurufen und warten Sie, bis sie abgeschlossen ist.

   Der Trigger führt die in der Konfiguration definierten Schritte aus. Im ersten Schritt erstellen Sie ein Docker-Image aus dem Anwendungscode im Repository sample. Im letzten Schritt wird die Cloud Deploy-Pipeline gestartet, die die Anwendung im GKE-Dev-Cluster bereitstellt.

3. Prüfen Sie das Deployment im Entwicklungscluster:

   Zur Seite "Cloud Deploy-Pipeline"

   Klicken Sie auf die Pipeline sample. Das Deployment im Entwicklungs-GKE-Cluster wurde gestartet. Warten Sie, bis der Vorgang abgeschlossen ist.

Prüfen Sie, ob die Anwendung erfolgreich bereitgestellt wurde:

1. Rufen Sie Anmeldedaten für den Entwicklungscluster ab.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. Tunnel zum GKE-Cluster.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
   

3. Klicken Sie in der Symbolleiste von Cloud Shell auf

   Webvorschau und klicken Sie anschließend auf Vorschau auf Port 8080:

   Die Ausgabe sieht so aus:

   Hello World!
   

4. Drücken Sie in Cloud Shell CTRL+C, um die Portweiterleitung zu beenden.

Neue Funktion zur Anwendung hinzufügen

Wenn Sie eine neue Funktion entwickeln, müssen Sie Ihre Änderungen schnell in einer Entwicklungsumgebung bereitstellen, um sie zu testen und zu iterieren. In dieser Anleitung verwenden Sie Änderungen im Anwendungscode-Repository und stellen sie in der Entwicklungsumgebung bereit.

1. Wechseln Sie in Cloud Shell zum bereits geklonten sample-Repository:

2. Aktualisieren Sie die Anwendung, sodass eine andere Nachricht ausgegeben wird:

     sed -i "s/Hello World/My new feature/g" main.py
   

3. Übernehmen Sie die Änderungen per Commit und übertragen Sie sie per Push:

   git add .
   git commit -m "Changed the message"
   git push
   

   Sobald der Code an das GitHub-Repository übertragen wurde, wird der Webhook-Trigger deploy-app-sample gestartet.

4. Überwachen Sie den Status des Triggers auf der Seite "Cloud Build-Verlauf" und warten Sie, bis der Vorgang abgeschlossen ist.

5. Zur Seite "Cloud Deploy-Pipeline"

   Klicken Sie auf die Pipeline sample. Das Deployment im Entwicklungs-GKE-Cluster wurde gestartet. Warten Sie, bis der Vorgang abgeschlossen ist.

Prüfen Sie, ob die Anwendung erfolgreich bereitgestellt wurde:

1. Rufen Sie Anmeldedaten für den Entwicklungscluster ab, wenn Sie eine neue Cloud Shell öffnen:

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. Tunnel zum GKE-Cluster:

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
   

3. Klicken Sie in der Symbolleiste von Cloud Shell auf

   Webvorschau und klicken Sie anschließend auf Vorschau auf Port 8080:

   

   Die Ausgabe sieht so aus:

   My new feature!
   

4. Drücken Sie in Cloud Shell CTRL+C, um die Portweiterleitung zu beenden.

Änderung an Staging- und Produktionsclustern übertragen

Bevor Sie die Anwendung in die Staging- und Produktionsumgebung hochstufen, müssen Sie die Landing-Zone für die Anwendung in den GKE-Clustern für diese Umgebungen erstellen. Beim Onboarding der Anwendung wurde die Landing-Zone für die Entwicklung automatisch im GKE-Cluster erstellt, indem der Code im Entwicklungszweig acm-gke-infrastructure-repo hinzugefügt wurde.

Landing-Zone in Staging- und Produktions-GKE-Clustern erstellen

1. Erstellen Sie die Landing-Zone im Staging-GKE-Cluster: Sie müssen eine Pull-Anfrage vom Entwicklungs- zum Staging-Zweig in acm-gke-infrastructure-repo erstellen und zusammenführen.

   1. Rufen Sie GitHub auf und wechseln Sie zum Repository acm-gke-infrastructure-repo. Klicken Sie auf Pull requests und dann auf New pull request. Wählen Sie im Menü Basis die Option Staging und im Menü Vergleichen die Option Entwicklung aus. Klicken Sie auf Create pull request.

   2. In der Regel prüft jemand, der Zugriff auf das Repository hat, die Änderungen und führt dann die Pull-Anfrage zusammen, um sicherzustellen, dass nur die gewünschten Änderungen in die Staging-Umgebung übernommen werden. Damit die Nutzer die Referenzarchitektur ausprobieren können, wurden die Regeln für den Zweigschutz gelockert, damit der Repository-Administrator die Prüfung umgehen und die Pull-Anfrage zusammenführen kann. Wenn Sie ein Administrator für das Repository sind, führen Sie die Pull-Anfrage zusammen. Andernfalls bitten Sie den Administrator, sie zusammenzuführen.

   Config Sync synchronisiert die Änderungen, die im Staging-Zweig des Repositorys acm-gke-infrastructure-repo eingehen, mit dem Staging-GKE-Cluster, der zur Erstellung der Landing-Zone für die Anwendung im Staging-GKE-Cluster führt.

2. Landing-Zone in GKE-Produktionsclustern erstellen: Sie müssen eine Pull-Anfrage vom Staging zum Produktionszweig erstellen und zusammenführen.

   1. Klicken Sie auf Pull requests und dann auf New pull request. Wählen Sie im Menü Basis die Option Produktion und im Menü Vergleichen die Option Staging aus. Klicken Sie auf die Schaltfläche Create pull request.

   2. Wenn Sie ein Administrator für das Repository sind, führen Sie die Pull-Anfrage zusammen. Andernfalls bitten Sie den Administrator, sie zusammenzuführen.

   Config Sync synchronisiert die Änderungen, die im Produktionszweig des Repositorys acm-gke-infrastructure-repo ankommen, mit den GKE-Produktionsclustern, die zur Erstellung einer Landing-Zone für die Anwendung in GKE-Produktionsclustern führen.

Änderungen von Entwicklungsphase zu Staging hochstufen

Nachdem Sie die Landing Zone für die Anwendung in Staging- und Produktions-GKE-Clustern erstellt haben, stufen Sie die Anwendung von der Entwicklungs- zur Staging-Umgebung hoch.

1. Suchen Sie den neuesten Releasenamen und speichern Sie ihn als Umgebungsvariable:

     export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')
    

   Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.

   Prüfen Sie, ob die Umgebungsvariable festgelegt wurde:

     echo $RELEASE
     

2. Führen Sie in Cloud Shell den folgenden Befehl aus, um das Hochstufen von dem Release von der Entwicklung zur Staging-Umgebung auszulösen:

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=staging --quiet
    

3. Prüfen Sie das Staging-Deployment:

   Zur Seite "Cloud Deploy-Pipeline"

   Klicken Sie auf die Pipeline sample, die Bereitstellung im Staging-GKE-Cluster wurde gestartet. Warten Sie, bis der Vorgang abgeschlossen ist.

4. Prüfen Sie, ob die Staging-Bereitstellung erfolgreich abgeschlossen wurde:

   1. Rufen Sie Anmeldedaten für den Staging-Cluster ab:

      gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a
      

   2. Tunnel zum GKE-Cluster:

      gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
      

   3. Klicken Sie in der Symbolleiste von Cloud Shell auf

      Webvorschau und klicken Sie anschließend auf Vorschau auf Port 8080:

      

      Die Ausgabe sieht so aus:

      My new feature!
      

   4. Drücken Sie in Cloud Shell CTRL+C, um die Portweiterleitung zu beenden.

Änderungen vom Staging zur Produktion hochstufen

Stufen Sie jetzt den Release vom Staging zur Produktion hoch. Sie haben zwei Produktionscluster und Cloud Deploy hat für jeden Cluster ein Ziel mit den Namen prod1 bzw. prod2.

1. Führen Sie in Cloud Shell den folgenden Befehl aus, um das Hochstufen vom Staging zum Cluster prod1 auszulösen:

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod1 --quiet
    

2. Die Freigabe für Produktionscluster erfordert eine Genehmigung, damit das Rollout wartet, bis Sie es genehmigen. So rufen Sie sie auf:

   Zur Seite "Cloud Deploy-Pipeline"

   Klicken Sie auf Pipeline sample. Für den Roll-out von "prod1" ist eine Genehmigung erforderlich, während die Rolle "clouddeploy.approver" erforderlich ist, um das Roll-out zu genehmigen. Da Sie der Inhaber des Projekts sind, haben Sie die Berechtigung, die Freigabe zu genehmigen.

3. Genehmigen Sie die Freigabe für prod1:

   Führen Sie den folgenden Befehl aus, um den Namen des ausstehenden Roll-outs abzurufen und ihn in einer Umgebungsvariablen zu speichern:

    export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
    

   Genehmigen Sie die Freigabe:

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

4. Nachdem die Genehmigung erteilt wurde, startet prod1. Überwachen Sie den Fortschritt auf der Seite Cloud Deploy-Pipeline.

5. Starten Sie nach Abschluss der prod1-Bereitstellung die Prod2-Freigabe.

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod2 --quiet
    

6. Für die Freigabe auf prod2 ist ebenfalls eine Genehmigung erforderlich. Genehmigen Sie die Freigabe für den prod2-Cluster:

   Führen Sie den folgenden Befehl aus, um den Namen des ausstehenden Roll-outs abzurufen und ihn in einer Umgebungsvariablen zu speichern:

    export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
    

   Genehmigen Sie die Freigabe:

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

   Hinweis: Mit Cloud Deploy können Sie parallele Bereitstellungen in mehreren GKE-Clustern ausführen, sodass Sie gleichzeitig in mehreren Produktionsclustern bereitstellen können. Weitere Informationen finden Sie unter Parallele Bereitstellung mit Cloud Deploy.

7. Nachdem die Genehmigung erteilt wurde, startet die Prod2-Freigabe. Überwachen Sie den Fortschritt auf der Seite Cloud Deploy-Pipeline.

8. Prüfen Sie, ob die Bereitstellung im Produktionscluster erfolgreich war, nachdem die Cloud Deploy-Pipelines in prod1 und prod2 abgeschlossen sind.

   1. In Produktionsclustern wird Multi-Cluster-Ingress erstellt. Mit einem Load Balancer können Sie auf die Produktionsanwendung zugreifen. Diese Multi-Cluster-Ingress-Konfigurationen werden mit den YAML-Dateien k8s/prod/mci.yaml und k8s/prod/mcs.yaml im Repository sample erstellt. Wenn Sie eine Anfrage an die IP-Adresse des Load Balancers senden, leitet Multi-Cluster-Ingress die Anfrage an eine der beiden Instanzen der Anwendung weiter, die in zwei verschiedenen GKE-Clustern ausgeführt werden.

   2. Listen Sie die Weiterleitungsregel auf, die dem Load Balancer zugeordnet ist, um die IP-Adresse zu ermitteln.

      gcloud compute forwarding-rules list
      

   3. Die Ausgabe sollte so aussehen:

      NAME: mci-qqxs9x-fw-sample-sample-ingress
      REGION:
      IP_ADDRESS: 34.36.123.118
      IP_PROTOCOL: TCP
      TARGET: mci-qqxs9x-sample-sample-ingress
      

   4. Öffnen Sie einen Webbrowser und geben Sie Folgendes in die URL ein:

      http://IP_ADDRESS:80
      

      Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Load Balancers.

      Die Ausgabe sieht so aus:

      My new feature!
      

      So wird bestätigt, dass die Anwendung wie erwartet in Produktionsclustern bereitgestellt wird.

Ausfallsicherheit der Anwendung testen

In diesem Abschnitt testen Sie die Ausfallsicherheit der in der Produktion ausgeführten Anwendung. Dazu starten Sie einen der beiden Knoten der GKE-Produktionscluster neu, ohne die Anwendung zu beeinträchtigen.

Die Anwendung in der Produktion verwendet Multi-Cluster-Ingress und ist über eine Load Balancer-IP zugänglich. Wenn über diese IP auf die Anwendung zugegriffen wird, leitet Multi-Cluster-Ingress sie an eine der beiden Instanzen der Anwendung weiter, die auf zwei verschiedenen GKE-Clustern ausgeführt wird. Wenn einer der GKE-Cluster fehlerhaft ist und die darauf ausgeführte Anwendungsinstanz nicht erreicht werden kann, sendet der Multi-Cluster-Ingress weiterhin Traffic an die fehlerfreie Instanz der Anwendung, die im anderen GKE-Cluster ausgeführt wird. Dadurch wird der Clusterausfall für den Endnutzer unsichtbar und die Anwendung verarbeitet kontinuierlich die Anfragen.

So testen Sie die Ausfallsicherheit:

1. Suchen Sie den Knotenpool der GKE-Produktionscluster, die in us-west1 ausgeführt werden.

    gcloud container clusters describe gke-prod-us-west1 --zone=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' |  awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print  ""}'
   

2. Die Ausgabe sollte so aussehen:

   us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp
   us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp
   

   Die Ausgabe hat zwei Spalten: Die erste Spalte ist die Zone und die zweite Spalte der Name der Instanzgruppe, die dem Knotenpool des GKE-Produktionsclusters in der Region „us-west1“ zugeordnet ist.

3. Starten Sie die Instanzgruppe entsprechend den Knotenpools neu:

    gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1  --zone=ZONE_1 --max-unavailable=100%
   
    gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2  --zone=ZONE_2 --max-unavailable=100%
   

   Ersetzen Sie INSTANCE_GROUP_1 durch den Namen der ersten Instanzgruppe.

   Ersetzen Sie ZONE_1 durch die Zone der ersten Instanzgruppe.

   Ersetzen Sie INSTANCE_GROUP_2 durch den Namen der zweiten Instanzgruppe.

   Ersetzen Sie ZONE_2 durch die Zone der zweiten Instanzgruppe.

4. Prüfen Sie den Status der Instanzgruppe.

   Zur Seite "Instanzgruppen"

   Die beiden Instanzgruppen werden neu gestartet, während die anderen Gruppen ein grünes Häkchen haben.

   

5. Öffnen Sie einen Webbrowser und geben Sie Folgendes in die URL ein:

   http://IP_ADDRESS:80
   

   Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Load Balancers.

   Auch wenn einer der beiden GKE-Cluster ausgefallen ist, ist die Anwendung verfügbar und die Ausgabe sieht so aus:

    My new feature!
    

   Dies zeigt, dass Ihre Anwendung stabil und hochverfügbar ist.

Anwendung verwalten

Wenn Sie diese Anwendung aus der Application Factory erstellt haben, erhalten Sie separate Git-Repositories, Infrastrukturen und CI/CD-Pipelines für die Anwendung. Sie haben diese Ressourcen verwendet, um die Anwendung bereitzustellen und ein neues Feature hinzuzufügen. Um die Anwendung weiter zu verwalten, müssen Sie nur mit diesen Git-Repositories und der Pipeline interagieren, ohne die Anwendungs-Factory aktualisieren zu müssen. Sie können die Pipelines und Git-Repositories der Anwendung an Ihre Anforderungen anpassen. Als Anwendungsinhaber können Sie festlegen, wer Zugriff auf die Pipelines und Git-Repositories Ihrer Anwendung erhält, um sie zu verwalten.

Bereinigen

Führen Sie eine Bereinigung durch, um zu vermeiden, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen 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.
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.

Nächste Schritte

• Best Practices zum Einrichten der Identity-Föderation
• Weitere Informationen zu Kubernetes und den Herausforderungen der kontinuierlichen Softwarebereitstellung
• Hybrid- und Multi-Cloud-Monitoring sowie -Logging-Muster
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center