Aufteilen einer Monolithanwendung in Microservices

mit Amazon Elastic Container Service, Docker und Amazon EC2

Containerisieren des Monolithen

Bereitstellen von Microservices

Modul 4 – Bereitstellen von Microservices

In diesem Modul stellen Sie die Anwendung node.js als Gruppe von miteinander verbundenen Services hinter einem Application Load Balancer (ALB) bereit. Anschließend verlagern Sie den Datenverkehr mit dem ALB nahtlos vom Monolithen auf die Microservices. Erste Schritte

Übersicht über die Architektur

Hierbei handelt es sich um den Prozess, mit dessen Hilfe Sie die Microservices bereitstellen und den Datenverkehr der Anwendung sicher vom Monolithen wegführen.

Verlagern des Datenverkehrs
Hierbei handelt es sich um die Ausgangskonfiguration. Die monolithische Anwendung node.js wird in einem Container in Amazon ECS ausgeführt.
Starten von Microservices
Mithilfe der drei Container-Images, die Sie im vorherigen Modul erstellt und nach Amazon ECR übertragen haben, starten Sie drei Microservices im bestehenden Amazon ECS-Cluster.
Konfigurieren der Zielgruppen
Wie in Modul 2 fügen Sie eine Zielgruppe für jeden Service hinzu und aktualisieren die ALB-Regeln, um die neuen Microservices zu verbinden.
Herunterfahren des Monolithen
Durch Ändern einer Regel im ALB beginnen Sie mit der Weiterleitung des Datenverkehrs an die ausgeführten Microservices. Nach Überprüfung der Umleitung des Datenverkehrs fahren Sie den Monolithen herunter.

Zeit bis Fertigstellung: 30 Minuten

Genutzte Services:

Implementierungsanweisungen

Befolgen Sie die folgende schrittweise Anleitung zum Bereitstellen der Microservices. Klicken Sie auf die jeweilige Nummer eines Schritts, um den Bereich zu erweitern.

Schritt 1. Verfassen von Aufgabendefinitionen für Ihre Services
Sie stellen drei neue Services im Cluster bereit, das Sie in Modul 2 gestartet haben. Wie in Modul 2 verfassen Sie Aufgabendefinitionen für jeden Service.

⚐ HINWEIS: Einer einzelnen Aufgabendefinition können mehrere Container hinzugefügt werden. Das bedeutet, dass Sie alle drei Microservices als unterschiedliche Container über einen einzigen Service ausführen können. Diese Vorgehensweise ist jedoch nach wie vor monolithisch, da jeder Container linear mit dem Service skaliert werden müsste. Das Ziel sind drei unabhängige Services. Jeder Service erfordert eine eigene Aufgabendefinition, die einen Container mit dem Image des jeweiligen Service ausführt.

Diese Aufgabendefinitionen können Sie entweder in der Amazon ECS-Konsole erstellen oder, noch schneller, als JSON verfassen. Um die Aufgabendefinition als JSON-Datei zu verfassen, gehen Sie wie folgt vor:

Klicken Sie in der Amazon Elastic Container Services-Konsole unter Amazon ECS auf Task definitions (Aufgabendefinitionen).

Klicken Sie auf der Seite Task Definitions (Aufgabendefinitionen) auf die Schaltfläche Create new Task Definition (Neue Aufgabendefinition erstellen).

Wählen Sie auf der Seite Select launch type compatibility (Kompatibilität des Starttyps auswählen) die Option EC2 aus und dann Next step (Nächster Schritt).

Scrollen Sie auf der Seite Configure task and container definitions (Aufgaben- und Containerdefinitionen konfigurieren) zum Abschnitt Volumes und klicken Sie auf die Schaltfläche Configure via JSON (Über JSON konfigurieren).

Kopieren Sie das folgenden Code-Snippet und fügen Sie es anstelle des vorhandenen Codes in das JSON-Feld ein.
Denken Sie daran, die Platzhalter [service-name], [account-ID], [region] und [tag] zu ersetzen.

⚐ Hinweis: Für die Aufgabendefinition werden die folgenden Parameter verwendet:

Name = [service-name: posts, threads und users]

Image = [URL des Amazon ECR-Repository-Image]:latest

CPU = 256

Arbeitsspeicher = 256

Container-Port = 3000

Host-Port = 0
```
{
    "containerDefinitions": [
        {
            "name": "[service-name]",
            "image": "[account-id].dkr.ecr.[region].amazonaws.com/[service-name]:[tag]",
            "memoryReservation": "256",
            "cpu": "256",
            "essential": true,
            "portMappings": [
                {
                    "hostPort": "0",
                    "containerPort": "3000",
                    "protocol": "tcp"
                }
            ]
        }
    ],
    "volumes": [],
    "networkMode": "bridge",
    "placementConstraints": [],
    "family": "[service-name]"
}
```
♻ Wiederholen Sie die Schritte, um eine Aufgabendefinition für jeden Service zu erstellen:

posts

threads

users
Schritt 2. Konfigurieren des Application Load Balancer: Zielgruppen
Konfigurieren Sie wie in Modul 2 eine Zielgruppe für jeden Service (posts, threads und users). Mithilfe einer Zielgruppe kann der Datenverkehr einem angegebenen Service auf korrekte Weise zugeführt werden. Die Zielgruppen konfigurieren Sie mit der AWS-Befehlszeilenschnittstelle. Vor dem Fortfahren müssen Sie jedoch sicherstellen, dass Sie über den korrekten, für dieses Tutorial verwendeten VPC-Namen verfügen:

Navigieren Sie zum Abschnitt "Load Balancer" der EC2-Konsole.

Aktivieren Sie das Kontrollkästchen neben der Demo, wählen Sie die Registerkarte Description (Beschreibung) aus und suchen Sie nach dem Attribut VPC (in diesem Format: vpc-xxxxxxxxxxxxxxxxx).
⚐ Hinweis: Sie benötigen das VPC-Attribut beim Konfigurieren der Zielgruppen.

Konfigurieren der Zielgruppen

Geben Sie im Terminal den folgenden Befehl ein, um eine Zielgruppe für jeden Service (posts, threads und users) zu erstellen. Darüber hinaus erstellen Sie eine Zielgruppe (drop-traffic), um zu verhindern, dass der Datenverkehr den Monolithen erreicht, sobald die Microservices vollständig ausgeführt werden. Denken Sie daran, die folgenden Platzhalter zu ersetzen: [region], [service-name] und [vpc-attribute].

Service-Namen: posts, threads, users und drop-traffic
```
aws elbv2 create-target-group --region [region] --name [service-name] --protocol HTTP --port 80 --vpc-id [vpc-attribute] --healthy-threshold-count 2 --unhealthy-threshold-count 2 --health-check-timeout-seconds 5 --health-check-interval-seconds 6
```
Schritt 3. Konfigurieren der Listener-Regeln
Der Listener prüft eingehende Verbindungsanfragen an den ALB, um den Datenverkehr entsprechend weiterzuleiten.

Derzeit werden Ihre vier Services (Monolith und die drei Microservices) alle hinter demselben Load Balancer ausgeführt. Um die Umstellung vom Monolithen zu den Microservices zu vollziehen, beginnen Sie mit der Weiterleitung des Datenverkehrs zu den Microservices und beenden dessen Weiterleitung zum Monolithen.

Zugreifen auf die Listener-Regeln

Navigieren Sie zum Abschnitt "Load Balancer" der EC2-Konsole.

Suchen Sie nach der entsprechenden Load Balancer-Demo und aktivieren Sie das Kontrollkästchen daneben, um die Details anzuzeigen.

Wählen Sie die Registerkarte Listeners aus.

Aktualisieren der Listener-Regeln

Auf der Registerkarte sollte nur ein Listener aufgeführt sein. Gehen Sie wie folgt vor, um die Listener-Regeln zu bearbeiten:

Wählen Sie unter der Spalte Rules (Regeln) die Option View/edit rules (Regeln anzeigen/bearbeiten) aus.

Klicken Sie auf der Seite Rules (Regeln) auf die Plus-Schaltfläche (+).
Daraufhin wird die Option Insert Rule (Regel einfügen) auf der Seite angezeigt.

Fügen Sie die erforderlichen Regeln mithilfe der folgenden Regelvorlage ein. Dazu gehören eine Regel für die Aufrechterhaltung des Datenverkehrs zum Monolithen und eine für jeden Microservice:

