Enable services, create an artifact registry and the GKE cluster
Fortschritt prüfen
/ 20
Create a container image with Cloud Build
Fortschritt prüfen
/ 20
Create the Continuous Integration (CI) Pipeline
Fortschritt prüfen
/ 20
Accessing GitHub from a build via SSH keys
Fortschritt prüfen
/ 20
Create the Test Environment and CD Pipeline
Fortschritt prüfen
/ 20
Quick tip: Review the prerequisites before you run the lab
Use an Incognito or private browser window to run this lab. This prevents any conflicts between your personal account and the student account, which may cause extra charges incurred to your personal account.
Testen und teilen Sie Ihr Wissen mit unserer Community.
done
Sie erhalten Zugriff auf über 700 praxisorientierte Labs, Skill-Logos und Kurse
Testen und teilen Sie Ihr Wissen mit unserer Community.
done
Sie erhalten Zugriff auf über 700 praxisorientierte Labs, Skill-Logos und Kurse
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 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 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
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.
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“.
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 „Details zum Lab“.
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 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 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 .
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.
(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
Legen Sie in Cloud Shell eine Projekt-ID und Projektnummer fest. Speichern Sie diese als die Variablen PROJECT_ID und PROJECT_NUMBER ab:
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.
Führen Sie den folgenden Befehl aus, um die APIs für GKE, Cloud Build, Cloud Source Repositories und Container Analysis zu aktivieren:
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:
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.
Führen Sie diese Befehle in Cloud Shell aus, um die beiden Git-Repositories zu erstellen:
Wenn Sie diesen Befehl ausführen, streamt Cloud Build die durch die Erstellung des Container-Images generierten Logs an Ihr Terminal.
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.
Rufen Sie in der Cloud Console Cloud Build > Triggers auf.
Klicken Sie auf Trigger erstellen.
Geben Sie in das Feld „Name“ hello-cloudbuild ein.
Wählen Sie unter Ereignis die Option Push zu Zweig aus.
Wählen Sie unter Quelle die Option hello-cloudbuild-app als Repository und .* (beliebiger Zweig) als Zweig aus.
Wählen Sie unter Build-Konfiguration die Option Cloud Build-Konfigurationsdatei aus.
Geben Sie im Feld Speicherort der Cloud Build-Konfigurationsdatei nach dem / cloudbuild.yaml ein.
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.
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
Rufen Sie in der Cloud Console Cloud Build > Dashboard auf.
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“.
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.
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
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“.
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.
Rufen Sie in der Cloud Console Cloud Build > Triggers auf.
Klicken Sie auf Trigger erstellen.
Geben Sie in das Feld „Name“ hello-cloudbuild-deploy ein.
Wählen Sie unter Ereignis die Option Push zu Zweig aus.
Wählen Sie unter Quelle die Option hello-cloudbuild-env als Repository und ^candidate$ als Zweig aus.
Wählen Sie unter Build-Konfiguration die Option Cloud Build-Konfigurationsdatei aus.
Geben Sie im Feld Speicherort der Cloud Build-Konfigurationsdatei nach dem / cloudbuild.yaml ein.
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.
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.
Ü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
Rufen Sie in der Cloud Console Cloud Build > Dashboard auf.
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.
Kehren Sie zum Haupt-Dashboard zurück.
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.
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.
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.
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
Übernehmen Sie die Änderung und übertragen Sie diese per Push in Cloud Source Repositories:
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.
Rufen Sie in der Cloud Console Cloud Build > Dashboard auf.
Klicken Sie auf den Link Alle anzeigen unter Build-Verlauf für das Repository hello-cloudbuild-env.
Klicken Sie 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.
Labs create a Google Cloud project and resources for a fixed time
Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
On the top left of your screen, click Start lab to begin
Use private browsing
Copy the provided Username and Password for the lab
Click Open console in private mode
Sign in to the Console
Sign in using your lab credentials. Using other credentials might cause errors or incur charges.
Accept the terms, and skip the recovery resource page
Don't click End lab unless you've finished the lab or want to restart it, as it will clear your work and remove the project
Diese Inhalte sind derzeit nicht verfügbar
Bei Verfügbarkeit des Labs benachrichtigen wir Sie per E-Mail
Sehr gut!
Bei Verfügbarkeit kontaktieren wir Sie per E-Mail
One lab at a time
Confirm to end all existing labs and start this one
Use private browsing to run the lab
Use an Incognito or private browser window to run this lab. This
prevents any conflicts between your personal account and the Student
account, which may cause extra charges incurred to your personal account.
Erstellen Sie eine CI/CD-Pipeline, die automatisch ein Container-Image generiert, das Image in Artifact Registry speichert, ein Kubernetes-Manifest in einem Git-Repository aktualisiert und die Anwendung in Google Kubernetes Engine bereitstellt.