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

Dies ist die dritte Anleitung in einem Lernpfad, in dem Sie erfahren, wie Sie eine monolithische Anwendung modularisieren und containerisieren.

Der Lernpfad besteht aus den folgenden Anleitungen:

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

In der vorherigen Anleitung Monolithische Anwendung modularisieren haben Sie erfahren, wie Sie die Cymbal Books-Anwendung in unabhängige Flask-Module aufteilen. In dieser Anleitung erfahren Sie mehr über eine einzelne Änderung, die an der modularen Anwendung vorgenommen werden muss, um sie für die Containerisierung vorzubereiten.

Kosten

Sie können diese Anleitung kostenlos zu verursachen durcharbeiten. Wenn Sie jedoch die Schritte in der letzten Anleitung dieser Reihe ausführen, fallen Kosten für Ihr Google Cloud Konto an. Die Kosten entstehen, wenn Sie GKE aktivieren und die Cymbal Books-Anwendung in einem GKE-Cluster bereitstellen. Diese Kosten umfassen Clusterkosten für GKE, wie auf der Preisseite beschrieben, und Kosten für die Ausführung von Compute Engine-VMs.

Deaktivieren Sie GKE oder löschen Sie das Projekt, sobald Sie diese Anleitung durchgearbeitet haben, um unnötige Kosten zu vermeiden.

Hinweis

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: Monolithische Anwendung in eine GKE-Anwendung umwandeln – Übersicht.

Wenn Sie die erste Anleitung bereits durchgearbeitet haben, haben Sie ein GitHub-Repository geklont. Alle drei Versionen der Cymbal Books-Anwendung 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

In der vorherigen Anleitung haben Sie erfahren, dass das Homepage-Modul 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 fest codiert, wie hier:

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 verschiedene Computer verschoben werden, um Fehler zu beheben oder die Last auszugleichen. Das bedeutet, dass sich ihre IP-Adressen ändern können.

Damit das Homepage-Modul die anderen Module weiterhin erreichen kann, müssen die URLs Kubernetes-Dienstnamen anstelle von localhost verwenden. Ein Dienstname fungiert als Alias, mit dem Kubernetes Anfragen an das richtige Modul weiterleitet, unabhängig davon, wo es ausgeführt wird. Wenn das Homepage-Modul 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 Anwendung im Ordner containerized/ enthält diese Änderung bereits: Die fest codierten localhost-URLs wurden durch Kubernetes-Dienstnamen ersetzt. Die aktualisierte Version finden Sie unter 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"

Diese Aktualisierung trägt dazu bei, dass die Anwendung korrekt funktioniert, wenn sie in einer Kubernetes-Umgebung ausgeführt wird.

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, welche Art von Kubernetes-Cluster Sie zum Hosten Ihrer modularen Anwendung erstellen möchten. Das Manifest wird in YAML oder JSON geschrieben. Darin definieren Sie Dinge wie 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-Manifestekö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 sehen Sie nur, 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 überprüfen Sie jedoch nur das Manifest.

Manifest ansehen

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

  1. Öffnen Sie in Ihrem Terminal das Verzeichnis „containerized“ 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. Sie sieht so aus wie im folgenden Beispiel:

    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 Anwendung 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 Anfragenrouting verarbeiten. Jedes Modul in Ihrer Anwendung 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 Anwendung 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 Standorte im Cluster ändern. Sie haben auch das Kubernetes-Manifest untersucht und gesehen, wie die Dienstnamen im modularen Code mit den im Manifest definierten Namen übereinstimmen.

Nächste Schritte

In der nächsten Anleitung Modulare Anwendung containerisieren erfahren Sie wie Sie ein Modul containerisieren, indem Sie es in etwas verpacken, das als Container Image bezeichnet wird. Anschließend sehen Sie, wie Sie ein Container-Image als Container ausführen, seine Funktionen testen und das Container-Image in die Artifact Registry von Google übertragen.