1. Einführung
Was spricht dafür, eine monolithische Anwendung zu einer Mikrodienstarchitektur zu migrieren? Das Aufteilen der Features einer Anwendung auf Mikrodienste hat die folgenden Vorteile, wovon die meisten darauf beruhen, dass die Mikrodienste lose miteinander verknüpft 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 führen wir Mikrodienste in Google Kubernetes Engine (GKE) aus. 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.
In diesem Lab stellen wir eine monolithische Anwendung in einem Google Kubernetes Engine-Cluster bereit und teilen sie dann in Mikrodienste auf.
Diagramm der Architektur unserer Mikrodienste
Als Erstes teilen wir die monolithische Anwendung schrittweise in drei Mikrodienste auf. Die Mikrodienste sind „Orders“, „Products“ und „Frontend“. Wir erstellen mit Cloud Build ein Docker-Image für jeden Mikrodienst, das wir über Cloud Shell auslösen. Anschließend stellen wir die Mikrodienste in Google Kubernetes Engine (GKE) mit einem Kubernetes-Dienst vom Typ LoadBalancer bereit und geben sie frei. Wir führen dies für alle Dienste aus und refaktorieren sie dabei gleichzeitig aus unserer 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
Voraussetzungen
- Ein Google Cloud Platform-Konto mit Administratorzugriff zum Erstellen von Projekten oder eines Projekts mit der Rolle "Projektinhaber"
- Grundlegende Kenntnisse von Docker und Kubernetes
2. Umgebung einrichten
Umgebung zum selbstbestimmten Lernen einrichten
Wenn Sie noch kein Google-Konto (Gmail oder Google Apps) haben, müssen Sie eines erstellen. Melden Sie sich in der Google Cloud Platform Console ( console.cloud.google.com) an und erstellen Sie ein neues Projekt:
Notieren Sie sich die Projekt-ID, also den projektübergreifend nur einmal vorkommenden Namen eines Google Cloud-Projekts. Der oben angegebene Name ist bereits vergeben und kann leider nicht mehr verwendet werden. Sie wird später in diesem Codelab als PROJECT_ID bezeichnet.
Als Nächstes müssen Sie die Abrechnung in der Entwicklerkonsole aktivieren, um Google Cloud-Ressourcen verwenden zu können, und die Container Engine API aktivieren.
Dieses Codelab sollte Sie nicht mehr als ein paar Dollar kosten, aber es könnte mehr sein, wenn Sie sich für mehr Ressourcen entscheiden oder wenn Sie sie laufen lassen (siehe Abschnitt „Bereinigen“ am Ende dieses Dokuments). Die Preise für Google Kubernetes Engine sind hier dokumentiert.
Neuen Nutzern der Google Cloud Platform steht eine kostenlose Testversion mit einem Guthaben von 300$ zur Verfügung.
Google Cloud Shell
Während Sie Google Cloud und Kubernetes von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.
Diese Debian-basierte virtuelle Maschine verfügt über alle Entwicklungstools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Für dieses Codelab benötigen Sie also nur einen Browser (es funktioniert auch auf einem Chromebook).
- Klicken Sie zum Aktivieren von Cloud Shell in der Cloud Console einfach auf Cloud Shell aktivieren
. Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern.
Sobald die Verbindung mit der Cloud Shell hergestellt ist, sehen Sie, dass Sie bereits authentifiziert sind und für das Projekt schon Ihre PROJECT_ID eingestellt ist.
gcloud auth list
Befehlsausgabe
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Befehlsausgabe
[core] project = <PROJECT_ID>
Wenn das Projekt aus irgendeinem Grund nicht festgelegt ist, führen Sie einfach den folgenden Befehl aus:
gcloud config set project <PROJECT_ID>
Suchst du nach deinem PROJECT_ID? Sehen Sie nach, welche ID Sie in den Einrichtungsschritten verwendet haben, oder suchen Sie sie im Cloud Console-Dashboard:
In Cloud Shell werden auch einige Umgebungsvariablen standardmäßig festgelegt, die für zukünftige Befehle nützlich sein können.
echo $GOOGLE_CLOUD_PROJECT
Befehlsausgabe
<PROJECT_ID>
- Legen Sie zum Schluss die Standardzone und die Projektkonfiguration fest.
gcloud config set compute/zone us-central1-f
Sie können verschiedene Zonen auswählen. Weitere Informationen finden Sie unter Regionen und Zonen.
3. Quell-Repository klonen
Wir 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. Wir installieren auch die NodeJS-Abhängigkeiten, damit wir die monolithische Anwendung testen können, bevor sie bereitgestellt wird. Die Ausführung des Skripts kann einige Minuten dauern.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
Dadurch wird unser Github-Repository geklont, in das Verzeichnis gewechselt und die zum lokalen Ausführen unserer Anwendung erforderlichen Abhängigkeiten installiert. Die Ausführung des Skripts kann einige Minuten dauern.
4. 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
Jetzt können wir den Cluster erstellen. 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
Es kann einige Minuten dauern, bis der Cluster erstellt ist. Führen Sie nach Abschluss des Befehls den folgenden Befehl aus, um die drei Worker-VM-Instanzen des Clusters aufzurufen:
gcloud compute instances list
Ausgabe:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
Sie können Ihren Kubernetes-Cluster und die zugehörigen Informationen auch in der Google Cloud Console aufrufen. Klicken Sie links oben auf die Menüschaltfläche, scrollen Sie nach unten zu „Kubernetes Engine“ und klicken Sie auf „Cluster“. Es sollte der Cluster fancy-cluster zu sehen sein.
Das wars! Sie haben Ihren ersten Kubernetes-Cluster erstellt.
5. 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 eine monolithische Anwendung in unserem GKE-Cluster für dieses Lab 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
HINWEIS: Hierfür muss ein externer Load Balancer und eine IP-Adresse bereitgestellt werden. Das kann einige Zeit dauern. Wenn in Ihrer Ausgabe für die externe IP-Adresse
<pending> Warte einige Minuten und versuche es dann noch einmal.
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 abrufbar ist.
Es sollte nun die Begrüßungsseite für die monolithische Website wie in der Abbildung oben 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.
6. Dienst „Orders“ zu einem Mikrodienst migrieren
Die bestehende monolithische Website wird jetzt in GKE ausgeführt und wir können die Dienste in Mikrodienste umwandeln. Normalerweise sollte in der Planungsphase entschieden werden, welche Dienste in kleinere Einheiten aufgeteilt werden. Die Unterteilung richtet sich meistens nach bestimmten Teilen der Anwendung, beispielsweise dem Geschäftsbereich. Zu Demonstrationszwecken haben wir ein einfaches Beispiel erstellt und die einzelnen Dienste nach Geschäftsbereich aufgeteilt: „Orders“ für Bestellungen, „Products“ für Produkte und „Frontend“ für das Frontend. Der entsprechende Code wurde bereits migriert, sodass wir uns ganz darauf konzentrieren können, die Dienste in der GKE bereitzustellen.
Neuen Mikrodienst „Orders“ erstellen
Der erste Dienst, den wir aufteilen, ist der Dienst „Orders“. Wir nutzen die bereitgestellte separate Codebasis und erstellen einen eigenen Docker-Container für diesen Dienst.
Docker-Container mit Google Cloud Build erstellen
Da wir die Codebasis bereits für Sie migriert haben, besteht der erste Schritt darin, einen Docker-Container für den Dienst „Orders“ mithilfe von Google Cloud Build zu erstellen.
Normalerweise sind dafür zwei Schritte erforderlich. Zunächst muss ein Docker-Container erstellt und dann per Push in eine Registry übertragen werden, um das Image für GKE zum Abruf zu speichern. Diesen Vorgang können Sie vereinfachen und mit einem einzigen Befehl den Docker-Container mit Google Cloud Build erstellen sowie das Image in die Google Cloud Container Registry platzieren. Um das Image zu erstellen und in die Container Registry zu übertragen, müssen wir also nur einen Befehl eingeben. Informationen zum manuellen Erstellen und Übertragen eines Dockerfile finden Sie unter Kurzanleitung für Container Registry.
Google Cloud Build komprimiert die Dateien aus dem Verzeichnis und verschiebt sie in einen Google Cloud Storage-Bucket. Beim Erstellen werden dann alle Dateien aus dem Bucket abgerufen und mit dem Dockerfile wird der Docker-Build-Prozess ausgeführt. Da wir das Flag --tag mit dem Host als gcr.io für das Docker-Image angegeben haben, wird das fertige Docker-Image per Push in die Google Cloud Container Registry übertragen.
Führen Sie die folgenden Befehle aus, um Ihren Docker-Container zu erstellen und per Push in die Google Container Registry zu übertragen:
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
Dieser Prozess dauert einige Minuten. Nach Abschluss ist im Terminal in etwa folgende Ausgabe enthalten:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
Um den Build-Verlauf aufzurufen oder den Prozess in Echtzeit zu kontrollieren, können Sie die Google Cloud Console aufrufen. Klicken Sie links oben auf die Menüschaltfläche und scrollen Sie nach unten zu „Tools“ → „Cloud Build“. Klicken Sie dann auf „Verlauf“. Im Verlauf wird eine vollständige Liste Ihrer bisherigen Builds angezeigt. In diesem Fall sollte nur der von Ihnen soeben 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 Abschnitt „Build-Informationen“ auf den Image-Namen.
Container in GKE bereitstellen
Nachdem wir einen Container für unsere Website erstellt und per Push in die Google Container Registry übertragen haben, können wir ihn 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.
Zuerst erstellen wir 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 in 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 gezeigte Befehl kubectl create deployment bewirkt, dass Kubernetes ein Deployment namens orders in Ihrem Cluster mit 1 Replikat erstellt.
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
Deployment prüfen
Um zu prüfen, ob das Deployment erstellt wurde, führen Sie folgenden Befehl aus. Es kann einige Zeit dauern, bis der Pod-Status „Running“ lautet:
kubectl get all
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 <none> 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
Diese Ausgabe zeigt uns mehrere Dinge. Wir sehen hier unser Deployment als aktuelles Deployment, unser ReplicaSet mit der gewünschten Anzahl von 1 Pod und den ausgeführten Pod. Der Vorgang war also erfolgreich.
Geben Sie den GKE-Container frei:
Wir haben nun unsere Anwendung in GKE bereitgestellt, es gibt aber keine Möglichkeit, darauf außerhalb des Clusters zuzugreifen. Standardmäßig sind die Container, die Sie in 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. GKE erstellt eine externe IP-Adresse und einen (kostenpflichtigen) Load-Balancer für Ihre Anwendung.
Als wir 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 wir einen Kubernetes-Dienst vom Typ LoadBalancer erstellen, um Traffic vom externen Port 80 zum internen Port 8081 für den Dienst „Orders“ 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
GKE weist die externe IP-Adresse der Dienstressource zu, nicht dem Deployment. Wenn Sie die externe IP-Adresse ermitteln möchten, die GKE für Ihre Anwendung bereitgestellt 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 3d
Kopieren Sie dann die externe IP-Adresse für die Anwendung. Speichern Sie sie für den nächsten Schritt, in dem wir unsere monolithische Anwendung ändern, um auf den neuen Dienst „Orders“ zu verweisen.
Monolithische Anwendung neu konfigurieren
Da wir den Dienst „Orders“ aus der monolithischen Anwendung entfernt haben, müssen wir sie ändern und auf den neuen externen Mikrodienst „Orders“ verweisen.
Beim Aufteilen einer monolithischen Anwendung entfernen wir Teile aus dem Code einer einzelnen Codebasis für mehrere Mikrodienste und stellen die Teile gesondert bereit. Da der Mikrodienst auf einem anderen Server ausgeführt wird, können wir auf unsere Dienst-URLs nicht mehr mit absoluten Pfaden verweisen. Wir müssen an die neue Serveradresse unseres 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.
Wir müssen unsere Konfigurationsdatei in der monolithischen Anwendung aktualisieren, um auf die IP-Adresse des neuen Mikrodienstes „Orders“ zu verweisen. Ersetzen Sie im Nano-Editor die lokale URL durch die IP-Adresse unseres neuen Mikrodienstes „Orders“. Führen Sie den folgenden Befehl aus, um
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 CTRL+O, ENTER und dann CTRL+X, um die Datei im nano-Editor zu speichern.
Rufen Sie zum Testen des neuen Mikrodienstes die URL auf, die Sie soeben in dieser Datei angegeben haben. Die Webseite sollte eine JSON-Antwort aus unserem Mikrodienst „Orders“ zurückgeben.
Als Nächstes müssen wir das monolithische Frontend neu erstellen und den Build-Prozess für den Container der monolithischen Anwendung wiederholen. Anschließend stellen wir ihn in unserem GKE-Cluster erneut bereit. Führen Sie zum Abschließen dieser Schritte die folgenden Befehle aus.
Erstellen Sie die monolithischen Konfigurationsdateien neu:
npm run build:monolith
Docker-Container mit Google Cloud Build erstellen
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
Container in GKE bereitstellen
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:
7. Dienst "Products" zu einem Mikrodienst migrieren
Neuen Mikrodienst „Products“ erstellen
Jetzt migrieren wir den Dienst „Products“, um die Dienste weiter aufzuteilen. Wir gehen genauso vor wie im vorherigen Schritt. Führen Sie die folgenden Befehle aus, um einen Docker-Container zu erstellen, diesen bereitzustellen und ihn dann über einen Kubernetes-Dienst freizugeben.
Docker-Container mit Google Cloud Build erstellen
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
Container in GKE bereitstellen
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 unserer Products-Dienste wie zuvor für den Dienst „Orders“ mit dem folgenden Befehl 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
Speichern Sie die IP-Adresse für den nächsten Schritt, in dem wir unsere 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 CTRL+O, ENTER und dann CTRL+X, um die Datei im nano-Editor zu speichern.
Rufen Sie zum Testen des neuen Mikrodienstes die URL auf, die Sie soeben in dieser Datei angegeben haben. Die Webseite sollte eine JSON-Antwort aus unserem Mikrodienst „Products“ zurückgeben.
Als Nächstes müssen wir das monolithische Frontend neu erstellen und den Build-Prozess für den Container der monolithischen Anwendung wiederholen. Anschließend stellen wir ihn in unserem GKE-Cluster erneut bereit. Führen Sie zum Abschließen dieser Schritte die folgenden Befehle aus.
Erstellen Sie die monolithischen Konfigurationsdateien neu:
npm run build:monolith
Docker-Container mit Google Cloud Build erstellen
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
Container in GKE bereitstellen
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:
8. 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 wir unsere 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 wir beim Neuerstellen der monolithischen Anwendung die Konfiguration mit einem Verweis auf die monolithische Anwendung aktualisiert. Jetzt müssen wir dieselbe Konfiguration für den Mikrodienst „Frontend“ verwenden. 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 wir 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.
Docker-Container mit Google Cloud Build erstellen
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
Container in GKE bereitstellen
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
Monolithische Anwendung löschen
Nachdem nun alle Dienste als Mikrodienste ausgeführt werden, können wir die monolithische Anwendung löschen. Beachten Sie, dass mit einer tatsächlichen Migration u. a. auch DNS-Änderungen verbunden sind, um vorhandene Domainnamen für den Verweis auf den neuen Mikrodienst "Frontend" für die Anwendung abzurufen. 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. Verwenden Sie den folgenden Befehl, um eine Liste aller Dienste und IP-Adressen aufzurufen:
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 <none> 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.
9. Bereinigen
Wenn Sie fertig sind, können Sie alle ausgeführten Aktivitäten am einfachsten bereinigen, indem Sie das Projekt löschen. Wenn Sie das Projekt löschen, werden alle Ressourcen gelöscht, die in diesem Codelab erstellt wurden. So werden unerwartete wiederkehrende Gebühren vermieden. Führen Sie den folgenden Befehl in Cloud Shell aus. Dabei ist PROJECT_ID die vollständige Projekt-ID und nicht nur der Projektname.
gcloud projects delete [PROJECT_ID]
Bestätigen Sie das Löschen, indem Sie „Y“ eingeben, wenn Sie dazu aufgefordert werden.
10. Glückwunsch!
Sie haben Ihre monolithische Anwendung in Mikrodienste aufgeteilt und in Google Kubernetes Engine bereitgestellt.
Nächste Schritte
Weitere Informationen zu Kubernetes finden Sie in den folgenden Codelabs:
- Website in Google Kubernetes Engine bereitstellen, skalieren und aktualisieren
- Mit Node.js auf Kubernetes einen Slack-Bot erstellen
- Continuous Delivery in Kubernetes mithilfe von Spinnaker
- Java-Anwendung in Kubernetes in der Google Kubernetes Engine bereitstellen
Zusätzliche Ressourcen
- Docker: https://docs.docker.com/
- Kubernetes: https://kubernetes.io/docs/home/
- Google Kubernetes Engine: https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build: https://cloud.google.com/cloud-build/docs/
- Google Container Registry: https://cloud.google.com/container-registry/docs/
- Monolithische Anwendungen zu Mikrodiensten migrieren: https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke