Continuous Delivery gemäß GitOps mit Cloud Build

---

Auf dieser Seite wird erläutert, wie Sie eine Continuous Integration- und Continuous Delivery-Pipeline (CI/CD) in Google Cloud erstellen, die nur gehostete Produkte und die beliebte GitOps-Methode verwendet.

Unsere Entwickler speichern schon seit Langem Konfigurations- und Implementierungsdateien in unserem primären Quellcode-Repository. Diese Methode wird im Buch Site Reliability Engineering, Kapitel 8 (Beyer et. al., 2016) beschrieben. Kelsey Hightower hat sie in seinem Vortrag auf der Google Cloud Next '17 erörtert.

Ein wesentlicher Bestandteil von GitOps ist das Konzept "Environments-As-Code" (Umgebungen als Code). Dabei geht es darum, dass Sie Deployments mithilfe von Dateien (z. B. Kubernetes-Manifesten), die in einem Git-Repository gespeichert sind, deklarativ beschreiben.

Im Rahmen dieser Anleitung erstellen Sie eine CI/CD-Pipeline, die automatisch ein Container-Image aus gespeichertem Code erstellt, das Image in Artifact Registry speichert, ein Kubernetes-Manifest in einem Git-Repository aktualisiert und die Anwendung mithilfe dieses Manifests in Google Kubernetes Engine (GKE) bereitstellt.

In dieser Anleitung werden zwei Git-Repositories verwendet:

• app-Repository: enthält den Quellcode der Anwendung
• env-Repository: enthält die Manifeste für das Kubernetes-Deployment

Wenn Sie eine Änderung am app-Repository per Push zustellen, führt die Cloud Build-Pipeline Tests aus, erstellt ein Container-Image und überträgt dieses per Push in Artifact Registry. Nachdem das Image per Push übertragen wurde, aktualisiert Cloud Build das Deployment-Manifest und überträgt es per Push in das env-Repository. Dies löst eine weitere Cloud Build-Pipeline aus, die das Manifest auf den GKE-Cluster anwendet und es bei Erfolg in einem anderen Branch des env-Repositorys speichert.

Wir halten die Repositories app und env getrennt, da sich ihre Lebenszyklen und Verwendungszwecke unterscheiden. Das app-Repository wird primär von Menschen genutzt und ist für eine bestimmte Anwendung vorgesehen. Das env-Repository wird dagegen hauptsächlich von automatisierten Systemen (z. B. Cloud Build) genutzt. Dieses Repository kann von mehreren Anwendungen gemeinsam verwendet werden. Das env-Repository kann mehrere Branches haben, die jeweils einer bestimmten Umgebung zugeordnet sind und auf ein bestimmtes Container-Image verweisen, das app-Repository jedoch nicht. Sie verwenden in dieser Anleitung allerdings nur die Produktionsumgebung.

Nach Abschluss dieser Anleitung haben Sie ein System, mit dem Sie Folgendes tun können:

• Fehlgeschlagene und erfolgreiche Deployments durch einen Blick in den Cloud Build-Verlauf voneinander unterscheiden
• Über den production-Branch des env-Repositorys auf das derzeit verwendete Manifest zugreifen
• Ein Rollback zu einer vorherigen Version durch erneutes Ausführen des jeweiligen Cloud Build-Builds durchführen

Informationen zu dieser Anleitung

In dieser Anleitung wird Cloud Source Repositories zum Hosten von Git-Repositories verwendet. Mit anderen Drittanbieterprodukten wie GitHub, Bitbucket oder GitLab können Sie jedoch dieselben Ergebnisse erzielen.

Diese Pipeline erstellt vor dem Errichten des Deployments kein Validierungsverfahren. Wenn Sie GitHub, Bitbucket oder GitLab verwenden, können Sie die Pipeline so ändern, dass sie zu diesem Zweck eine Pull-Anfrage verwendet.

Solchen Teams, die erweiterte Deployment-Muster erstellen möchten (Blau/Grün-Deployments, Canary-Analyse, Multi-Cloud usw.), empfehlen wir zwar Spinnaker, jedoch ist dessen Feature-Set für eine erfolgreiche CI/CD-Strategie für kleinere Organisationen und Projekte möglicherweise nicht erforderlich. In dieser Anleitung erfahren Sie, wie Sie eine CI/CD-Pipeline für Anwendungen erstellen, die in GKE mit Tools gehostet werden.

