GSP699
Übersicht
Was spricht dafür, eine monolithische Anwendung zu einer Mikrodienstarchitektur zu migrieren? Features einer Anwendung auf Mikrodienste aufzuteilen hat die folgenden Vorteile. Die meisten beruhen darauf, dass Mikrodienste lose miteinander gekoppelt sind.
- Mikrodienste können unabhängig voneinander getestet und bereitgestellt werden. Je kleiner die Deployment-Einheit ist, desto einfacher ist das Bereitstellen.
- Mikrodienste lassen sich in verschiedenen Sprachen und Frameworks implementieren. Für jeden Mikrodienst gibt es eine Auswahl an Technologien, die sich für den jeweiligen Anwendungsfall am besten eignen.
- Mikrodienste können von verschiedenen Teams verwaltet werden. Durch die Abgrenzung der Mikrodienste voneinander ist es einfacher, einem Team einen oder mehrere Dienste zuzuweisen.
- Durch das Umsteigen auf Mikrodienste sind die Teams weniger stark aufeinander angewiesen. Für jedes Team sind nur die APIs der Mikrodienste von Belang, für die es zuständig ist. Die Teams müssen sich weder darüber Gedanken machen, wie diese Mikrodienste implementiert werden, noch über ihre Releasezyklen usw.
- Sie können Ausfälle leichter im Design einplanen. Da die Dienste klar voneinander abgegrenzt sind, lässt sich einfacher feststellen, was zu tun ist, wenn ein Dienst ausfällt.
Mikrodienste haben gegenüber monolithischen Anwendungen jedoch auch einige Nachteile:
- Da es sich bei einer auf Mikrodiensten beruhenden Anwendung um eine Verknüpfung verschiedener Dienste handelt, die häufig auf nicht direkt erkennbare Weise miteinander interagieren, nimmt die allgemeine Komplexität des Systems tendenziell zu.
- Anders als bei monolithischen Anwendungen erfolgt die Kommunikation bei Mikrodiensten über ein Netzwerk und nicht über interne Strukturen. In manchen Fällen kann dies zu Sicherheitsproblemen führen. Bei Istio wird diesem Problem durch automatisches Verschlüsseln des Traffics zwischen den Mikrodiensten begegnet.
- Aufgrund von Latenzen zwischen den Diensten wird möglicherweise nicht das gleiche Leistungsniveau erreicht wie bei einem monolithischen Ansatz.
- Das Verhalten Ihres Systems wird nicht von einem einzelnen Dienst, sondern von mehreren Diensten und deren Zusammenwirken bestimmt. Daher ist es schwieriger, nachzuvollziehen, wie sich Ihr System in der Produktionsumgebung verhält, d. h., die Beobachtbarkeit wird erschwert. Auch dieses Problem kann mit Istio umgangen werden.
In diesem Lab stellen Sie eine monolithische Anwendung in einem Google Kubernetes Engine-Cluster bereit und teilen sie dann in Mikrodienste auf. Kubernetes ist eine Plattform zum Verwalten, Hosten, Skalieren und Bereitstellen von Containern. Container bieten die Möglichkeit, Code portabel zu verpacken und auszuführen. Sie eignen sich gut für Anwendungen, die in Form von Mikrodiensten entwickelt wurden und bei denen jeder Mikrodienst in einem eigenen Container ausgeführt werden kann.
Architekturdiagramm von Mikrodiensten
Als Erstes teilen Sie die monolithische Anwendung schrittweise in drei Mikrodienste auf. Die Mikrodienste sind „Orders“, „Products“ und „Frontend“. Mithilfe von Cloud Build erstellen Sie ein Docker-Image für jeden Mikrodienst. Anschließend stellen Sie die Mikrodienste in der Google Kubernetes Engine (GKE) mit einem Kubernetes-Dienst vom Typ LoadBalancer bereit und geben sie frei. Sie führen dies für alle Dienste aus und refaktorieren sie dabei gleichzeitig aus der monolithischen Anwendung. Während des gesamten Vorgangs werden sowohl die monolithische Anwendung als auch die Mikrodienste ausgeführt, bis Erstere gelöscht werden kann.
Lerninhalte
- Eine monolithische Anwendung in Mikrodienste aufteilen
- Google Kubernetes Engine-Cluster erstellen
- Docker-Image erstellen
- Docker-Images in Kubernetes bereitstellen
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
.
-
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.
Legen Sie die Standardzone und die Projektkonfiguration fest:
gcloud config set compute/zone {{{project_0.default_zone | (zone)}}}
Aufgabe 1: Quell-Repository klonen
Sie verwenden eine monolithische Anwendung für eine fiktive E-Commerce-Website mit einer einfachen Begrüßungsseite, einer Produktseite und einer Seite für den Bestellverlauf. Für die Anwendung muss nur die Quelle aus unserem Git-Repository geklont werden. Dann können uns darauf konzentrieren, sie in Mikrodienste aufzuteilen und in der GKE bereitzustellen.
- Führen Sie die folgenden Befehle aus, um das Git-Repository in Ihre Cloud Shell-Instanz zu klonen und um in das entsprechende Verzeichnis zu wechseln. Sie installieren auch die NodeJS-Abhängigkeiten, damit Sie die monolithische Anwendung testen können, bevor sie bereitgestellt wird.
cd ~
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd ~/monolith-to-microservices
./setup.sh
Die Ausführung des Skripts kann einige Minuten dauern.
Aufgabe 2: GKE-Cluster erstellen
Sie haben nun eine funktionsfähige Entwicklungsumgebung. Jetzt benötigen Sie noch einen Kubernetes-Cluster, um darin Ihre monolithische Anwendung und dann die Mikrodienste bereitzustellen. Damit der Cluster erstellt werden kann, müssen die richtigen APIs aktiviert sein.
- Führen Sie den folgenden Befehl aus, um die Containers API für die Verwendung von Google Kubernetes Engine zu aktivieren:
gcloud services enable container.googleapis.com
- Führen Sie den folgenden Befehl aus, um den GKE-Cluster fancy-cluster mit 3 Knoten zu erstellen:
gcloud container clusters create fancy-cluster --num-nodes 3 --machine-type=e2-standard-4
Warnung: Wenn Sie eine Fehlermeldung erhalten, dass keine Region oder Zone angegeben wurde, sollten Sie prüfen, ob Sie die standardmäßige Computing-Zone festgelegt haben. Informationen dazu finden Sie im Abschnitt über die Einrichtung der Umgebung.
Es kann einige Minuten dauern, bis der Cluster erstellt ist.
- Wenn der Befehl ausgeführt ist, führen Sie den folgenden Befehl aus, um die drei Worker-VM-Instanzen aufzulisten:
gcloud compute instances list
Ausgabe:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
gke-fancy-cluster-default-pool-ad92506d-1ng3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.7 XX.XX.XX.XX RUNNING
gke-fancy-cluster-default-pool-ad92506d-4fvq {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.5 XX.XX.XX.XX RUNNING
gke-fancy-cluster-default-pool-ad92506d-4zs3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.6 XX.XX.XX.XX RUNNING
Sie können Ihren Kubernetes-Cluster und die zugehörigen Informationen auch in der Cloud Console aufrufen. Scrollen Sie dazu im Navigationsmenü nach unten bis zu Kubernetes Engine und klicken Sie auf Cluster.
Es sollte der Cluster fancy-cluster zu sehen sein.
Glückwunsch! Sie haben Ihren ersten Kubernetes-Cluster erstellt.
Klicken Sie auf Fortschritt prüfen.
GKE-Cluster erstellen
Aufgabe 3: Vorhandene monolithische Anwendung bereitstellen
Da in diesem Lab das Aufteilen einer monolithischen Anwendung in Mikrodienste im Mittelpunkt steht, benötigen Sie eine betriebsbereite monolithische Anwendung.
- Führen Sie das folgende Skript aus, um diese in Ihrem GKE-Cluster bereitzustellen:
cd ~/monolith-to-microservices
./deploy-monolith.sh
Auf die monolithische Anwendung zugreifen
- Ermitteln Sie als Erstes die externe IP-Adresse der monolithischen Anwendung. Führen Sie dazu den folgenden Befehl aus:
kubectl get service monolith
Die Ausgabe sollte in etwa so aussehen:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
-
Wenn in Ihrer Ausgabe für die externe IP-Adresse <pending> angezeigt wird, warten Sie etwas und führen Sie den Befehl dann noch einmal aus.
-
Nachdem Sie die externe IP-Adresse der monolithischen Anwendung ermittelt haben, kopieren Sie diese. Rufen Sie die jeweilige URL (z. B. http://203.0.113.0) in Ihrem Browser auf, um zu prüfen, ob die monolithische Anwendung erreichbar ist.
Hinweis: Notieren Sie sich diese IP-Adresse, da sie im weiteren Verlauf noch benötigt wird. Diese Adresse kann immer mit dem obigen Befehl abgerufen werden.
Es sollte nun die Begrüßungsseite für die monolithische Website angezeigt werden. Diese Begrüßungsseite ist eine statische Seite, die später vom Mikrodienst „Frontend“ generiert wird. Die monolithische Anwendung wird jetzt vollständig in Kubernetes ausgeführt.
Klicken Sie auf Fortschritt prüfen.
Monolithische Anwendung bereitstellen
Aufgabe 4: Dienst „Orders“ zu einem Mikrodienst migrieren
Nachdem die monolithische Website nun in der GKE ausgeführt wird, können Sie mit der Aufteilung der Dienste in Mikrodienste beginnen. In der Planungsphase geht es in der Regel darum, festzulegen, welche Dienste in kleinere Blöcke aufgeteilt werden sollen. Die Unterteilung kann beispielsweise nach bestimmten Abschnitten der Anwendung, z. B. nach Geschäftsbereichen, erfolgen.
In diesem Lab erstellen Sie ein entsprechendes Beispiel und teilen dafür die Dienste nach Geschäftsbereich auf: „Orders“ für Bestellungen, „Products“ für Produkte und „Frontend“ für das Frontend. Der entsprechende Code wurde bereits für Sie migriert, sodass Sie sich ganz darauf konzentrieren können, die Dienste in der GKE bereitzustellen.
Mikrodienst „Orders“ erstellen
Der erste Dienst, der aufgeteilt werden soll, ist der Dienst „Orders“. Nutzen Sie die bereitgestellte separate Codebasis und erstellen Sie einen eigenen Docker-Container für diesen Dienst.
Docker-Container mit Cloud Build erstellen
Da die Codebasis bereits vorhanden ist, besteht der erste Schritt darin, einen Docker-Container für den Dienst „Orders“ mithilfe von Cloud Build zu erstellen.
In der Regel erfolgt dies in zwei Schritten: Zuerst wird der Docker-Container erstellt und dann wird dieser per Push in eine Registry übertragen, um das Image für den Abruf durch die GKE zu speichern. Mithilfe von Cloud Build kann mit einem einzigen Befehl der Docker-Container erstellt und das Image in die Artifact Registry übertragen werden.
Google Cloud Build komprimiert die Dateien aus dem Verzeichnis und verschiebt sie in einen Cloud Storage-Bucket. Beim Erstellen werden dann alle Dateien aus dem Bucket abgerufen und mit dem Dockerfile wird der Docker-Build-Prozess ausgeführt. Das Flag --tag wird mit dem Host als gcr.io für das Docker-Image angegeben und das erstellte Docker-Image wird in die Artifact Registry per Push übertragen.
- Führen Sie die folgenden Befehle aus, um Ihren Docker-Container zu erstellen und per Push in die Artifact Registry zu übertragen:
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
Dieser Vorgang dauert einige Minuten. Nach Abschluss ist im Terminal in etwa folgende Ausgabe zu sehen:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID CREATE_TIME DURATION SOURCE IMAGES STATUS
1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io//orders:1.0.0 SUCCESS
-
Um den Build-Verlauf aufzurufen oder den Prozess in Echtzeit zu kontrollieren, suchen Sie in der Console nach Cloud Build und klicken Sie auf das Ergebnis Cloud Build.
-
Auf der Seite Verlauf wird eine vollständige Liste Ihrer Builds angezeigt. In diesem Fall sollte nur der von Ihnen erstellte Build zu sehen sein. Wenn Sie auf die Build-ID klicken, werden alle Details zu diesem Build angezeigt, inklusive der Logausgabe.
-
Auf der Seite „Build-Details“ können Sie das erstellte Container-Image aufrufen. Klicken Sie dazu im rechten Bereich auf den Tab Ausführungsdetails. Das Image wird angezeigt.
Container in der GKE bereitstellen
Nachdem Sie einen Container für die Website erstellt und per Push in die Artifact Registry übertragen haben, können Sie ihn nun in Kubernetes bereitstellen.
Kubernetes abstrahiert Anwendungen als sogenannte Pods – Einheiten, die einen Container (bzw. eine Gruppe eng gekoppelter Container) darstellen. Der Pod ist die kleinste bereitstellbare Einheit in Kubernetes. In diesem Tutorial enthalten Pods nur Mikrodienst-Container.
Für das Deployment und die Verwaltung von Anwendungen in einem GKE-Cluster müssen Sie mit dem Kubernetes-Clusterverwaltungssystem kommunizieren. In der Regel verwenden Sie dazu das kubectl-Befehlszeilentool in Cloud Shell.
Als Erstes erstellen Sie eine Deployment-Ressource. Das Deployment verwaltet mehrere Kopien Ihrer Anwendung, sogenannte Replikate, und plant deren Ausführung auf den einzelnen Knoten im Cluster. In diesem Fall wird mit dem Deployment nur ein einziger Pod Ihrer Anwendung ausgeführt. Um dies zu gewährleisten, erstellen Deployments ein ReplicaSet. Das ReplicaSet sorgt dafür, dass immer die vorgegebene Anzahl von Replikaten ausgeführt wird.
Der unten aufgeführte Befehl kubectl create deployment weist Kubernetes an, in Ihrem Cluster das Deployment Orders mit 1 Replikat zu erstellen.
- Führen Sie den folgenden Befehl aus, um die Anwendung bereitzustellen:
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
Hinweis: Als Best Practice wird die Verwendung einer YAML-Datei empfohlen, um Änderungen des Kubernetes-Clusters (also das Erstellen oder Ändern eines Deployments oder Dienstes) zu deklarieren und ein Versionsverwaltungssystem wie GitHub zum Speichern dieser Änderungen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation zu Deployments.
Deployment prüfen
- Um zu prüfen, ob das Deployment erstellt wurde, führen Sie folgenden Befehl aus:
kubectl get all
Es kann einen Moment dauern, bis der Pod-Status „Wird ausgeführt“ angezeigt wird.
Ausgabe:
NAME READY STATUS RESTARTS AGE
pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h
pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.39.240.1 443/TCP 19d
service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/monolith 1/1 1 1 15h
deployment.apps/orders 1/1 1 1 21s
NAME DESIRED CURRENT READY AGE
replicaset.apps/monolith-779c8d95f5 1 1 1 15h
replicaset.apps/orders-5bc6969d76 1 1 1 21s
Sie sehen hier Ihr aktuelles Deployment, das replicaset mit der gewünschten Anzahl von 1 Pod und den ausgeführten Pod. Der Vorgang war also erfolgreich.
Sie können Ihre Kubernetes-Deployments auch im Navigationsmenü der Cloud Console mit der Option Kubernetes Engine > Arbeitslasten aufrufen.
GKE-Container freigeben
Sie haben Ihre Anwendung in der GKE bereitgestellt, aber bisher gibt es keine Möglichkeit, von außerhalb des Clusters darauf zuzugreifen. Standardmäßig sind die Container, die Sie in der GKE ausführen, nicht über das Internet zugänglich, da sie keine externen IP-Adressen haben. Sie müssen deshalb die Anwendung mit einer Dienstressource explizit für Traffic aus dem Internet freigeben. Ein Dienst bietet Netzwerk- und IP-Unterstützung für die Pods Ihrer Anwendung. Die GKE erstellt eine externe IP-Adresse und einen Load Balancer.
Für dieses Lab wurde die Freigabe der Dienste vereinfacht. Normalerweise wird dazu ein API-Gateway verwendet, um die öffentlichen Endpunkte zu schützen.
Als Sie den Dienst „Orders“ bereitgestellt haben, wurde er an Port 8081 intern über ein Kubernetes-Deployment freigegeben. Um diesen Dienst extern verfügbar zu machen, müssen Sie einen Kubernetes-Dienst vom Typ LoadBalancer erstellen, um Traffic vom externen Port 80 zum internen Port 8081 weiterzuleiten.
- Führen Sie den folgenden Befehl aus, um die Website für das Internet freizugeben:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
Auf den Dienst zugreifen
Die GKE weist die externe IP-Adresse der Dienstressource zu, nicht dem Deployment.
- Um die externe IP-Adresse zu ermitteln, die die GKE der Anwendung zugewiesen hat, können Sie den Dienst mit dem Befehl
kubectl get service prüfen:
kubectl get service orders
Ausgabe:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
orders 10.3.251.122 203.0.113.0 80:30877/TCP 3s
Kopieren Sie dann die externe IP-Adresse für die Anwendung. Speichern Sie sie für den nächsten Schritt, in dem Sie Ihre monolithische Anwendung ändern, um auf den neuen Dienst „Orders“ zu verweisen.
Monolithische Anwendung neu konfigurieren
Da Sie den Dienst „Orders“ aus der monolithischen Anwendung entfernt haben, müssen Sie sie ändern und auf den neuen externen Mikrodienst „Orders“ verweisen.
Beim Aufteilen einer monolithischen Anwendung entfernen Sie Teile aus dem Code einer einzelnen Codebasis für mehrere Mikrodienste und stellen die Teile gesondert bereit. Da die Mikrodienste auf einem anderen Server ausgeführt werden, können Sie auf Ihre Dienst-URLs nicht mehr mit absoluten Pfaden verweisen. Sie müssen an die Serveradresse des Mikrodienstes „Orders“ weiterleiten. Deshalb ist der monolithische Dienst eine Zeit lang nicht verfügbar, wenn die URL für den Dienst, der aufgeteilt wurde, aktualisiert wird. Dies sollten Sie berücksichtigen, wenn Sie bei der Migration der Mikrodienste den Übergang Ihrer Mikrodienste und der monolithischen Anwendung in die Produktion planen.
Sie müssen Ihre Konfigurationsdatei in der monolithischen Anwendung aktualisieren, um auf die IP-Adresse des neuen Mikrodienstes „Orders“ zu verweisen.
- Verwenden Sie den
nano-Editor, um die lokale URL durch die IP-Adresse des Mikrodienstes „Orders“ zu ersetzen:
cd ~/monolith-to-microservices/react-app
nano .env.monolith
Ihre Datei sollte im Editor in etwa so aussehen:
REACT_APP_ORDERS_URL=/service/orders
REACT_APP_PRODUCTS_URL=/service/products
- Geben Sie für
REACT_APP_ORDERS_URL die IP-Adresse des Mikrodienstes „Orders“ zum Ersetzen der lokalen URL in folgender Weise an:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders
REACT_APP_PRODUCTS_URL=/service/products
-
Drücken Sie STRG + O, die EINGABETASTE und STRG + X, um die Datei im nano-Editor zu speichern.
-
Rufen Sie zum Testen des neuen Mikrodienstes die URL auf, die Sie soeben in der Datei angegeben haben. Die Webseite sollte eine JSON-Antwort aus Ihrem Mikrodienst „Orders“ zurückgeben.
-
Als Nächstes erstellen Sie das monolithische Frontend neu und wiederholen den Build-Prozess für den Container der monolithischen Anwendung. Anschließend stellen Sie ihn im GKE-Cluster erneut bereit.
npm run build:monolith
- Erstellen Sie den Docker-Container mit Cloud Build:
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
- Stellen Sie den Container in der GKE bereit:
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
- Prüfen Sie, ob die Anwendung nun den Mikrodienst „Orders“ aufruft. Öffnen Sie dazu die monolithische Anwendung in Ihrem Browser und dort die Seite „Orders“. Alle Bestell-IDs müssen wie in der folgenden Abbildung gezeigt mit dem Suffix -MICROSERVICE enden:

- Klicken Sie auf Fortschritt prüfen.
Dienst „Orders“ zu einem Mikrodienst migrieren
Aufgabe 5: Dienst „Products“ zu einem Mikrodienst migrieren
Neuen Mikrodienst „Products“ erstellen
Jetzt migrieren Sie den Dienst „Products“, um die Dienste weiter aufzuteilen. Dazu wiederholen Sie den obigen Vorgang für diesen Dienst. Führen Sie die folgenden Befehle aus, um einen Docker-Container zu erstellen, diesen bereitzustellen und ihn dann über einen Kubernetes-Dienst freizugeben.
- Erstellen Sie den Docker-Container mit Cloud Build:
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
- Stellen Sie den Container in der GKE bereit:
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
- Geben Sie den GKE-Container frei:
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
- Geben Sie die öffentliche IP-Adresse des Dienstes „Products“ wie zuvor für den Dienst „Orders“ frei:
kubectl get service products
Ausgabe:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Diese IP-Adresse verwenden Sie im nächsten Schritt, wenn Sie die monolithische Anwendung neu konfigurieren, um auf den neuen Mikrodienst „Products“ zu verweisen.
Monolithische Anwendung neu konfigurieren
- Ersetzen Sie im
nano-Editor die lokale URL durch die IP-Adresse des neuen Mikrodienstes „Products“:
cd ~/monolith-to-microservices/react-app
nano .env.monolith
Ihre Datei sollte im Editor in etwa so aussehen:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders
REACT_APP_PRODUCTS_URL=/service/products
- Geben Sie für
REACT_APP_PRODUCTS_URL die IP-Adresse des Mikrodienstes „Products“ zum Ersetzen der lokalen URL so an:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders
REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
-
Drücken Sie STRG + O, die EINGABETASTE und STRG + X, um die Datei zu speichern.
-
Rufen Sie zum Testen des neuen Mikrodienstes die URL auf, die Sie soeben in der Datei angegeben haben. Die Webseite sollte eine JSON-Antwort aus dem Mikrodienst „Products“ zurückgeben.
-
Als Nächstes erstellen Sie das monolithische Frontend neu und wiederholen den Build-Prozess für den Container der monolithischen Anwendung. Anschließend stellen Sie ihn im GKE-Cluster erneut bereit. Führen Sie dazu die folgenden Befehle aus.
-
Erstellen Sie die monolithischen Konfigurationsdateien neu:
npm run build:monolith
- Erstellen Sie den Docker-Container mit Cloud Build:
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
- Stellen Sie den Container in der GKE bereit:
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
- Prüfen Sie, ob die Anwendung nun den Mikrodienst „Products“ aufruft. Öffnen Sie dazu die monolithische Anwendung in Ihrem Browser und dort die Seite „Products“. Alle Produktnamen sollten das Präfix „MS-“ enthalten, wie in der folgenden Abbildung dargestellt:

- Klicken Sie auf Fortschritt prüfen.
Dienst „Products“ zu einem Mikrodienst migrieren
Aufgabe 6: Dienst „Frontend“ zu einem Mikrodienst migrieren
Der letzte Schritt bei der Migration ist das Übertragen des Frontend-Codes an einen Mikrodienst und das Abschalten der monolithischen Anwendung. Damit haben Sie die monolithische Anwendung erfolgreich zu einer Mikrodienstarchitektur migriert.
Neuen Mikrodienst „Frontend“ erstellen
Wiederholen Sie die letzten beiden Schritte, um den neuen Mikrodienst „Frontend“ zu erstellen.
Zuvor haben Sie beim Neuerstellen der monolithischen Anwendung die Konfiguration mit einem Verweis auf die monolithische Anwendung aktualisiert. Für den Mikrodienst „Frontend“ wird jetzt die gleiche Konfiguration verwendet.
- Führen Sie die folgenden Befehle aus, um die Konfigurationsdateien der Mikrodienst-URL in die Codebasis des Mikrodienstes „Frontend“ zu kopieren:
cd ~/monolith-to-microservices/react-app
cp .env.monolith .env
npm run build
-
Wenn dieser Vorgang abgeschlossen ist, gehen Sie vor, wie bei den vorherigen Schritten. Führen Sie die folgenden Befehle aus, um einen Docker-Container zu erstellen, diesen bereitzustellen und ihn dann über einen Kubernetes-Dienst freizugeben.
-
Erstellen Sie den Docker-Container mit Google Cloud Build:
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
- Stellen Sie den Container in der GKE bereit:
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
- Geben Sie den GKE-Container frei:
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
- Klicken Sie auf Fortschritt prüfen.
Dienst „Frontend“ zu einem Mikrodienst migrieren
Monolithische Anwendung löschen
Nachdem nun alle Dienste als Mikrodienste ausgeführt werden, können Sie die monolithische Anwendung löschen. Bei einer tatsächlichen Migration wären auch DNS-Änderungen usw. erforderlich, damit die vorhandenen Domainnamen auf die neuen Frontend-Mikrodienste für die Anwendung verweisen.
- Führen Sie zum Löschen der monolithischen Anwendung folgende Befehle aus:
kubectl delete deployment monolith
kubectl delete service monolith
Testen Sie Ihre Arbeit
Damit alles wie gewünscht funktioniert, sollte die alte IP-Adresse Ihres monolithischen Dienstes nicht mehr gültig sein und die neue IP-Adresse des Dienstes „Frontend“ sollte die neue Anwendung hosten.
- Zum Aufrufen einer Liste aller Dienste und IP-Adressen führen Sie den folgenden Befehl aus:
kubectl get services
Die Ausgabe sollte in etwa so aussehen:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m
kubernetes ClusterIP 10.39.240.1 443/TCP 18d
orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m
products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
Kopieren Sie dann die externe IP-Adresse für die Anwendung. Rufen Sie die jeweilige URL (z. B. http://203.0.113.0) in Ihrem Browser auf, um zu prüfen, ob Ihr Frontend abrufbar ist. Die Website sollte genauso angezeigt werden wie vor der Aufteilung der monolithischen Anwendung in Mikrodienste.
Das wars! Sie haben das Lab erfolgreich abgeschlossen.
Sie haben Ihre monolithische Anwendung in Mikrodienste aufgeteilt und in Google Kubernetes Engine bereitgestellt.
Weitere Ressourcen
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.
Handbuch zuletzt aktualisiert am 26. April 2024
Lab zuletzt am 20. September 2023 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.