IF Path = /api/[service-name]* THEN Forward to [service-name]
Beispiel: IF Path = /api/posts* THEN Forward to posts

Fügen Sie die Regeln in der folgenden Reihenfolge ein:

api: /api* wird weitergeleitet an api

users: /api/users* wird weitergeleitet an users

threads: /api/threads* wird weitergeleitet an threads

posts: /api/posts* wird weitergeleitet an posts

Klicken Sie auf Save (Speichern).

Klicken Sie auf den Zurück-Pfeil links oben auf der Seite, um zur Load-Balancer-Konsole zurückzukehren.
Schritt 4. Bereitstellen der Microservices
Stellen Sie die drei Microservices (posts, threads und users) in Ihrem Cluster bereit. Wiederholen Sie diese Schritte für jeden der drei Microservices:

Navigieren Sie zur Amazon ECS-Konsole und wählen Sie in der linken Menüleiste Clusters (Cluster) aus.

Wählen Sie das Cluster BreakTheMonolith-Demo und dann die Registerkarte Services aus und klicken Sie anschließend auf Create (Erstellen).

Auf der Seite Configure service (Service konfigurieren) bearbeiten Sie die folgenden Parameter (behalten Sie die Standardwerte für unten nicht aufgeführte Parameter bei):

Unter Launch type (Starttyp) wählen Sie EC2 aus.

Unter Task Definition (Aufgabendefinition) klicken Sie auf die Schaltfläche Enter a value (Wert eingeben), um automatisch den höchsten Versionswert auszuwählen.
Beispiel: api:1

Unter Service name (Servicename) geben Sie einen Servicenamen ein (posts, threads oder users).

Unter Number of tasks (Anzahl der Aufgaben) geben Sie 1 ein.

Klicken Sie auf Next step (Nächster Schritt).

Gehen Sie auf der Seite Configure network (Netzwerk konfigurieren) im Abschnitt Load balancingwie folgt vor:

Unter Load balancer type (Art des Load Balancer) wählen Sie Application Load Balancer aus.

Unter Service IAM role (IAM-Rolle des Service) wählen Sie BreakTheMonolith-Demo-ECSServiceRole aus.

Stellen Sie sicher, dass unter Load balancer name (Load Balancer-Name) demo ausgewählt ist.

Klicken Sie im Abschnitt Container to load balance (Container für Lastausgleich) auf die Schaltfläche Add to load balancer (Zum Load Balancer hinzufügen), und nehmen Sie folgende Änderungen vor:

Unter Production listener port (Port des Produktions-Listener) stellen Sie 80:HTTP ein.

Unter Target group name (Name der Zielgruppe) wählen Sie die entsprechende Gruppe aus: (posts, threads oder users)

Klicken Sie auf Next step (Nächster Schritt).

Klicken Sie auf der Seite Set Auto Scaling (Auto Scaling einstellen) auf Next step (Nächster Schritt).

Klicken Sie auf der Seite Review (Überprüfung) auf Create Service (Service erstellen).

Klicken Sie auf View Service (Service anzeigen).

Es sollte nur einige Sekunden dauern, bis alle Services gestartet werden. Vergewissern Sie sich vor dem Fortfahren noch einmal, dass alle Services und Aufgaben ausgeführt werden und aktiv sind.
Schritt 5. Verlagern des Datenverkehrs auf die Microservices
Ihre Microservices werden jetzt ausgeführt, doch der gesamte Datenverkehr fließt nach wie vor zum Monolithen. Um den Datenverkehr zu den Microservices umzuleiten, gehen Sie zum Aktualisieren der Listener-Regeln wie folgt vor:

Navigieren Sie zum Abschnitt "Load Balancers" der EC2-Konsole.

Aktivieren Sie das Kontrollkästchen neben demo, um die Details des Load Balancer anzuzeigen.

Wählen Sie die Registerkarte Listeners aus.
Es sollte nur ein Listener aufgeführt sein.

Wählen Sie unter der Spalte Rules (Regeln) die Option View/edit rules (Regeln anzeigen/bearbeiten) aus.

Klicken Sie auf der Seite Rules (Regeln) im oberen Menü auf die Minus-Schaltfläche (-).

Löschen Sie die erste Regel (/api* wird weitergeleitet an api), indem Sie das Kontrollkästchen daneben aktivieren.

Wählen Sie Delete aus.

Aktualisieren Sie die Standardregel so, dass an drop-traffic weitergeleitet wird.

Klicken Sie im oberen Menü auf die Bearbeitungsschaltfläche (Bleistift).

Klicken Sie auf das Bearbeitungssymbol (Bleistift) neben der Standardregel (HTTP 80: default action).

Klicken Sie auf das Bearbeitungssymbol (Bleistift) in der Spalte THEN, um Forward to (Weiterleiten an) zu bearbeiten.

Wählen Sie im Feld Target group (Zielgruppe) drop-traffic aus.

Klicken Sie auf die Schaltfläche Update (Aktualisieren).

Im folgenden Screenshot finden Sie ein Beispiel für die aktualisierten Regeln.
Deaktivieren Sie den Monolithen: Da der Datenverkehr jetzt zu Ihren Microservices fließt, können Sie den Monolithservice deaktivieren.

Navigieren Sie zurück zum Amazon ECS-Cluster BreakTheMonolith-Demo-ECSCluster.

Aktivieren Sie auf der Registerkarte Services das Kontrollkästchen neben api und klicken Sie auf Update (Aktualisieren).

Suchen Sie auf der Seite Configure service (Service konfigurieren) das Feld Number of tasks (Anzahl der Aufgaben) und geben Sie 0 ein.

Klicken Sie auf Skip to review (Zum Überprüfen überspringen).

Klicken Sie auf Update Service (Service aktualisieren).

Amazon ECS leert nun Verbindungen von Containern, die der Service im Cluster bereitgestellt hat, und stoppt anschließend die Container. Wenn Sie die Bereitstellungs- oder Aufgabenlisten nach ca. 30 Sekunden aktualisieren, erkennen Sie, dass die Anzahl der Aufgaben auf 0 zurückgeht. Der Service ist nach wie vor aktiv. Wenn Sie aus irgendeinem Grund ein Rollback durchführen müssen, können Sie ihn daher einfach aktualisieren, um weitere Aufgaben bereitzustellen.

Den api-Service können Sie optional löschen. Aktivieren Sie auf der Registerkarte Services das Kontrollkästchen neben api, klicken Sie auf Delete (Löschen) und bestätigen Sie den Löschvorgang.

Sie haben node.js nun vollständig vom Monolithen auf Microservices umgestellt – ohne Ausfallzeiten!
Schritt 6. Validieren der Bereitstellung
Suchen Sie nach der Service-URL: Hierbei handelt es sich um die gleiche URL, die Sie in Modul 2 dieses Tutorials verwendet haben.

Navigieren Sie zum Abschnitt "Load Balancers" der EC2-Konsole.

Aktivieren Sie das Kontrollkästchen neben demo, um die Details des Load Balancer anzuzeigen.

Suchen Sie auf der Registerkarte Description (Beschreibung) nach dem DNS-Namen und klicken Sie auf das Kopiersymbol am Ende der URL.

Fügen Sie den DNS-Namen in einer neuen Registerkarte oder einem neuen Fenster des Browsers ein.

Es sollte die Meldung "Ready to receive requests" (Bereit zum Empfangen von Anfragen) angezeigt werden.

Zeigen Sie die Werte der einzelnen Microservices an: Der ALB leitet den Datenverkehr auf Grundlage der Anfrage-URL weiter. Um die einzelnen Services anzuzeigen, fügen Sie den Servicenamen einfach an das Ende des DNS-Namens an:

http://[DNS-Name]/api/users

http://[DNS-Name]/api/threads

http://[DNS-Name]/api/posts
⚐ HINWEIS: Diese URLs verhalten sich genauso wie beim Bereitstellen des Monolithen. Dies ist sehr wichtig, da APIs oder Verbraucher, die davon ausgehen, dass sie eine Verbindung zu dieser Anwendung herstellen, von den vorgenommenen Änderungen nicht betroffen sind. Die Umstellung vom Monolithen auf Microservices erforderte keine Änderungen an Teilen Ihrer Infrastruktur.

Zum Testen Ihrer APIs können Sie auch Tools wie Postman verwenden.