Der Einfachheit halber wird in dieser Anleitung nur die Produktionsumgebung im env-Repository verwendet. Sie können es jedoch bei Bedarf einrichten, dass das Deployment in mehreren Umgebungen erstellt wird.

Ziele

• Git-Repositories in Cloud Source Repositories erstellen
• Mit Cloud Build ein Container-Image erstellen und in Artifact Registry speichern
• CI-Pipeline erstellen
• CD-Pipeline erstellen
• CI/CD-Pipeline testen

Kosten

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

• GKE
• Cloud Source Repositories
• Artifact Registry
• Cloud Build

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.

Vorbereitung

1. Wählen Sie ein Google Cloud-Projekt aus oder erstellen Sie eines.

   Zur Seite „Ressourcen verwalten“

2. Aktivieren Sie die Abrechnung für Ihr Projekt.

   Abrechnung aktivieren

3. Öffnen Sie Cloud Shell, um die in dieser Anleitung aufgeführten Befehle auszuführen. Cloud Shell ist eine interaktive Shell-Umgebung für Google Cloud, mit der Sie Projekte und Ressourcen über Ihren Webbrowser verwalten können.

   Zu Cloud Shell

4. Wenn der Befehl gcloud config get-value project nicht die ID des ausgewählten Projekts zurückgibt, konfigurieren Sie Cloud Shell so, dass Ihr Projekt verwendet wird.

   gcloud config set project [PROJECT_ID]
   

5. Aktivieren Sie in Cloud Shell die erforderlichen APIs.

   gcloud services enable container.googleapis.com \
       cloudbuild.googleapis.com \
       sourcerepo.googleapis.com \
       artifactregistry.googleapis.com
   

6. Erstellen Sie ein Artifact Registry-Docker-Repository mit dem Namen my-repository in der Region us-central1, um Ihre Container-Images zu speichern.

   gcloud artifacts repositories create my-repository \
     --repository-format=docker \
     --location=us-central1
   

7. Erstellen Sie in Cloud Shell einen GKE-Cluster, den Sie zum Erstellen der Beispielanwendung aus dieser Anleitung verwenden.

   Autopilot

   Erstellen Sie einen Autopilot-Cluster mit dem Namen hello-cloudbuild:

   gcloud container clusters create-auto hello-cloudbuild \
       --region us-central1
   

   Standard

   Erstellen Sie einen Standardcluster mit einem Knoten mit dem Namen hello-cloudbuild:

   gcloud container clusters create hello-cloudbuild \
       --num-nodes 1 --region us-central1
   

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

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie im Abschnitt Bereinigen.

Git-Repositories in Cloud Source Repositories erstellen

In diesem Abschnitt erstellen Sie die beiden Git-Repositories (app und env), die in dieser Anleitung verwendet werden, und initialisieren das app-Repository mithilfe von Beispielcode.

1. Erstellen Sie in Cloud Shell die beiden Git-Repositories.

   gcloud source repos create hello-cloudbuild-app
   gcloud source repos create hello-cloudbuild-env
   

2. Klonen Sie den Beispielcode aus GitHub.

   cd ~
   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   

3. Konfigurieren Sie Cloud Source Repositories als Remote-Repository.

   PROJECT_ID=$(gcloud config get-value project)
   git remote add google \
       "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"
   

Der geklonte Code enthält eine „Hello World“-Anwendung.

from flask import Flask
app = Flask('hello-cloudbuild')

@app.route('/')
def hello():
  return "Hello World!\n"

if __name__ == '__main__':
  app.run(host = '0.0.0.0', port = 8080)

Container-Image mit Cloud Build erstellen

Der geklonte Code enthält folgendes Dockerfile.

FROM python:3.7-slim
RUN pip install flask
WORKDIR /app
COPY app.py /app/app.py
ENTRYPOINT ["python"]
CMD ["/app/app.py"]

Mit diesem Dockerfile können Sie mit Cloud Build ein Container-Image erstellen und dieses in Artifact Registry speichern.

