GSP1077
Übersicht
Cloud Build ist ein Dienst zum Ausführen von Builds in Google Cloud. Sie können Quellcode importieren, Builds ausführen und vieles mehr.
In diesem Lab erstellen Sie eine CI/CD-Pipeline (Continuous Integration/Continuous Deployment), 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 der Google Kubernetes Engine bereitstellt.

In diesem Lab verwenden Sie 2 Git-Repositories, die auf einem dedizierten, selbst gehosteten Gitea-Git-Server (git-server) gehostet werden:
-
app: enthält den Quellcode der Anwendung (hello-cloudbuild-app)
-
env: enthält die Kubernetes-Deployment-Manifeste (hello-cloudbuild-env)
Wenn Sie eine Änderung am Repository app per Push machen, 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 Repository env. Dies löst eine weitere Cloud Build-Pipeline aus, die das Manifest auf den GKE-Cluster anwendet und es bei Erfolg in einem anderen Zweig des Repositorys env speichert.
Die Repositories app und env bleiben getrennt, weil sie unterschiedliche Lebenszyklen und Verwendungszwecke haben. Das Repository app ist für eine bestimmte Anwendung vorgesehen und wird primär von Menschen genutzt. Das Repository env kann von mehreren Anwendungen gemeinsam verwendet werden und wird von automatisierten Systemen wie Cloud Build genutzt. Das Repository env kann mehrere Zweige haben, die jeweils einer bestimmten Umgebung zugeordnet sind und auf ein bestimmtes Container-Image verweisen, das Repository app jedoch nicht.
Nach Abschluss dieses Labs 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 Zweig „production“ des Repositorys
env auf das derzeit verwendete Manifest zugreifen
- Rollback zu einer vorherigen Version durch erneutes Ausführen des jeweiligen Cloud Build-Builds durchführen

