GSP1077

Übersicht

Im Rahmen dieses Labs 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 bereitstellt.

Für dieses Lab erstellen Sie 2 Git-Repositories:

• 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 Zweig des env-Repository speichert.

Die Repositories „app“ und „env“ bleiben getrennt, weil sie unterschiedliche Lebenszyklen und Verwendungszwecke haben. 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 Zweige haben, die jeweils einer bestimmten Umgebung zugeordnet sind und auf ein bestimmtes Container-Image verweisen, das app-Repository jedoch nicht. Sie verwenden in diesem Lab allerdings nur die Produktionsumgebung.

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 env-Repositorys auf das derzeit verwendete Manifest zugreifen
• Rollback zu einer vorherigen Version durch erneutes Ausführen des jeweiligen Cloud Build-Builds

Lernziele

Aufgaben in diesem Lab:

• Kubernetes Engine-Cluster erstellen
• Cloud Source Repositories erstellen
• Cloud Build von Cloud Source Repositories aus aktivieren
• 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 die Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung selbst 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, 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: Wenn Sie über ein persönliches Google Cloud-Konto oder -Projekt verfügen, verwenden Sie es nicht für dieses Lab. So werden zusätzliche Kosten für Ihr Konto vermieden.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Pop-up-Fenster geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der linken Seite befindet sich der Bereich Details zum Lab mit diesen Informationen:

   • Schaltfläche Google Cloud Console öffnen
   • Restzeit
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab

2. Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).

   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.

3. 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 Details zum Lab.

4. Klicken Sie auf Weiter.

5. 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 Details zum Lab.

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

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder Zwei-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 sich eine Liste der Google Cloud-Produkte und ‑Dienste ansehen möchten, klicken Sie oben links auf das Navigationsmenü.

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.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

Wenn Sie verbunden sind, sind Sie bereits authentifiziert und das Projekt ist auf Ihre 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.

2. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