1. Erstellen Sie in Cloud Shell mit dem folgenden Befehl auf Grundlage des neuesten Commits einen Cloud Build-Build.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   COMMIT_ID="$(git rev-parse --short=7 HEAD)"
   gcloud builds submit --tag="us-central1-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .
   

   Wenn Sie diesen Befehl ausführen, streamt Cloud Build die durch die Erstellung des Container-Images generierten Logs an Ihr Terminal.

2. Stellen Sie nach Fertigstellen des Builds sicher, dass das neue Container-Image in Artifact Registry verfügbar ist.

   Zu Artifact Registry

   

Continuous Integration-Pipeline erstellen

In diesem Abschnitt konfigurieren Sie Cloud Build so, dass automatisch ein kleiner Einheitentest ausgeführt wird sowie das Container-Image erstellt und anschließend mithilfe von Push in Artifact Registry übertragen wird. Durch das Übertragen eines neuen Commits an Cloud Source Repositories wird diese Pipeline automatisch ausgelöst. Die bereits im Code enthaltene Datei cloudbuild.yaml enthält die Konfiguration der Pipeline.

steps:
# This step runs the unit tests on the app
- name: 'python:3.12-slim'
  id: Test
  entrypoint: /bin/sh
  args:
  - -c
  - 'pip install flask && python test_app.py -v'

# This step builds the container image.
- name: 'gcr.io/cloud-builders/docker'
  id: Build
  args:
  - 'build'
  - '-t'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'
  - '.'

# This step pushes the image to Artifact Registry
# The PROJECT_ID and SHORT_SHA variables are automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/docker'
  id: Push
  args:
  - 'push'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'

1. Öffnen Sie in Cloud Build die Seite Trigger.

   Zur Seite "Trigger"

2. Klicken Sie auf Trigger erstellen.

3. Füllen Sie die folgenden Optionen aus:

   • Geben Sie im Feld Name den Wert hello-cloudbuild ein.
   • Wählen Sie unter Ereignis die Option Push zu Zweig aus.
   • Wählen Sie unter Quelle hello-cloudbuild-app als Repository und ^master$ als Zweig aus.
   • Wählen Sie unter Build-Konfiguration die Option Cloud Build-Konfigurationsdatei aus.
   • Geben Sie im Feld Speicherort der Cloud Build-Konfigurationsdatei cloudbuild.yaml nach / ein.

4. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

   Tipp: Wenn Sie Build-Trigger für viele Projekte erstellen müssen, können Sie die Build Triggers API verwenden.

5. Übertragen Sie in Cloud Shell den Anwendungscode per Push in Cloud Source Repositories, um die CI-Pipeline in Cloud Build auszulösen.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git push google master
   

6. Öffnen Sie die Cloud Build-Konsole.

   Zu Cloud Build

   Die zuletzt ausgeführten und fertigen Builds werden angezeigt. Sie können auf den Build klicken, um dessen Ausführung zu verfolgen und die Logs zu überprüfen.

Continuous Delivery-Pipeline erstellen

Cloud Build wird auch für die Continuous Delivery (CD)-Pipeline verwendet. Die Pipeline wird jedes Mal ausgeführt, wenn ein Commit per Push an den Branch candidate des Repositorys hello-cloudbuild-env gesendet wird. Die Pipeline wendet die neue Version des Manifests auf den Kubernetes-Cluster an und kopiert das Manifest bei Erfolg in den Branch production. Für diesen Prozess gilt Folgendes:

• Im Branch candidate werden die Erstellungsversuche in Verlaufsform angezeigt.
• Im Branch production werden die erfolgreichen Deployments in Verlaufsform angezeigt.
• Sie können die Anzahl erfolgreicher und fehlgeschlagener Deployments in Cloud Build einsehen.
• Sie können ein Rollback zu einem beliebigen vorherigen Deployment vornehmen, indem Sie den entsprechenden Build in Cloud Build noch einmal ausführen. Durch ein Rollback wird auch der Branch production aktualisiert, um den Verlauf der Deployments korrekt widerzuspiegeln.

Sie werden im Folgenden die CI-Pipeline verändern, sodass der Branch candidate des Repositorys hello-cloudbuild-env aktualisiert wird, wodurch dann die CD-Pipeline ausgelöst wird.

