Lernpfad: Monolithische Anwendung in eine GKE-Anwendung umwandeln – Modulare Anwendung für die Containerisierung vorbereiten

Dies ist das dritte Tutorial in einem Lernpfad, in dem Sie erfahren, wie Sie eine monolithische Anwendung modularisieren und in Containern verpacken.

Der Lernpfad besteht aus den folgenden Anleitungen:

  1. Übersicht
  2. Monolith verstehen
  3. Monolith modularisieren
  4. Modulare App für die Containerisierung vorbereiten (diese Anleitung)
  5. Modulare App containerisieren
  6. Anwendung in einem GKE-Cluster bereitstellen

Im vorherigen Tutorial Monolith modularisieren haben Sie erfahren, wie Sie die Cymbal Books-App in unabhängige Flask-Module aufteilen. In dieser Anleitung erfahren Sie, welche Änderung an der modularen App vorgenommen werden muss, um sie für die Containerisierung vorzubereiten.

Kosten

Für diese Anleitung fallen keine Kosten an. Wenn Sie jedoch die Schritte in der letzten Anleitung dieser Reihe ausführen, fallen Kosten für IhrGoogle Cloud -Konto an. Die Kosten fallen an, sobald Sie GKE aktivieren und die Cymbal Books-App in einem GKE-Cluster bereitstellen. Diese Kosten umfassen die Kosten pro Cluster für GKE, wie auf der Preisseite beschrieben, sowie die Kosten für die Ausführung von Compute Engine-VMs.

Um unnötige Gebühren zu vermeiden, sollten Sie GKE deaktivieren oder das Projekt löschen, sobald Sie diese Anleitung abgeschlossen haben.

Hinweise

Bevor Sie mit dieser Anleitung beginnen, müssen Sie die vorherigen Anleitungen der Reihe durchgearbeitet haben. Eine Übersicht über die gesamte Reihe und Links zu den einzelnen Anleitungen finden Sie unter Lernpfad: Monolith in eine GKE-App umwandeln – Übersicht.

Wenn Sie das erste Tutorial bereits durchgearbeitet haben, haben Sie ein GitHub-Repository geklont. Alle drei Versionen der Cymbal Books App befinden sich in diesem Repository in den folgenden Ordnern:

  • monolith/
  • modular/
  • containerized/

Prüfen Sie, ob sich diese Ordner auf Ihrem Computer befinden, bevor Sie fortfahren.

Modularen Code ändern

Im vorherigen Tutorial haben Sie gelernt, dass das Startseitenmodul mit den anderen Modulen kommuniziert. Es sendet Anfragen an die Endpunkte der anderen Module, um Buchdetails, Rezensionen und Bilder abzurufen, und präsentiert diese Daten dann auf HTML-Seiten.

Im Ordner modular/ sind die Endpunkte in home.py mit localhost hartcodiert:

BOOK_SERVICE_URL = "http://localhost:8081"     # Book details module listens on port 8081
REVIEW_SERVICE_URL = "http://localhost:8082"   # Book reviews module listens on port 8082
IMAGE_SERVICE_URL = "http://localhost:8083"    # Image module listens on port 8083

Diese URLs funktionieren, wenn alle Module auf demselben Computer ausgeführt werden. In einer Kubernetes-Umgebung können Module jedoch auf andere Maschinen verschoben werden, um Fehler zu beheben oder die Last auszugleichen. Das bedeutet, dass sich ihre IP-Adressen ändern können.

Damit das Startseitenmodul weiterhin auf die anderen Module zugreifen kann, müssen die URLs Kubernetes-Dienstnamen anstelle von localhost verwenden. Ein Dienstname fungiert als Alias, den Kubernetes verwendet, um Anfragen an das richtige Modul weiterzuleiten – unabhängig davon, wo es ausgeführt wird. Wenn das Startseitenmodul beispielsweise eine Anfrage an http://book-details-service/book/1 sendet, sorgt Kubernetes dafür, dass die Anfrage das Modul „book-details“ erreicht.

Sie müssen diese URLs nicht selbst aktualisieren. Die Version der App im Ordner containerized/ enthält diese Änderung bereits: Die hartcodierten localhost-URLs wurden durch Kubernetes-Dienstnamen ersetzt. Die aktualisierte Version finden Sie in containerized/home_app/home_app.py:

BOOK_SERVICE_URL = "http://book-details-service"
REVIEW_SERVICE_URL = "http://book-reviews-service"
IMAGE_SERVICE_URL = "http://images-service"