Lernziele
Aufgaben in diesem Lab:
- Kubernetes Engine-Cluster erstellen
- Verbindung zu einem dedizierten Git-Server herstellen und Git-Repositories initialisieren
- Cloud Build-Pipelines aus Quellcode-Repositories ausführen
- Tests automatisieren und ein bereitstellbares Container-Image über Cloud Build veröffentlichen
- Ressourcen verwalten, die in einem Kubernetes Engine-Cluster über Cloud Build bereitgestellt werden
Einrichtung und Anforderungen
Vor dem Klick auf „Start Lab“ (Lab starten)
Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange Google Cloud-Ressourcen für das Lab verfügbar sind.
In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.
Für dieses Lab benötigen Sie Folgendes:
- Einen Standardbrowser (empfohlen wird Chrome)
Hinweis: Nutzen Sie den privaten oder Inkognitomodus (empfohlen), um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.
- Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.
Hinweis: Verwenden Sie für dieses Lab nur das Teilnehmerkonto. Wenn Sie ein anderes Google Cloud-Konto verwenden, fallen dafür möglicherweise Kosten an.
Lab starten und bei der Google Cloud Console anmelden
-
Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Dialogfeld geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können.
Auf der rechten Seite befindet sich der Bereich Lab-Einrichtung und ‑Zugriff:
- Button Google Cloud Console öffnen
- Die temporären Anmeldedaten (Nutzername und Passwort), die Sie für dieses Lab verwenden müssen
- Gegebenenfalls weitere Informationen für dieses Lab
Der Lab-Timer befindet sich oben auf der Seite und zeigt die verbleibende Zeit an.
-
Klicken Sie auf Google Cloud Console öffnen. Wenn Sie Chrome verwenden, können Sie auch rechtsklicken und Link in Inkognitofenster öffnen auswählen.
Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite „Anmelden“ geöffnet.
Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.
Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.
-
Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.
{{{user_0.username | "Username"}}}
Sie finden den Nutzernamen auch im Bereich Lab-Einrichtung und ‑Zugriff.
-
Klicken Sie auf Weiter.
-
Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.
{{{user_0.password | "Password"}}}
Sie finden das Passwort auch im Bereich Lab-Einrichtung und ‑Zugriff.
-
Klicken Sie auf Weiter.
Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos.
Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.
-
Klicken Sie sich durch die nachfolgenden Seiten:
- Akzeptieren Sie die Nutzungsbedingungen.
- Fügen Sie keine Wiederherstellungsoptionen oder 2-Faktor-Authentifizierung hinzu, da dies nur ein temporäres Konto ist.
- Melden Sie sich nicht für kostenlose Testversionen an.
Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.
Hinweis: Wenn Sie auf Google Cloud-Produkte und ‑Dienste zugreifen möchten, klicken Sie auf das Navigationsmenü oder geben Sie den Namen des Produkts oder Dienstes in das Feld Suchen ein.
Cloud Shell aktivieren
Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.
-
Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren
.
-
Klicken Sie sich durch die folgenden Fenster:
- Fahren Sie mit dem Informationsfenster zu Cloud Shell fort.
- Autorisieren Sie Cloud Shell, Ihre Anmeldedaten für Google Cloud API-Aufrufe zu verwenden.
Wenn eine Verbindung besteht, sind Sie bereits authentifiziert und das Projekt ist auf Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:
Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}
gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.
- (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:
gcloud auth list
- Klicken Sie auf Autorisieren.
Ausgabe:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
Um das aktive Konto festzulegen, führen Sie diesen Befehl aus:
$ gcloud config set account `ACCOUNT`
- (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:
gcloud config list project
Ausgabe:
[core]
project = {{{project_0.project_id | "PROJECT_ID"}}}
Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.
Aufgabe 1: Lab initialisieren
Im Rahmen dieser Aufgabe richten Sie Ihre Umgebung ein:
- Projekt-ID, Projektnummer und Git-Server-IP als Variablen importieren
- APIs für GKE, Cloud Build, Secret Manager und Artefaktanalyse aktivieren
- Artifact Registry-Docker-Repository erstellen
- GKE-Cluster erstellen, um die Beispielanwendung dieses Labs bereitzustellen
- Führen Sie in der Cloud Shell den folgenden Befehl aus, um Ihre Projekt-ID, Projektnummer und Region festzulegen:
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
export REGION={{{ project_0.default_region }}}
gcloud config set compute/region $REGION
export GIT_SERVER_IP=$(gcloud compute instances describe git-server --zone={{{ project_0.default_zone }}} --format='get(networkInterfaces[0].accessConfigs[0].natIP)')
echo "Git Server IP is: ${GIT_SERVER_IP}"
- Führen Sie den folgenden Befehl aus, um die APIs für GKE, Cloud Build, Secret Manager und Artefaktanalyse zu aktivieren:
gcloud services enable container.googleapis.com \
cloudbuild.googleapis.com \
secretmanager.googleapis.com \
containeranalysis.googleapis.com
- Erstellen Sie in Artifact Registry ein Docker-Repository mit dem Namen
my-repository in der Region . Dort werden die Container-Images gespeichert:
gcloud artifacts repositories create my-repository \
--repository-format=docker \
--location=$REGION
- Erstellen Sie einen GKE-Cluster, um die Beispielanwendung dieses Labs bereitzustellen:
gcloud container clusters create hello-cloudbuild --num-nodes 1 --region $REGION
- Führen Sie den folgenden Befehl aus, um Git in der Cloud Shell zu konfigurieren:
git config --global user.name "giteaadmin"
git config --global user.email "student@qwiklabs.net"
Klicken Sie auf Fortschritt prüfen.
Dienste aktivieren, Artifact Registry und GKE-Cluster erstellen
Aufgabe 2: Verbindung zu den Git-Repositories auf dem Git-Server herstellen
In dieser Aufgabe initialisieren Sie die beiden Git-Repositories (hello-cloudbuild-app und hello-cloudbuild-env) auf Ihrem dedizierten Git-Server (git-server) und übertragen den ersten Beispielcode.
- Laden Sie den Beispielcode aus Cloud Storage herunter:
cd ~
git clone http://${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-app.git
Der geklonte Code enthält eine einfache „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)
Aufgabe 3: Container-Image mit Cloud Build erstellen
Im Rahmen dieser Aufgabe verwenden Sie ein vorhandenes Dockerfile, um mit Cloud Build ein Container-Image zu erstellen und zu speichern.
Der zuvor geklonte Code enthält die Docker-Datei:
FROM python:3.11-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.
- Erstellen Sie in Cloud Shell mit dem folgenden Befehl auf Grundlage des neuesten Commits einen Cloud Build-Build:
cd ~/hello-cloudbuild-app
COMMIT_ID="$(git rev-parse --short=7 HEAD)"
gcloud builds submit --tag="${REGION}-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.
- Nachdem der Build abgeschlossen ist, geben Sie in der Titelleiste der Google Cloud Console Artifact Registry in das Suchfeld ein und klicken Sie in den Suchergebnissen auf Artifact Registry. Prüfen Sie, ob das neue Container-Image tatsächlich in Artifact Registry verfügbar ist. Klicken Sie auf my-repository, um das Image
hello-cloudbuild in der Liste Image aufzurufen.
Klicken Sie auf Fortschritt prüfen.
Container-Image mit Cloud Build erstellen
Aufgabe 4: CI-Pipeline erstellen und ausführen
In dieser Aufgabe konfigurieren Sie Cloud Build und führen es aus, um automatisch Unittests auszuführen, das Container-Image zu erstellen und es per Push an Artifact Registry zu übertragen.

Die bereits im Code enthaltene Datei cloudbuild.yaml enthält die Konfiguration der Pipeline.
- Übernehmen Sie die Änderungen und übertragen Sie sie per Push auf Ihren Git-Server:
cd ~/hello-cloudbuild-app
git add .
git commit -m "Trigger CI pipeline"
git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-app.git main
- Senden Sie den Build mit dem folgenden Befehl an Cloud Build:
gcloud builds submit --config=cloudbuild.yaml --substitutions=SHORT_SHA=$(git rev-parse --short=7 HEAD) .
- Suchen Sie in der Google Cloud Console nach Cloud Build und klicken Sie im linken Bereich auf Verlauf. Sie können das Ausführungslog Ihres CI-Builds prüfen.
Klicken Sie auf Fortschritt prüfen.
CI-Pipeline erstellen
Aufgabe 5: SSH-Schlüssel-Secret in Secret Manager speichern
In diesem Schritt speichern Sie ein Secret eines privaten Schlüssels in Secret Manager und gewähren Cloud Build Berechtigungen für den Zugriff auf Secret Manager.
SSH-Schlüssel erstellen und in Secret Manager speichern
-
Erstellen Sie in der Cloud Shell einen SSH-Schlüssel:
mkdir -p ~/workingdir && cd ~/workingdir
ssh-keygen -t rsa -b 4096 -N '' -f id_rsa -C "student@qwiklabs.net"
-
Speichern Sie den privaten SSH-Schlüssel in Secret Manager, indem Sie den folgenden Befehl in der Cloud Shell ausführen:
gcloud secrets create ssh_key_secret --data-file=$HOME/workingdir/id_rsa
Alternative Vorgehensweise in der Google Cloud Console:
a. Laden Sie zuerst id_rsa auf Ihren Computer herunter. Klicken Sie dazu in der Cloud Shell auf das Dreipunkt-Menü (
) > Datei herunterladen, geben Sie workingdir/id_rsa ein und klicken Sie auf Herunterladen.
b. Suchen Sie nach Secret Manager und klicken Sie auf Secret Manager.
c. Klicken Sie auf Secret erstellen.
d. Setzen Sie Name auf ssh_key_secret.
e. Wählen Sie unter Secret-Wert die Option Hochladen aus und laden Sie die heruntergeladene Datei id_rsa hoch.
f. Klicken Sie auf Secret erstellen.
Dem Dienstkonto die Berechtigung für den Zugriff auf Secret Manager gewähren
Führen Sie in der Cloud Shell den folgenden Befehl aus, um dem Compute Engine-Standarddienstkonto Zugriff auf Secret Manager zu gewähren:
PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
--member=serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \
--role=roles/secretmanager.secretAccessor
Klicken Sie auf Fortschritt prüfen.
SSH-Schlüssel-Secret in Secret Manager speichern
Aufgabe 6: Testumgebung und CD-Pipeline erstellen
Sie können Cloud Build auch für die CD-Pipeline (Continuous Delivery) verwenden. Die Pipeline wird jedes Mal ausgeführt, wenn ein Commit per Push an den Zweig „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 Zweig „production“. Für diesen Prozess gilt Folgendes:
- Im Zweig „candidate“ werden die Deployment-Versuche in Verlaufsform angezeigt.
- Im Zweig „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 Zweig „production“ aktualisiert, um den Verlauf der Deployments korrekt widerzuspiegeln.
Als Nächstes ändern Sie die CI-Pipeline, sodass der Zweig „candidate“ des Repositorys hello-cloudbuild-env aktualisiert wird, wodurch dann die CD-Pipeline ausgelöst wird.
Cloud Build Zugriff auf GKE gewähren
Damit die Anwendung im Kubernetes-Cluster bereitgestellt werden kann, benötigt Cloud Build die Rolle „Kubernetes Engine Developer“.
- 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
Sie müssen das Repository hello-cloudbuild-env mit zwei Zweigen („production“ und „candidate“) und einer Cloud Build-Konfigurationsdatei initialisieren, in welcher der Deployment-Prozess beschrieben ist.
- Laden Sie in der Cloud Shell den Beispielcode aus Cloud Storage herunter:
cd ~
git clone http://${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-env.git
- Ersetzen Sie in der Cloud Shell den Inhalt von
cloudbuild.yaml im Repository hello-cloudbuild-env, indem Sie den folgenden Befehl ausführen:
cd ~/hello-cloudbuild-env
cat <<'EOF' > cloudbuild.yaml
# Copyright 2018 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
substitutions:
_COMMIT_SHA: 'v1.0'
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={{{ project_0.default_region }}}'
- 'CLOUDSDK_CONTAINER_CLUSTER=hello-cloudbuild'
# This step copies the applied manifest to the production branch
- name: 'gcr.io/cloud-builders/gcloud'
id: Copy to production branch
entrypoint: /bin/sh
args:
- '-c'
- |
set -x && \
git clone -b production http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-env.git prod_repo && \
cd prod_repo && \
git config user.email "student@qwiklabs.net" && \
git config user.name "Cloud Build" && \
cp ../kubernetes.yaml kubernetes.yaml && \
git add kubernetes.yaml && \
git commit -m "Deployed manifest from commit $_COMMIT_SHA" && \
git push origin production
options:
logging: CLOUD_LOGGING_ONLY
EOF
sed -i "s/\${GIT_SERVER_IP}/$GIT_SERVER_IP/g" cloudbuild.yaml
Führen Sie ein Commit durch und übertragen Sie die Änderung an hello-cloudbuild-env:
cd ~/hello-cloudbuild-env
git checkout candidate
git add cloudbuild.yaml
git commit -m "Create cloudbuild.yaml for deployment"
git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-env.git candidate
CI-Pipeline ändern, damit die CD-Pipeline ausgelöst wird
Als Nächstes aktualisieren Sie die CI-Pipeline in hello-cloudbuild-app, um eine neue Version des Kubernetes-Manifests zu generieren und per Push an hello-cloudbuild-env zu übertragen, damit die CD-Pipeline ausgelöst wird.
- Ersetzen Sie in der Cloud Shell
cloudbuild.yaml in hello-cloudbuild-app und setzen Sie die IP-Adresse Ihres Git-Servers ein, indem Sie die folgenden Befehle ausführen:
cd ~/hello-cloudbuild-app
cat <<'EOF' > cloudbuild.yaml
# Copyright 2018 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
substitutions:
_SHORT_SHA: 'v1.0'
_COMMIT_SHA: 'v1.0'
steps:
# This step runs the unit tests on the app
- name: 'python:3.11-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'
- '{{{ project_0.default_region }}}-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$_SHORT_SHA'
- '.'
# This step pushes the image to Artifact Registry
- name: 'gcr.io/cloud-builders/docker'
id: Push
args:
- 'push'
- '{{{ project_0.default_region }}}-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$_SHORT_SHA'
# This step clones the hello-cloudbuild-env repository
- name: 'gcr.io/cloud-builders/gcloud'
id: Clone env repo
entrypoint: /bin/sh
args:
- '-c'
- |
git clone http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-env.git && \
cd hello-cloudbuild-env && \
git checkout candidate && \
git config user.email "student@qwiklabs.net" && \
git config user.name "Cloud Build"
# 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 candidate branch
- 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 {{{ project_0.default_region }}}-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
options:
logging: CLOUD_LOGGING_ONLY
EOF
sed -i "s/\${GIT_SERVER_IP}/$GIT_SERVER_IP/g" cloudbuild.yaml
- Führen Sie ein Commit der Änderungen durch, übertragen Sie sie per Push an den Git-Server und senden Sie den Pipeline-Build:
cd ~/hello-cloudbuild-app
git add cloudbuild.yaml
git commit -m "Trigger CD pipeline"
git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-app.git main
gcloud builds submit --config=cloudbuild.yaml --substitutions=_SHORT_SHA=$(git rev-parse --short=7 HEAD),_COMMIT_SHA=$(git rev-parse HEAD) .
Dadurch wird die CI-Pipeline in Cloud Build ausgelöst, die das Anwendungs-Image erstellt und ein neues kubernetes.yaml-Manifest per Push in das Repository hello-cloudbuild-env überträgt.
- Rufen Sie das generierte Manifest in
hello-cloudbuild-env ab und lösen Sie den CD-Deployment-Build aus:
cd ~/hello-cloudbuild-env
git pull http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-env.git candidate
gcloud builds submit --config=cloudbuild.yaml --substitutions=_COMMIT_SHA=$(git rev-parse HEAD) .
Klicken Sie auf Fortschritt prüfen.
Testumgebung und CD-Pipeline erstellen
Aufgabe 7: Cloud Build-Pipeline überprüfen
In dieser Aufgabe überprüfen Sie die Cloud Build-Pipeline in der Console.
- Rufen Sie in der Console Cloud Build > Verlauf auf.
- Klicken Sie auf den neuesten Build, um dessen Ausführung zu verfolgen und die Logs anzusehen.
- Prüfen Sie, ob die Build-Pipeline alle Schritte erfolgreich ausgeführt hat.
Aufgabe 8: Vollständige Pipeline testen
Sie haben jetzt die gesamte CI/CD-Pipeline konfiguriert. Im Rahmen dieser Aufgabe führen Sie einen End-to-End-Test durch.
- Klicken Sie in der Console im Navigationsmenü (
) auf Kubernetes Engine > Gateways, Dienste und eingehender Traffic > Dienste.
Auf der Seite sollte nur ein Dienst namens hello-cloudbuild aufgelistet sein. Dieser wurde durch den CD-Build erstellt, der gerade ausgeführt wurde.
- Klicken Sie auf den Endpunkt für den Dienst hello-cloudbuild. Es sollte „Hello World!“ angezeigt werden. 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 wurde. Klicken Sie gegebenenfalls auf Aktualisieren, um die Seite neu zu laden.

- Ersetzen Sie in der Cloud Shell sowohl bei der Anwendung als auch beim Unittest „Hello World“ durch „Hello Cloud Build“.
cd ~/hello-cloudbuild-app
sed -i 's/Hello World/Hello Cloud Build/g' app.py
sed -i 's/Hello World/Hello Cloud Build/g' test_app.py
- Führen Sie ein Commit der Änderung durch und übertragen Sie sie per Push an den Git-Server. Senden Sie dann den CI-Build:
git add app.py test_app.py
git commit -m "Hello Cloud Build"
git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-app.git main
gcloud builds submit --config=cloudbuild.yaml --substitutions=_SHORT_SHA=$(git rev-parse --short=7 HEAD),_COMMIT_SHA=$(git rev-parse HEAD) .
- Übertragen Sie das aktualisierte Manifest per Pull in
hello-cloudbuild-env und senden Sie den Build der Deployment-Pipeline, um die neue Anwendungsversion bereitzustellen:
cd ~/hello-cloudbuild-env
git pull http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/hello-cloudbuild-env.git candidate
gcloud builds submit --config=cloudbuild.yaml --substitutions=_COMMIT_SHA=$(git rev-parse HEAD) .
Aktualisieren Sie die Anwendung in Ihrem Browser nach einigen Minuten. Es sollte jetzt „Hello Cloud Build!“ angezeigt werden.

Aufgabe 9: Rollback testen
Im Rahmen dieser Aufgabe führen Sie ein Rollback zur Version der Anwendung durch, in der „Hello World!“ angezeigt wurde.
- Geben Sie in der Titelleiste der Console Cloud Build-Dashboard in das Suchfeld ein und klicken Sie in den Suchergebnissen auf Cloud Build. Achten Sie darauf, dass im linken Bereich Verlauf ausgewählt ist.
- Klicken Sie im Build-Verlauf auf den zweitaktuellsten Build.
- Klicken Sie auf Neu erstellen.

Wenn der Build fertig erstellt ist, laden Sie die Anwendung noch einmal in Ihrem Browser. Nun sollte wieder „Hello World!“ angezeigt werden.

Das wars! Sie haben das Lab erfolgreich abgeschlossen.
Jetzt können Sie Cloud Build verwenden, um CI-Pipelines mit GKE auf Google Cloud zu erstellen und zurückzusetzen.
Google Cloud-Schulungen und -Zertifizierungen
In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.
Anleitung zuletzt am 20. Juli 2026 aktualisiert
Lab zuletzt am 20. Juli 2026 getestet
© 2026 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.