Hinweis: Sie können das in dieser Anleitung beschriebene System zum Verwalten mehrerer Umgebungen erweitern. Der einfachste Weg dafür besteht darin, für jede Umgebung env zwei Branches zu haben: einen Kandidaten-env-Branch und einen env-Branch.

Cloud Build Zugriff auf GKE gewähren

Damit die Anwendung im Kubernetes-Cluster bereitgestellt werden kann, benötigt Cloud Build die IAM-Rolle (Identity and Access Management) „Kubernetes Engine-Entwickler“.

Shell

Führen Sie in Cloud Shell den folgenden Befehl aus:

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')"
gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

Console

1. Öffnen Sie in der Google Cloud Console die Seite Cloud Build-Einstellungen:

   Cloud Build-Einstellungen öffnen

   Die Seite Dienstkontoberechtigungen wird angezeigt:

   

2. Legen Sie den Status der Rolle Kubernetes Engine Developer (Kubernetes Engine-Entwickler) auf Enable (Aktivieren) fest.

Repository hello-cloudbuild-env initialisieren

Sie müssen das Repository hello-cloudbuild-env mit zwei Branches (production und candidate) und einer Cloud Build-Konfigurationsdatei initialisieren, in welcher der Deployment-Prozess beschrieben ist.

1. Klonen Sie in Cloud Shell das Repository hello-cloudbuild-env und erstellen Sie den Branch production.

   cd ~
   gcloud source repos clone hello-cloudbuild-env
   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git checkout -b production
   

2. Kopieren Sie die Datei cloudbuild-delivery.yaml aus dem Repository hello-cloudbuild-app in das gerade erstellte Repository und übernehmen Sie die Änderung.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/kubernetes-engine-samples/management/gitops-style-delivery/cloudbuild.yaml
   git add .
   git commit -m "Create cloudbuild.yaml for deployment"
   

   In der Datei cloudbuild-delivery.yaml ist der Deployment-Prozess beschrieben, der in Cloud Build ausgeführt werden soll. Er besteht aus zwei Schritten:

   1. Cloud Build wendet das Manifest auf den GKE-Cluster an.

   2. Bei Erfolg kopiert Cloud Build das Manifest in den Branch production.

   steps:
   # This step deploys the new version of our container image
   # in the hello-cloudbuild Kubernetes Engine cluster.
   - name: 'gcr.io/cloud-builders/kubectl'
     id: Deploy
     args:
     - 'apply'
     - '-f'
     - 'kubernetes.yaml'
     env:
     - 'CLOUDSDK_COMPUTE_REGION=us-central1'
     - 'CLOUDSDK_CONTAINER_CLUSTER=hello-cloudbuild'
   
   # This step copies the applied manifest to the production branch
   # The COMMIT_SHA variable is automatically
   # replaced by Cloud Build.
   - name: 'gcr.io/cloud-builders/git'
     id: Copy to production branch
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       set -x && \
       # Configure Git to create commits with Cloud Build's service account
       git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') && \
       # Switch to the production branch and copy the kubernetes.yaml file from the candidate branch
       git fetch origin production && git checkout production && \
       git checkout $COMMIT_SHA kubernetes.yaml && \
       # Commit the kubernetes.yaml file with a descriptive commit message
       git commit -m "Manifest from commit $COMMIT_SHA
       $(git log --format=%B -n 1 $COMMIT_SHA)" && \
       # Push the changes back to Cloud Source Repository
       git push origin production

3. Erstellen Sie einen Branch namens candidate und übertragen Sie beide Branches per Push in Cloud Source Repositories, damit sie dort verfügbar sind.

   git checkout -b candidate
   git push origin production
   git push origin candidate
   

4. Weisen Sie dem Cloud Build-Dienstkonto die IAM-Rolle "Quell-Repository-Schreiber" für das Repository hello-cloudbuild-env zu.

   PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
       --format='get(projectNumber)')"
   cat >/tmp/hello-cloudbuild-env-policy.yaml <<EOF
   bindings:
   - members:
     - serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com
     role: roles/source.writer
   EOF
   gcloud source repos set-iam-policy \
       hello-cloudbuild-env /tmp/hello-cloudbuild-env-policy.yaml
   