3. 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`

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

1. Legen Sie in Cloud Shell eine Projekt-ID und Projektnummer fest. Speichern Sie diese als die Variablen PROJECT_ID und PROJECT_NUMBER ab:

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

In der nächsten Aufgabe bereiten Sie Ihr Google Cloud Project für die Verwendung vor. Dazu aktivieren Sie die erforderlichen APIs, initialisieren die Git-Konfiguration in Cloud Shell und laden den später in der Übung verwendeten Beispielcode herunter.

2. Führen Sie den folgenden Befehl aus, um die APIs für GKE, Cloud Build, Cloud Source Repositories und Container Analysis zu aktivieren:

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

3. Erstellen Sie ein Docker-Repository der Artifact Registry mit der Bezeichnung „my-repository“ in der Region , um Container-Images zu speichern:

gcloud artifacts repositories create my-repository \ --repository-format=docker \ --location=$REGION

4. Erstellen Sie einen GKE-Cluster, um die Beispielanwendung dieses Labs bereitzustellen:

gcloud container clusters create hello-cloudbuild --num-nodes 1 --region $REGION

5. 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. Wenn Sie kein GitHub-Konto haben, können Sie hier einfach Ihre aktuellen Daten eintragen. Für dieses Lab ist kein Konto erforderlich:

git config --global user.email "you@example.com" git config --global user.name "Your Name"

Klicken Sie auf Fortschritt prüfen. Dienste aktivieren, Artifact Registry und GKE-Cluster erstellen

Aufgabe 2: Git-Repositories in Cloud Source Repositories erstellen

In dieser Aufgabe erstellen Sie die beiden Git-Repositories (hello-cloudbuild-app und hello-cloudbuild-env) und initialisieren hello-cloudbuild-app mit Beispielcode.

1. Führen Sie diese Befehle in Cloud Shell aus, um die beiden Git-Repositories zu erstellen:

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/gke-gitops-tutorial-cloudbuild hello-cloudbuild-app

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

cd ~/hello-cloudbuild-app export REGION={{{project_0.default_region | "REGION"}}} sed -i "s/us-central1/$REGION/g" cloudbuild.yaml sed -i "s/us-central1/$REGION/g" cloudbuild-delivery.yaml sed -i "s/us-central1/$REGION/g" cloudbuild-trigger-cd.yaml sed -i "s/us-central1/$REGION/g" kubernetes.yaml.tpl PROJECT_ID=$(gcloud config get-value project) git remote add google "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"

Der soeben 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)

Klicken Sie auf Fortschritt prüfen. Git-Repositories erstellen

Aufgabe 3: Container-Image mit Cloud Build erstellen

Der geklonte Code enthält bereits 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 ~/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.

2. Nachdem der Build fertig erstellt wurde, rufen Sie in der Cloud Console Artifact Registry > Repositories auf, um zu überprüfen, ob das neue Container-Image wirklich in der Artifact Registry verfügbar ist. Klicken Sie auf my-repository.

Klicken Sie auf Fortschritt prüfen. Container-Image mit Cloud Build erstellen

Aufgabe 4: CI-Pipeline erstellen

In dieser Aufgabe 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. Wenn ein neuer Commit per Push in Cloud Source Repositories übertragen wird, wird jene Pipeline automatisch ausgelöst. Die bereits im Code enthaltene Datei cloudbuild.yaml enthält die Konfiguration der Pipeline.

1. Rufen Sie in der Cloud Console Cloud Build > Triggers auf.
2. Klicken Sie auf Trigger erstellen.
3. Geben Sie in das Feld „Name“ hello-cloudbuild ein.
4. Wählen Sie unter Ereignis die Option Push zu Zweig aus.
5. Wählen Sie unter Quelle die Option hello-cloudbuild-app als Repository und .* (beliebiger Zweig) als Zweig aus.
6. Wählen Sie unter Build-Konfiguration die Option Cloud Build-Konfigurationsdatei aus.
7. Geben Sie im Feld Speicherort der Cloud Build-Konfigurationsdatei nach dem / cloudbuild.yaml ein.
8. Klicken Sie auf Erstellen.

Nachdem der Trigger erstellt wurde, kehren Sie zur Cloud Shell zurück. Sie müssen den Anwendungscode per Push in Cloud Source Repositories übertragen, um die CI-Pipeline in Cloud Build auszulösen.

9. Führen Sie den folgenden Befehl aus, um den Trigger zu starten:

cd ~/hello-cloudbuild-app git add . git commit -m "Type Any Commit Message here" git push google master

10. Rufen Sie in der Cloud Console Cloud Build > Dashboard auf.

11. Sie sollten einen Build sehen, der gerade ausgeführt wird oder kürzlich abgeschlossen wurde. Sie können auf den Build klicken, um dessen Ausführung zu verfolgen und die Logs zu überprüfen.

Klicken Sie auf Fortschritt prüfen. CI-Pipeline (CI) erstellen

Aufgabe 5: Testumgebung und CD-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 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 IAM-Rolle (Identity and Access Management) „Kubernetes Engine Developer“.

1. Führen Sie in Cloud Shell diesen 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.

Klonen Sie als Erstes das Repository hello-cloudbuild-env und erstellen Sie den Zweig „production“. Noch ist dies leer.

2. Führen Sie in Cloud Shell diesen Befehl aus:

cd ~ gcloud source repos clone hello-cloudbuild-env cd ~/hello-cloudbuild-env git checkout -b production

3. Kopieren Sie als Nächstes die Datei cloudbuild-delivery.yaml aus dem Repository hello-cloudbuild-app in das gerade erstellte Repository und übernehmen Sie die Änderung:

cd ~/hello-cloudbuild-env cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/hello-cloudbuild-env/cloudbuild.yaml git add . git commit -m "Create cloudbuild.yaml for deployment"

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

• Cloud Build wendet das Manifest auf den GKE-Cluster an.
• Bei Erfolg kopiert Cloud Build das Manifest in den Zweig „production“.

4. Erstellen Sie einen Zweig mit der Bezeichnung „candidate“ und übertragen Sie beide Zweige per Push in Cloud Source Repositories, damit sie dort verfügbar sind.

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

5. Weisen Sie dem Cloud Build-Dienstkonto die IAM-Rolle „Source Repository Writer“ 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

1. Rufen Sie in der Cloud Console Cloud Build > Triggers auf.
2. Klicken Sie auf Trigger erstellen.
3. Geben Sie in das Feld „Name“ hello-cloudbuild-deploy ein.
4. Wählen Sie unter Ereignis die Option Push zu Zweig aus.
5. Wählen Sie unter Quelle die Option hello-cloudbuild-env als Repository und ^candidate$ als Zweig aus.
6. Wählen Sie unter Build-Konfiguration die Option Cloud Build-Konfigurationsdatei aus.
7. Geben Sie im Feld Speicherort der Cloud Build-Konfigurationsdatei nach dem / cloudbuild.yaml ein.
8. Klicken Sie auf Erstellen.

Ändern Sie die CI-Pipeline, damit die CD-Pipeline ausgelöst wird.

Als Nächstes 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. Kopieren Sie die erweiterte Version der Datei cloudbuild.yaml in das app-Repository:

cd ~/hello-cloudbuild-app cp cloudbuild-trigger-cd.yaml cloudbuild.yaml

Die Datei cloudbuild-trigger-cd.yaml ist eine erweiterte Version der Datei cloudbuild.yaml. Mit der Datei werden die Schritte weiter unten hinzugefügt, durch die das neue Kubernetes-Manifest erzeugt und die CD-Pipeline ausgelöst wird.

Hinweis: Diese Pipeline verwendet zum Rendern der Manifestvorlage ein einfaches sed-Skript. In der Praxis bietet es sich an, dafür ein spezielles Tool wie kustomize oder skaffold zu verwenden. Dadurch erhalten Sie mehr Kontrolle über das Rendern der Manifestvorlagen.

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

cd ~/hello-cloudbuild-app git add cloudbuild.yaml git commit -m "Trigger CD pipeline" git push google master

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

Klicken Sie auf Fortschritt prüfen. Testumgebung und CD-Pipeline erstellen

Aufgabe 6: Cloud Build-Pipeline überprüfen

1. Rufen Sie in der Cloud Console Cloud Build > Dashboard auf.
2. Klicken Sie auf den Trigger der hello-cloudbuild-app, um seine Ausführung zu beobachten und die Logs aufzurufen. 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.

3. Kehren Sie zum Haupt-Dashboard zurück.
4. Sie sollten einen Build für das Repository hello-cloudbuild-env sehen, der gerade ausgeführt wird oder kürzlich abgeschlossen wurde. Sie können auf den Build klicken, um dessen Ausführung zu verfolgen und die Logs zu überprüfen.

Aufgabe 7: Vollständige Pipeline testen

Die gesamte CI/CD-Pipeline ist jetzt konfiguriert. Testen Sie den gesamten Ablauf.

1. Rufen Sie in der Cloud Console Kubernetes Engine > Gateways, Dienste und eingehender Traffic auf.

Auf der Seite sollte nur ein Dienst namens hello-cloudbuild aufgelistet sein. Dieser wurde durch den CD-Build erstellt, der gerade ausgeführt wurde.

2. 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 bei Bedarf auf Aktualisieren, um die Seite zu aktualisieren.

3. Ersetzen Sie in 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

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

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

Aktualisieren Sie die Anwendung in Ihrem Browser nach einigen Minuten. Es sollte jetzt „Hello Cloud Build!“ angezeigt werden.

Aufgabe 8: Rollback testen

In dieser Aufgabe führen Sie ein Rollback zur Version der Anwendung durch, in der „Hello World!“ angezeigt wurde.

1. Rufen Sie in der Cloud Console Cloud Build > Dashboard auf.
2. Klicken Sie auf den Link Alle anzeigen unter Build-Verlauf für das Repository hello-cloudbuild-env.
3. Klicken Sie auf den zweitaktuellsten Build.
4. 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 26. Januar 2024 aktualisiert

Lab zuletzt am 19. Januar 2024 getestet

© 2024 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.