1. Einführung
Was spricht dafür, eine monolithische Anwendung zu einer Mikrodienstarchitektur zu migrieren? Das Aufteilen einer Anwendung in Mikrodienste hat folgende Vorteile: Die meisten davon sind darauf zurückzuführen, dass 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 einem Sicherheitsproblem 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 vorhandene monolithische Anwendung in einem Google Kubernetes Engine-Cluster bereit und unterteilen sie dann in Mikrodienste.
Diagramm der Architektur unserer Mikrodienste
Zunächst unterteilen wir unsere monolithische Anwendung in drei Mikrodienste, nacheinander. Zu den Mikrodiensten gehören „Orders“, „Products“ und „Frontend“. Wir erstellen mit Cloud Build ein Docker-Image für jeden Mikrodienst, das wir in Cloud Shell auslösen. Anschließend stellen wir unsere Mikrodienste in der Google Kubernetes Engine (GKE) mit dem Kubernetes-Diensttyp LoadBalancer bereit und geben sie frei. Das machen wir für alle Dienste und refaktorieren sie gleichzeitig aus unserer monolithischen Anwendung. Während des gesamten Prozesses werden sowohl die monolithische Anwendung als auch die Mikrodienste ausgeführt, bis die monolithische Anwendung gelöscht ist.
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 in diesem Codelab später als PROJECT_ID bezeichnet.
Als Nächstes müssen Sie in der Developers Console die Abrechnung aktivieren, um Google Cloud-Ressourcen nutzen zu können und die Container Engine API zu aktivieren.
Dieses Codelab sollte nicht mehr als ein paar Euro kosten. Wenn Sie sich jedoch dazu entschließen, mehr Ressourcen zu verwenden oder diese weiter auszuführen (siehe Abschnitt „Bereinigen“ am Ende dieses Dokuments), Die Preise für Google Kubernetes Engine sind hier dokumentiert.
Neue Nutzer der Google Cloud Platform haben Anspruch auf eine kostenlose Testversion mit 300$Guthaben.
Google Cloud Shell
Sie können Google Cloud und Kubernetes über Ihren Laptop remote bedienen. In diesem Codelab verwenden wir jedoch Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.
Diese Debian-basierte virtuelle Maschine verfügt über alle erforderlichen Entwicklungstools. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und wird in Google Cloud ausgeführt. Dadurch werden die Netzwerkleistung und die Authentifizierung erheblich verbessert. Für dieses Codelab benötigen Sie also nur einen Browser – ja, er funktioniert auf Chromebooks.
- Klicken Sie einfach auf Cloud Shell aktivieren
, um Cloud Shell über die Cloud Console zu aktivieren. Die Bereitstellung und Verbindung mit der Umgebung dauert einen Moment.
Sobald Sie mit Cloud Shell verbunden sind, sollten Sie sehen, dass Sie bereits authentifiziert sind und dass das Projekt bereits auf Ihre PROJECT_ID eingestellt ist.
gcloud auth list
Befehlsausgabe
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Befehlsausgabe
[core] project = <PROJECT_ID>
Sollte das Projekt aus irgendeinem Grund nicht eingerichtet sein, geben Sie einfach den folgenden Befehl ein:
gcloud config set project <PROJECT_ID>
Du suchst dein Gerät (PROJECT_ID)? Sehen Sie nach, welche ID Sie bei den Einrichtungsschritten verwendet haben, oder rufen Sie sie im Dashboard der Cloud Console auf:
Cloud Shell legt außerdem standardmäßig einige Umgebungsvariablen fest, die bei der Ausführung zukünftiger Befehle nützlich sein können.
echo $GOOGLE_CLOUD_PROJECT
Befehlsausgabe
<PROJECT_ID>
- Legen Sie schließlich 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 einer imaginären E-Commerce-Website mit einer einfachen Begrüßungsseite, einer Produktseite und einer Seite mit Bestellverlauf. Für die Anwendung muss nur die Quelle aus unserem Git-Repository geklont werden. Wir können uns also darauf konzentrieren, sie in Mikrodienste aufzuteilen und in 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. Außerdem installieren wir die NodeJS-Abhängigkeiten, damit wir unsere monolithische Anwendung vor der Bereitstellung testen können. 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 Abhängigkeiten installiert, die zum lokalen Ausführen der Anwendung erforderlich sind. Die Ausführung des Skripts kann einige Minuten dauern.
4. GKE-Cluster erstellen
Sie haben jetzt Ihre funktionierende Entwicklungsumgebung. Jetzt benötigen wir einen Kubernetes-Cluster, um unsere monolithische Anwendung und schließlich unsere Mikrodienste bereitzustellen. Bevor wir einen Cluster erstellen können, müssen wir überprüfen, ob die richtigen APIs aktiviert sind. Führen Sie den folgenden Befehl aus, um die Container API zu aktivieren und Google Kubernetes Engine zu verwenden:
gcloud services enable container.googleapis.com
Jetzt können wir den Cluster erstellen. Führen Sie den folgenden Befehl aus, um einen GKE-Cluster namens 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 sich die drei Worker-VM-Instanzen des Clusters anzeigen zu lassen:
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 ansehen. 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
In diesem Lab geht es darum, eine monolithische Anwendung in Mikrodienste aufzuteilen. Deshalb müssen wir eine monolithische Anwendung zum Laufen bringen. Führen Sie das folgende Skript aus, um für dieses Lab eine monolithische Anwendung in unserem GKE-Cluster bereitzustellen:
cd ~/monolith-to-microservices ./deploy-monolith.sh
Zugriff auf die Monolithische Anwendung
Führen Sie den folgenden Befehl aus, um die externe IP-Adresse für die monolithische Anwendung zu ermitteln.
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: Dazu müssen ein externer Load-Balancer und eine IP-Adresse bereitgestellt werden. Es dauert daher einige Zeit. Wenn die externe IP-Adresse in der Ausgabe
<pending> Warten Sie einige Minuten und versuchen Sie es dann noch einmal.
Nachdem Sie die externe IP-Adresse für die monolithische 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. „Orders“ zum Mikrodienst migrieren
Die vorhandene monolithische Website läuft jetzt in der GKE. Jetzt können wir jeden Dienst in einen Mikrodienst aufteilen. In der Planungsphase geht es typischerweise um die Entscheidung, welche kleineren Blöcke als Mikrodienste erstellt werden sollen. Die Unterteilung kann beispielsweise nach bestimmten Teilen der Anwendung, z. B. Geschäftsbereiche, erfolgen. Zu Demonstrationszwecken haben wir ein einfaches Beispiel erstellt und jeden Dienst nach Unternehmensdomain, Bestellungen, Produkten und Frontend aufgeschlüsselt. Der Code wurde bereits migriert und wir werden uns auf das Erstellen und Bereitstellen der Dienste in der Google Kubernetes Engine (GKE) konzentrieren.
Mikrodienst „Neue Aufträge erstellen“
Der erste Dienst, den wir uns ansehen, ist der Dienst „Orders“. Wir nutzen die bereitgestellte separate Codebasis und erstellen einen separaten 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, mit Google Cloud Build einen Docker-Container für unseren Order-Dienst 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. Aber wir können das Leben vereinfachen, indem wir mit Google Cloud Build den Docker-Container erstellen und das Image mit einem einzigen Befehl in die Google Cloud Container Registry einfügen. Dadurch können wir unser Image mit einem einzigen Befehl erstellen und in die Container Registry verschieben. 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 resultierende 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
In der Google Cloud Console können Sie Ihren Build-Verlauf ansehen oder den Prozess in Echtzeit verfolgen. Klicken Sie links oben auf die Menüschaltfläche, scrollen Sie nach unten zu „Tools“ → „Cloud Build“ und klicken Sie 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 mit den Build-Details können Sie das erstellte Container-Image aufrufen. Klicken Sie dazu im Abschnitt mit den 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 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 dieser Anleitung enthält jeder Pod nur Ihren 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 auf dem Deployment nur ein 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 folgende kubectl create deployment-Befehl bewirkt, dass Kubernetes ein Deployment mit dem Namen 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
Führen Sie den folgenden Befehl aus, um zu prüfen, ob das Deployment erfolgreich erstellt wurde. Es kann einen Moment dauern, bis der Pod-Status „Wird ausgeführt“ angezeigt wird:
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 verschiedene Dinge. Sie sehen unser Deployment, das aktuell ist, unser ReplicaSet mit der gewünschten Pod-Anzahl von 1 und unseren Pod, der ausgeführt wird. 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 unseren Orders-Dienst bereitgestellt haben, wurde er intern über ein Kubernetes-Deployment auf Port 8081 verfügbar gemacht. Um diesen Dienst extern verfügbar zu machen, müssen Sie einen Kubernetes-Dienst vom Typ LoadBalancer erstellen, um Traffic für den Orders-Dienst von Port 80 extern 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
GKE weist die externe IP-Adresse der Dienstressource zu, nicht dem Deployment. Wenn Sie wissen möchten, welche externe IP-Adresse GKE Ihrer Anwendung zugewiesen hat, können Sie den Dienst mit dem Befehl „kubectl get service“ überprü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 ihn für den nächsten Schritt, wenn wir unsere monolithische Anwendung so ändern, dass sie auf unseren neuen Orders-Dienst verweist.
Monolithische Anwendung neu konfigurieren
Da wir den Dienst „Orders“ aus der monolithischen Anwendung entfernt haben, müssen wir sie so ändern, dass sie auf den neuen externen Mikrodienst „Orders“ verweist.
Beim Aufschlüsseln einer monolithischen Anwendung werden Teile des Codes von einer einzelnen Codebasis in mehrere Teile entfernt und separat bereitgestellt. Da der Mikrodienst auf einem anderen Server ausgeführt wird, können wir unsere Dienst-URLs nicht mehr als absolute Pfade referenzieren. Wir benötigen eine Weiterleitung zur neuen Serveradresse des Mikrodienstes „Order“. Beachten Sie, dass der monolithische Dienst in diesem Fall einige Zeit nicht verfügbar ist, um die URL für jeden Dienst zu aktualisieren, der aufgeschlüsselt wurde. Dies sollten Sie berücksichtigen, wenn Sie den Übergang Ihrer Mikrodienste und der monolithischen Anwendung in die Produktion bei der Migration der Mikrodienste planen.
Wir müssen die Konfigurationsdatei in der monolithischen Anwendung so aktualisieren, dass sie auf die IP-Adresse des neuen Mikrodienstes „Orders“ verweist. Ersetzen Sie im nano-Editor die lokale URL durch die IP-Adresse des neuen Mikrodienstes „Orders“. Führen Sie den folgenden Befehl aus, um die
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
Ersetzen Sie REACT_APP_ORDERS_URL durch die IP-Adresse des Mikrodienstes „Orders“ und geben Sie dabei Folgendes ein:
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.
Sie können Ihren neuen Mikrodienst testen, indem Sie die URL aufrufen, die Sie gerade in dieser Datei festgelegt haben. Die Webseite sollte eine JSON-Antwort von unserem Mikrodienst „Orders“ zurückgeben.
Als Nächstes müssen Sie das monolithische Front-End neu erstellen und den Build-Prozess wiederholen, um den Container für die monolithische Anwendung zu erstellen und ihn noch einmal im GKE-Cluster bereitzustellen. 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
Sie können überprüfen, ob Ihre Anwendung jetzt den neuen Mikrodienst „Orders“ verwendet, indem Sie die monolithische Anwendung in Ihrem Browser und die Seite „Orders“ aufrufen. Alle Bestell-IDs müssen wie in der folgenden Abbildung gezeigt mit dem Suffix -MICROSERVICE enden:
7. Dienst "Products" zu einem Mikrodienst migrieren
Mikrodienst „Produkte erstellen“
Wir können unsere Dienste weiter ausbauen, indem wir den Dienst „Produkte“ als Nächstes migrieren. Wir gehen wie im vorherigen Schritt vor. 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
Ermitteln Sie die öffentliche IP-Adresse unserer „Products“-Dienste genauso wie für den Dienst „Orders“ mit dem folgenden Befehl:
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, wenn wir die monolithische Anwendung neu konfigurieren, sodass sie auf den neuen Mikrodienst „Products“ verweist.
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
Ersetzen Sie REACT_APP_PRODUCTS_URL durch die IP-Adresse des Mikrodienstes „Produkt“ und geben Sie dabei Folgendes ein:
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.
Sie können den neuen Mikrodienst testen, indem Sie die URL aufrufen, die Sie gerade in dieser Datei festgelegt haben. Die Webseite sollte eine JSON-Antwort von unserem Mikrodienst „Products“ zurückgeben.
Als Nächstes müssen Sie das monolithische Front-End neu erstellen und den Build-Prozess wiederholen, um den Container für die monolithische Anwendung zu erstellen und ihn noch einmal im GKE-Cluster bereitzustellen. 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
Sie können überprüfen, ob Ihre Anwendung jetzt den neuen Mikrodienst „Products“ verwendet, indem Sie die monolithische Anwendung in Ihrem Browser und die Seite „Products“ aufrufen. Alle Produktnamen sollten das Präfix "MS-" enthalten, wie in der folgenden Abbildung dargestellt:
8. Front-End zu Mikrodienst migrieren
Der letzte Schritt im Migrationsprozess besteht darin, den Front-End-Code in einen Mikrodienst zu verschieben und die monolithische Anwendung herunterzufahren. Damit haben wir unsere monolithische Anwendung erfolgreich zu einer Mikrodienstarchitektur migriert.
Neuen Mikrodienst "Frontend" erstellen
Gehen Sie wie in den letzten beiden Schritten vor, um einen neuen Front-End-Mikrodienst zu erstellen.
Bisher haben wir bei der Neuerstellung der monolithischen Anwendung die Konfiguration so aktualisiert, dass sie auf die monolithische Anwendung verweist. Jetzt müssen wir aber 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 Front-End-Mikrodienstes zu kopieren:
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
Danach gehen wir wie bei den vorherigen Schritten vor. 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
Da alle unsere Dienste jetzt als Mikrodienste ausgeführt werden, können wir unsere 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 die folgenden Befehle aus, um die monolithische Anwendung zu löschen:
kubectl delete deployment monolith kubectl delete service monolith
Testen Sie Ihre Arbeit
Um zu überprüfen, ob alles funktioniert, sollte die alte IP-Adresse des monolithischen Dienstes nicht mehr funktionieren und die neue IP-Adresse des Frontend-Dienstes 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 die externe IP-Adresse für den Mikrodienst "Frontend", nachdem Sie sie ermittelt haben. Rufen Sie diese URL (z. B. http://203.0.113.0) in Ihrem Browser auf, um zu prüfen, ob Ihr Front-End zugänglich ist. Ihre Website sollte so aussehen wie vor der Aufteilung der monolithischen Anwendung in Mikrodienste.
9. Bereinigen
Anschließend können Sie alle ausgeführten Aktivitäten am einfachsten durch Löschen des Projekts bereinigen. Durch das Löschen des Projekts werden alle in diesem Codelab erstellten Ressourcen gelöscht, um sicherzustellen, dass keine unerwarteten wiederkehrenden Gebühren anfallen. Führen Sie den folgenden Befehl in Cloud Shell aus, wobei PROJECT_ID die vollständige Projekt-ID und nicht nur der Projektname ist.
gcloud projects delete [PROJECT_ID]
Bestätigen Sie das Löschen durch Eingabe von „Y“ 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
In den folgenden Codelabs erfahren Sie mehr über Kubernetes:
- Website in der Google Kubernetes Engine bereitstellen, skalieren und aktualisieren
- Mit Node.js auf Kubernetes einen Slack-Bot erstellen
- Kontinuierliche Bereitstellung in Kubernetes mit Spinnaker
- Java-Anwendung in Kubernetes in 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