Trigger für die CD-Pipeline erstellen

In diesem Abschnitt konfigurieren Sie Cloud Build so, dass dessen CD-Pipeline durch einen Push zum Branch candidate des Repositorys hello-cloudbuild-env ausgelöst wird.

1. Öffnen Sie die Seite Build-Trigger von Cloud Build.

   Zur Seite "Trigger"

2. Klicken Sie auf Trigger erstellen.

3. Füllen Sie die folgenden Optionen aus:

   • Geben Sie im Feld Name den Wert hello-cloudbuild-deploy ein.
   • Wählen Sie unter Ereignis die Option Push zu Zweig aus.
   • Wählen Sie unter Quelle hello-cloudbuild-env als Repository und ^candidate$ als Zweig aus.
   • Unter Konfiguration wählen Sie die Konfigurationsdatei (yaml oder json) von Cloud Build.
   • Geben Sie im Feld Speicherort der Cloud Build-Konfigurationsdatei cloudbuild.yaml nach / ein.

4. Klicken Sie auf Erstellen.

CI-Pipeline ändern, damit die CD-Pipeline ausgelöst wird

In diesem Abschnitt fügen Sie der CI-Pipeline einige Schritte hinzu, damit eine neue Version des Kubernetes-Manifests erzeugt wird, und übertragen dieses per Push in das Repository hello-cloudbuild-env, damit die CD-Pipeline ausgelöst wird.

1. Ersetzen Sie die Datei cloudbuild.yaml durch das erweiterte Beispiel in der Datei cloudbuild-trigger-cd.yaml.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   cp cloudbuild-trigger-cd.yaml cloudbuild.yaml
   

   Die Datei cloudbuild-trigger-cd.yaml ist eine erweiterte Version der Datei cloudbuild.yaml. Sie fügt Schritte hinzu, um das neue Kubernetes-Manifest zu generieren und die CD-Pipeline auszulösen.

   Hinweis: Diese Pipeline verwendet zum Rendern der Manifestvorlage ein sed-Skript. In der Praxis bietet es sich an, dafür ein spezielles Tool wie kustomize oder skaffold zu verwenden. Mit diesen Tools haben Sie mehr Kontrolle über das Rendern der Manifestvorlagen.
   # This step clones the hello-cloudbuild-env repository
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Clone env repository
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       gcloud source repos clone hello-cloudbuild-env && \
       cd hello-cloudbuild-env && \
       git checkout candidate && \
       git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)')
   
   # This step generates the new manifest
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Generate manifest
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
        sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" kubernetes.yaml.tpl | \
        sed "s/COMMIT_SHA/${SHORT_SHA}/g" > hello-cloudbuild-env/kubernetes.yaml
   
   # This step pushes the manifest back to hello-cloudbuild-env
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Push manifest
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       set -x && \
       cd hello-cloudbuild-env && \
       git add kubernetes.yaml && \
       git commit -m "Deploying image us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:${SHORT_SHA}
       Built from commit ${COMMIT_SHA} of repository hello-cloudbuild-app
       Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
       git push origin candidate
   

2. Übernehmen Sie die Änderungen und übertragen Sie diese per Push in Cloud Source Repositories.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git add cloudbuild.yaml
   git commit -m "Trigger CD pipeline"
   git push google master
   

   Dadurch wird die CI-Pipeline in Cloud Build ausgelöst.

3. Sehen Sie sich den CI-Build an.

   Zu Cloud Build

   Die zuletzt ausgeführten und abgeschlossenen Builds für das Repository hello-cloudbuild-app werden angezeigt. Sie können auf den Build klicken, um dessen Ausführung zu verfolgen und die Logs zu überprüfen. Im letzten Schritt dieser Pipeline wird das neue Manifest per Push in das Repository hello-cloudbuild-env übertragen, wodurch die CD-Pipeline ausgelöst wird.

4. Sehen Sie sich den CD-Build an.

   Zu Cloud Build

   Die zuletzt ausgeführten und abgeschlossenen Builds für das Repository hello-cloudbuild-env werden angezeigt. Sie können auf den Build klicken, um dessen Ausführung zu verfolgen und die Logs zu überprüfen.

Gesamte Pipeline testen

Die gesamte CI/CD-Pipeline ist jetzt konfiguriert. In diesem Abschnitt führen Sie einen End-to-End-Test der Pipeline durch.

1. Wechseln Sie zur Seite der Google Kubernetes Engine-Dienste.

   Zu den Google Kubernetes Engine-Diensten

   Die Liste enthält einen einzelnen Dienst namens hello-cloudbuild, der vom kürzlich abgeschlossenen Continuous Delivery-Build erstellt wurde.

2. Klicken Sie auf den Endpunkt für den Dienst hello-cloudbuild. „Hallo Welt!“ wird angezeigt. Wenn kein Endpunkt vorhanden ist oder ein Load-Balancer-Fehler auftritt, müssen Sie möglicherweise einige Minuten warten, bis der Load-Balancer vollständig initialisiert ist. Klicken Sie bei Bedarf auf Aktualisieren, um die Seite zu aktualisieren.

3. Ersetzen Sie in Cloud Shell sowohl bei der Anwendung als auch beim Einheitentest "Hello World" durch "Hello Cloud Build".

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   sed -i 's/Hello World/Hello Cloud Build/g' app.py
   sed -i 's/Hello World/Hello Cloud Build/g' test_app.py
   

4. Übernehmen Sie die Änderung und übertragen Sie diese per Push in Cloud Source Repositories.

   git add app.py test_app.py
   git commit -m "Hello Cloud Build"
   git push google master
   

   Dadurch wird die gesamte CI/CD-Pipeline ausgelöst.

5. Aktualisieren Sie die Anwendung in Ihrem Browser nach einigen Minuten. „Hello Cloud Build!“ wird angezeigt.

Rollback testen

In diesem Abschnitt führen Sie ein Rollback zur Version der Anwendung durch, in der "Hello World!" angezeigt wurde.

1. Rufen Sie in der Cloud Build-Konsole das Repository hello-cloudbuild-env auf.

   Zu Cloud Build

2. Klicken Sie auf den zweitaktuellsten Build.

3. Klicken Sie auf Neu erstellen.

4. Wenn der Build fertig erstellt ist, laden Sie die Anwendung noch einmal in Ihrem Browser. „Hello World!“ wird noch einmal angezeigt.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

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

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

   Go to Manage resources

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

Ressourcen löschen

Wenn Sie das in dieser Anleitung verwendete Google Cloud-Projekt beibehalten möchten, löschen Sie die einzelnen Ressourcen:

1. Löschen Sie die lokalen Git-Repositories.

   cd ~
   rm -rf ~/hello-cloudbuild-app
   rm -rf ~/hello-cloudbuild-env
   

2. Löschen Sie die Git-Repositories in Cloud Source Repositories.

   gcloud source repos delete hello-cloudbuild-app --quiet
   gcloud source repos delete hello-cloudbuild-env --quiet
   

3. Löschen Sie die Cloud Build-Trigger.

   1. Öffnen Sie die Seite Build-Trigger von Cloud Build.

      Zur Seite "Trigger"

   2. Klicken Sie für jeden Trigger auf Mehr und dann auf Löschen.

4. Löschen Sie das Docker-Repository in Artifact Registry.

   gcloud artifacts repositories delete my-repository \
       --location=us-central1
   

5. Entfernen Sie die Berechtigung, die Cloud Build zum Herstellen einer Verbindung mit GKE erteilt wurde.

   PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
       --format='get(projectNumber)')"
   gcloud projects remove-iam-policy-binding ${PROJECT_NUMBER} \
       --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role=roles/container.developer
   

6. Löschen Sie den GKE-Cluster.

   gcloud container clusters delete hello-cloudbuild \
      --region us-central1
   

Weitere Informationen

• Erweiterte Cloud Build-Features kennenlernen: Reihenfolge der Build-Schritte konfigurieren, Artefakte erstellen, testen und bereitstellen, Benutzerdefinierte Build-Schritte erstellen
• Erfahren, wie man ein GitHub- oder Bitbucket-Repository nach Cloud Source Repositories spiegelt
• Cloud Build direkt mit GitHub-Repository verbinden