Dieses Update sorgt dafür, dass die App korrekt funktioniert, wenn sie in einer Kubernetes-Umgebung ausgeführt wird.

Das Kubernetes-Manifest

Im vorherigen Abschnitt haben Sie gesehen, wie die Endpunkte der Module aktualisiert wurden, um Kubernetes-Dienstnamen zu verwenden. Sie definieren die Dienstnamen im Kubernetes-Manifest.

Das Kubernetes-Manifest ist eine Konfigurationsdatei, in der definiert wird, welcher Kubernetes-Cluster zum Hosten Ihrer modularen App erstellt werden soll. Das Manifest wird in YAML oder JSON geschrieben. Darin definieren Sie unter anderem die Dienste (für das Routing zwischen Modulen), die Anzahl der Replikate (Instanzen) jedes Moduls und wie viel CPU und Arbeitsspeicher jedes Modul verwenden darf.

Über Kubernetes-Manifeste könnte eine ganze Reihe von Anleitungen geschrieben werden. Das Manifest ist komplex, da es alles über Ihren Kubernetes-Cluster definiert – seine Struktur, sein Verhalten und seine Funktionen. In dieser Anleitung wird nur darauf eingegangen, wie die Dienstnamen im Manifest mit den Namen übereinstimmen, die in den Endpunkten der Module verwendet werden. In einer späteren Anleitung führen Sie den Befehl kubectl apply aus, um den GKE-Cluster gemäß der im Manifest definierten Konfiguration zu erstellen. In dieser Anleitung sehen Sie sich jedoch nur das Manifest an.

Manifest ansehen

In diesem Abschnitt sehen Sie, wie Services in einem Kubernetes-Manifest definiert werden, das für Sie geschrieben wurde. Die Manifestdatei, eine YAML-Datei, befindet sich im Ordner containerized/ des GitHub-Repositorys, das Sie im ersten Tutorial dieser Reihe geklont haben. So rufen Sie eine Dienstdefinition auf:

  1. Wechseln Sie in Ihrem Terminal zum containerisierten Verzeichnis im geklonten Repository:

    cd containerized

  2. Öffnen Sie die Kubernetes-Manifestdatei in einem Texteditor:

    cat kubernetes_manifest.yaml

  3. Suchen Sie die Dienstdefinition für das Modul book-details. Es sieht in etwa so aus:

    apiVersion: v1
kind: Service
metadata:
name: book-details-service
spec:
selector:
    app: book-details-app
ports:
    - protocol: TCP
    port: 80  # External traffic on port 80
    targetPort: 8080  # Targeting container port 8080
type: ClusterIP

Der Dienstname book-details-service im Manifest stimmt mit dem Namen überein, der im Endpunkt des Moduls verwendet wird: http://book-details-service. Wenn Ihre App in Kubernetes ausgeführt wird, verwendet Kubernetes diese Dienstnamen, um Anfragen an die richtigen Module weiterzuleiten.

Das Kubernetes-Manifest definiert die Funktionen Ihres Kubernetes-Clusters, einschließlich der Dienste, die das Anforderungsrouting übernehmen. Jedes Modul in Ihrer App hat einen entsprechenden Dienst, der im Manifest definiert ist. Wenn Sie die URLs im modularen Code so aktualisieren, dass sie mit diesen Dienstnamen übereinstimmen, kann Kubernetes Anfragen an die richtigen Module weiterleiten, wenn die App in einem Cluster ausgeführt wird.

Zusammenfassung

In dieser Anleitung haben Sie gesehen, wie die URLs im modularen Code aktualisiert wurden, um Kubernetes-Dienstnamen wie http://book-details-service zu verwenden. Mit diesen Dienstnamen kann Kubernetes Anfragen zwischen Modulen weiterleiten, auch wenn sich ihre Positionen im Cluster ändern. Sie haben sich auch das Kubernetes-Manifest angesehen und gesehen, wie die Dienstnamen im modularen Code mit den im Manifest definierten Namen übereinstimmen.

Nächste Schritte

Im nächsten Tutorial Modulare App containerisieren erfahren Sie, wie Sie ein Modul containerisieren, indem Sie es in ein Container-Image verpacken. Anschließend erfahren Sie, wie Sie ein Container-Image als Container ausführen, seine Funktionen testen und das Container-Image in die Artifact Registry von Google übertragen.