Lernpfad: Eine monolithische Anwendung in eine GKE-Anwendung umwandeln – Modulare Anwendung containerisieren


Dies ist das vierte Tutorial 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. Monolith verstehen
  3. Monolith modularisieren
  4. Modulare App für die Containerisierung vorbereiten
  5. Modulare App containerisieren (diese Anleitung)
  6. Anwendung in einem GKE-Cluster bereitstellen

Im vorherigen Tutorial Modulare App für die Containerisierung vorbereiten haben Sie gesehen, welche Änderungen an der modularen Version der Cymbal Books App vorgenommen werden mussten, um sie für die Containerisierung vorzubereiten. In dieser Anleitung containerisieren Sie die App.

Kosten

Für diese Anleitung fallen keine Kosten an. Wenn Sie jedoch die Schritte in der nächsten Anleitung dieser Reihe ausführen, fallen Gebühren 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 Clustergebühren für GKE, wie auf der Preisseite beschrieben, und Gebühren 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 Tutorials finden Sie unter Lernpfad: Monolith in eine GKE-App umwandeln – Übersicht.

Umgebung einrichten

In diesem Abschnitt richten Sie eine Umgebung ein, in der Sie die modulare App in einen Container packen. Dazu führen Sie die folgenden Schritte aus:

  1. Google Cloud Projekt auswählen oder erstellen
  2. Erforderliche APIs aktivieren
  3. Cloud Shell mit Ihrem Google Cloud Projekt verbinden
  4. Standardumgebungsvariablen festlegen
  5. Repository in Artifact Registry erstellen
  6. Docker für Artifact Registry konfigurieren
  7. Anleitungscode abrufen

Google Cloud -Projekt auswählen oder erstellen

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

Erforderliche APIs aktivieren

Wenn Sie in Ihrem Google Cloud -Projekt mit Container-Images und Kubernetes arbeiten möchten, müssen Sie die folgenden APIs aktivieren:

  • Artifact Registry API: Diese API aktiviert Artifact Registry, einen Dienst zum Speichern und Verwalten Ihrer Container-Images.
  • Kubernetes Engine API: Diese API bietet Zugriff auf GKE.

Aktivieren Sie die APIs in der Google Cloud Console.

Cloud Shell mit Ihrem Google Cloud -Projekt verbinden

Nachdem Sie Ihr Google Cloud -Projekt eingerichtet haben, müssen Sie eine Cloud Shell-Instanz starten und sie mit Ihrem Google Cloud-Projekt verbinden. Cloud Shell ist ein Befehlszeilentool, mit dem Sie die Ressourcen eines Projekts direkt über Ihren Browser erstellen und verwalten können. In Cloud Shell sind zwei wichtige Tools vorinstalliert: die gcloud CLI und die kubectl CLI. In dieser Anleitung verwenden Sie die gcloud CLI, um mit Google Cloud zu interagieren. In der nächsten Anleitung verwenden Sie die kubectl CLI, um die Cymbal Books-App zu verwalten, die in GKE ausgeführt wird.

So verbinden Sie eine Cloud Shell-Instanz mit Ihrem Google Cloud -Projekt:

  1. Rufen Sie die Google Cloud Console auf:

    Google Cloud console

  2. Klicken Sie in der Console auf die Schaltfläche Cloud Shell aktivieren Cloud Shell aktivieren.

    In einem Frame im unteren Teil der Console wird eine Cloud Shell-Sitzung geöffnet.

  3. Legen Sie Ihr Standardprojekt in der Google Cloud CLI mit dem folgenden Befehl fest:

    gcloud config set project PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch die Projekt-ID des Projekts, das Sie im vorherigen Abschnitt Projekt auswählen oder erstellen erstellt oder ausgewählt haben. Google Cloud Eine Projekt-ID ist ein eindeutiger String, mit dem Ihr Projekt von allen anderen Projekten in Google Cloudunterschieden wird. Die Projekt-ID finden Sie in der Projektauswahl. Auf dieser Seite sehen Sie die Projekt-IDs für jedes Ihrer Google Cloud-Projekte.

Standardumgebungsvariablen festlegen

Um die Befehle, die Sie in dieser Anleitung ausführen, zu vereinfachen, legen Sie jetzt einige Umgebungsvariablen in Cloud Shell fest. In diesen Variablen werden Werte wie Ihre Projekt-ID, die Repository-Region und das Image-Tag gespeichert. Nachdem Sie diese Variablen definiert haben, können Sie sie in mehreren Befehlen wiederverwenden, indem Sie auf den Variablennamen (z. B. $REPOSITORY_NAME) verweisen, anstatt Werte jedes Mal neu einzugeben oder zu ersetzen. So ist die Anleitung leichter nachvollziehbar und das Fehlerrisiko wird verringert.

So richten Sie Ihre Umgebung mit Cloud Shell ein:

export PROJECT_ID=$(gcloud config get project)
export REPOSITORY_REGION=REPOSITORY_REGION
export REPOSITORY_NAME=REPOSITORY_NAME
export REPOSITORY_DESCRIPTION="REPOSITORY_DESCRIPTION"
export TAG=TAG

Ersetzen Sie Folgendes:

  • REPOSITORY_REGION: die Region, in der Ihr Artifact Registry-Repository gehostet werden soll. Beispiele: us-central1 (Iowa), us-west1 (Oregon) oder europe-west1 (Belgien). Eine vollständige Liste der Regionen finden Sie unter Regionen und Zonen.
  • REPOSITORY_NAME: der Name Ihres Repositorys. Beispiel: book-review-service-repo.
  • REPOSITORY_DESCRIPTION: Eine kurze Beschreibung des Zwecks des Repositorys. Beispiel: "Repository for storing Docker images for the book review service".
  • TAG: Das Tag, das Sie auf ein Bild anwenden möchten. Ein Tag ist ein Label, das Sie an eine bestimmte Version eines Container-Images anhängen können. Sie können Tag-Namenskonventionen wie die folgenden verwenden, um verschiedene Versionen eines Bildes deutlich zu kennzeichnen:
    • v1
    • v1.2.3
    • Ein beschreibendes Tag, z. B. feature-x-dev
    • Ein Tag, das die Umgebung angibt, z. B. test

Repository in Artifact Registry erstellen

Als Nächstes erstellen Sie ein Repository in Artifact Registry. Ein Repository ist ein Speicherort, an dem Sie Container-Images aufbewahren. Wenn Sie ein Container-Image erstellen, benötigen Sie einen Ort, an dem Sie es speichern können, damit es später in einem Kubernetes-Cluster bereitgestellt werden kann. Mit Artifact Registry können Sie diese Repositories in Ihrem Google Cloud -Projekt erstellen und verwalten.

Führen Sie den folgenden Befehl aus, um ein Repository in Artifact Registry zu erstellen:

gcloud artifacts repositories create ${REPOSITORY_NAME} \
    --repository-format=docker \
    --location=${REPOSITORY_REGION} \
    --description="${REPOSITORY_DESCRIPTION}"

Eine erfolgreiche Ausgabe des Befehls sieht etwa so aus:

Waiting for operation [...] to complete...done.
Created repository [book-review-service-repo].

Docker für Artifact Registry konfigurieren

Als Nächstes konfigurieren Sie Docker so, dass es sicher mit der Artifact Registry vonGoogle Cloudkommunizieren kann. Docker ist ein Tool, mit dem Sie Software in verschiedenen Umgebungen einheitlich verpacken und ausführen können. Im nächsten Abschnitt erfahren Sie mehr zur Funktionsweise von Docker. Derzeit müssen Sie sie so konfigurieren, dass sie eine Verbindung zu Artifact Registry herstellen kann.

Wenn Sie Docker nicht auf diese Weise konfigurieren, können Sie die Container-Images nicht in Artifact Registry hochladen. Diese Aufgabe führen Sie später in dieser Anleitung aus. Außerdem können Sie die Container-Images nicht aus Artifact Registry abrufen und in einem GKE-Cluster bereitstellen. Diese Aufgabe wird im nächsten Tutorial behandelt.

Führen Sie diesen Befehl aus, um Docker für die Authentifizierung bei Artifact Registry zu konfigurieren:

gcloud auth configure-docker ${REPOSITORY_REGION}-docker.pkg.dev

Anleitungscode abrufen

Nachdem Sie Ihre Cloud Shell-Umgebung konfiguriert haben, müssen Sie den Tutorial-Code in Cloud Shell herunterladen. Auch wenn Sie das Repository zuvor auf Ihren lokalen Computer geklont haben, müssen Sie es hier noch einmal auf Ihre Cloud Shell-Instanz klonen.

Sie können diese Anleitung zwar auch auf Ihrem lokalen Computer durchführen, müssten dann aber mehrere Tools wie Docker, kubectl und die gcloud CLI manuell installieren und konfigurieren. Die Verwendung von Cloud Shell ist einfacher, da alle diese Tools vorkonfiguriert sind.

Führen Sie in Ihrer Cloud Shell-Instanz den folgenden Befehl aus, um das GitHub-Repository zu klonen:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git

Grundlagen der Containerisierung: Container-Images, Container und Dockerfiles

Nachdem Sie Ihre Umgebung eingerichtet und den containerisierten Code heruntergeladen haben, können Sie die App containerisieren. Dazu verwenden Sie ein Dockerfile, um jedes Modul von Cymbal Books (Startseite, Buchdetails, Bilder und Rezensionen) in ein Container-Image zu verpacken. Wenn die Anwendung im GKE-Cluster bereitgestellt wird, verwendet Kubernetes diese Container-Images, um laufende Container im Cluster zu erstellen.

In den folgenden Abschnitten werden diese Konzepte im Detail erläutert.

Was ist Containerisierung?

Bei der Containerisierung werden ein Modul und alle seine Abhängigkeiten, z. B. Bibliotheken und Konfigurationsdateien, in einer Einheit namens Container-Image verpackt. Entwickler verwenden dieses Container-Image, um Container in jeder Umgebung zu erstellen und auszuführen – vom Laptop eines Entwicklers über einen Testserver bis hin zu einem Kubernetes-Produktionscluster.

Was sind Container-Images?

Ein Container-Image enthält alle Dateien, die zum Ausführen einer Anwendung erforderlich sind. Dazu gehören der Anwendungscode selbst, Systembibliotheken, die Laufzeitumgebung (z. B. der Python-Interpreter), statische Daten und alle anderen Abhängigkeiten.

In dieser Anleitung erstellen Sie ein Container-Image für jedes Modul der App für Buchrezensionen.

Was ist ein Container?

Ein Container ist eine isolierte Umgebung, in der Code aus einem Container-Image ausgeführt wird. Sie können Container auf zwei Arten erstellen: mit dem Befehl docker run für Tests während der Entwicklung oder durch Bereitstellen von Container-Images in einem Kubernetes-Cluster.

In der containerisierten Version der Cymbal Books App wird jedes Modul der modularen App in einem eigenen Container ausgeführt:

  • Im Homepage-Container wird das Homepage-Modul ausgeführt und Anfragen an / werden verarbeitet.
  • Im Container mit den Buchdetails wird das Modul mit den Buchdetails ausgeführt und es werden Daten für Endpunkte wie /book/1 oder /book/3 bereitgestellt.
  • Der Container für Buchrezensionen führt das Modul für Buchrezensionen aus und verwaltet Anfragen an Endpunkte wie /book/2/reviews.
  • Der Images-Container führt das Images-Modul aus und stellt Buchcoverbilder für Endpunkte wie /images/fungi_frontier.jpg bereit.

Ein wichtiger Vorteil von Containern ist, dass Kubernetes bei Bedarf automatisch weitere Container erstellen kann. Wenn beispielsweise viele Nutzer Buchrezensionen lesen, kann Kubernetes zusätzliche Container für Buchrezensionen starten, um die Last zu bewältigen.

Um die Skalierung in einer modularen App zu implementieren, die keine Container verwendet, müssen Sie benutzerdefinierten Code schreiben, um neue Instanzen eines Moduls zu starten und den Traffic zwischen ihnen zu verteilen. Mit Kubernetes ist diese Skalierungsfunktion integriert. Sie müssen keinen benutzerdefinierten Skalierungscode schreiben.

Was sind Dockerfiles?

Ein Dockerfile ist ein Skript, das definiert, wie ein Modul in einem Container-Image verpackt wird. In dieser Anleitung müssen Sie keine Dockerfiles erstellen. Sie sind bereits im GitHub-Repository enthalten, das Sie zuvor geklont haben. Das Verzeichnis jedes Moduls in Ihrer lokalen Kopie von kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/ enthält ein eigenes Dockerfile.

Das Dockerfile des Moduls home_app finden Sie beispielsweise in Ihrer Cloud Shell-Instanz unter kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/home_app/Dockerfile. Dieses Dockerfile sieht so aus:

# Dockerfile for home_app
FROM python:3.9-slim #line 1
WORKDIR /app #line 2
COPY requirements.txt . #line 3
RUN pip install --no-cache-dir -r requirements.txt #line 4
COPY home_app.py . #line 5
COPY templates/ ./templates/ #line 6
COPY static/ ./static/ #line 7
CMD ["python", "home_app.py"] #line 8

Dieses Dockerfile führt die folgenden Schritte aus, um das Container-Image für das Modul home_app zu erstellen:

  • Zeile 1:Mit FROM python:3.9-slim wird ein Python 3.9-Interpreter und die erforderlichen Dateien in das Container-Image heruntergeladen. Diese Dateien ermöglichen die Ausführung des Moduls.
  • Zeile 2:Mit WORKDIR /app wird im Container ein Verzeichnis mit dem Namen /app erstellt und dieses Verzeichnis als aktuelles Arbeitsverzeichnis festgelegt. Alle Befehle, die im Container ausgeführt werden, werden in diesem Verzeichnis ausgeführt.
  • Zeilen 3 und 4:Mit COPY requirements.txt . wird die Datei requirements.txt von Ihrem lokalen Computer in das Verzeichnis /app des Container-Images kopiert. In der Datei requirements.txt sind alle Python-Bibliotheken aufgeführt, die home_app.py benötigt. Mit der Zeile RUN pip install werden diese Bibliotheken im Container-Image installiert.
  • Zeilen 5 bis 7:Mit den COPY-Befehlen in diesen Zeilen werden der Code des Moduls (home_app.py) und die zugehörigen Dateien (Vorlagen und statische Assets) in das Verzeichnis /app im Container-Image kopiert.
  • Zeile 8: CMD gibt den Standardbefehl an, der von Docker beim Start des Containers ausgeführt wird. In diesem Dockerfile weist CMD ["python", "home_app.py"] Docker an, den Python-Interpreter zum Ausführen des Moduls home_app.py zu verwenden, wenn der Container gestartet wird.

Wie durch Containerisierung eine strengere Datenisolation erzwungen werden kann

Die Zeilen 5 bis 7 des Dockerfile, die im vorherigen Abschnitt beschrieben wurden, zeigen, wie durch die Containerisierung eine strengere Datenisolation als bei der modularisierten Version der App erzwungen werden kann. In einem vorherigen Tutorial haben Sie im Abschnitt Jedem Modul nur Zugriff auf die benötigten Daten gewähren erfahren, dass die modulare Version der App Daten in separaten Verzeichnissen organisiert, Module jedoch dasselbe Dateisystem verwenden und potenziell auf die Daten anderer Module zugreifen können.

In der containerisierten Version der App enthält der Container jedes Moduls nur die erforderlichen Dateien. Wenn das Modul home_app beispielsweise keinen Zugriff auf Daten zu Buchrezensionen benötigt, sind diese Daten im home_app-Container nicht vorhanden. Standardmäßig kann ein Container nicht auf Dateien aus einem anderen Container zugreifen, sofern dies nicht explizit konfiguriert ist. So wird sichergestellt, dass jedes Modul vollständig isoliert ist und versehentlicher oder nicht autorisierter Datenzugriff verhindert wird.

Im nächsten Abschnitt sehen Sie, wie der Befehl docker build ein Dockerfile als Eingabe verwendet und den Anweisungen im Dockerfile folgt, um ein Container-Image zu erstellen.

Container-Images mit Docker erstellen

In diesem Abschnitt erstellen Sie Docker-Container-Images für jedes der Buchrezensionsmodule und übertragen sie per Push in Ihr Artifact Registry-Repository. Sie verwenden diese Containerimages in einer späteren Anleitung, um die Beispielanwendung „Cymbal Books“ in Kubernetes bereitzustellen und auszuführen.

  1. Wechseln Sie zum Stammverzeichnis der containerisierten Anwendung:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/
    
  2. Erstellen Sie die Container-Images mit dem Befehl docker build:

    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG} ./home_app
    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG} ./book_details_app
    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG} ./book_reviews_app
    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG} ./images_app
    
  3. Sehen Sie sich die Container-Images an, die in Ihrer Cloud Shell-Instanz erstellt wurden:

    docker images
    

    Prüfen Sie, ob die folgenden Bilder in der Liste angezeigt werden:

    • home-app
    • book-details-app
    • book-reviews-app
    • images-app

    Wenn alle vier Bilder aufgeführt sind, haben Sie die Container-Images erfolgreich erstellt.

Container in Cloud Shell testen

Um zu prüfen, ob die Container-Images korrekt erstellt wurden, können Sie sie als Container ausführen und ihre Endpunkte in Cloud Shell testen.

Die Container book_details_app, book_reviews_app und images_app können einzeln getestet werden, da sie nicht miteinander kommunizieren müssen. Das Testen des home_app-Containers mit Docker ist jedoch schwierig, da home_app so konfiguriert ist, dass die anderen Container anhand von Dienstnamen wie http://book-details-service:8081 gefunden werden.

Es ist zwar möglich, den home_app-Container zu testen, indem Sie die IP-Adresse jedes Containers ermitteln und home_app so konfigurieren, dass er diese anstelle von Dienstnamen verwendet. Dieser Ansatz ist jedoch sehr aufwendig. Stattdessen ist es ratsam, das Testen des home_app-Containers auf die Zeit nach der Bereitstellung der Anwendung in einem Kubernetes-Cluster zu verschieben. Nachdem die App auf dem Cluster ist, können Sie prüfen, ob das Home-Modul richtig funktioniert.

So testen Sie die Container:

  1. Starten Sie die Container book_details_app, book_reviews_app und images_app:

    docker run -d -p 8081:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
    docker run -d -p 8082:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
    docker run -d -p 8083:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}
    
  2. Prüfen Sie, ob die Container ausgeführt werden, indem Sie alle aktiven Container auflisten:

    docker ps
    

    Die Ausgabe dieses Befehls sollte drei Container mit dem Status Up anzeigen:

    CONTAINER ID   IMAGE                PORTS                        STATUS
    a1b2c3d4e5f6   REGION/.../details   0.0.0.0:8081->8080/tcp       Up
    g7h8i9j0k1l2   REGION/.../reviews   0.0.0.0:8082->8080/tcp       Up
    m3n4o5p6q7r8   REGION/.../images    0.0.0.0:8083->8080/tcp       Up
    
  3. Verwenden Sie die folgenden curl-Befehle, um die Endpunkte des book_details_app-Containers zu testen:

    curl http://localhost:8081/books
    curl http://localhost:8081/book/1
    curl http://localhost:8081/book/2
    curl http://localhost:8081/book/3
    

    Jeder dieser Befehle gibt Daten im JSON-Format zurück. Die Ausgabe des Befehls curl http://localhost:8081/book/1 sieht beispielsweise so aus:

    {"author":"Aria Clockwork","description":"In a world where time is a tangible substance, a young clockmaker discovers she can manipulate the fabric of time itself, leading to unforeseen consequences in her steampunk-inspired city.","id":1,"image_url":"zephyrs_timepiece.jpg","title":"Zephyr's Timepiece","year":2023}
    
  4. Rufen Sie Buchrezensionen aus dem book_reviews_app-Container mit dem folgenden curl-Befehl ab:

    curl http://localhost:8082/book/1/reviews
    

    Dieser Befehl gibt eine Liste mit 20 Rezensionen zu Buch 1 im JSON-Format zurück. Hier ist ein Beispiel für eine Rezension aus der Liste:

    {
    "content": "The concept of time as a tangible substance is brilliantly explored in 'Zephyr's Timepiece'.",
    "rating": 5
    }
    
  5. Testen Sie den images_app-Container:

    1. Klicken Sie auf die Schaltfläche **Web Preview**. Schaltfläche für Webvorschau

    2. Wählen Sie Port ändern aus und geben Sie 8083 ein. Ein Browserfenster mit einer URL wie dieser wird geöffnet:

      https://8083-your-instance-id.cs-your-region.cloudshell.dev/?authuser=0
      
    3. Entfernen Sie ?authuser=0 am Ende der URL und fügen Sie den Pfad zu einer Bilddatei hinzu, z. B. /images/fungi_frontier.jpg. Hier ein Beispiel:

      https://8083-your-instance-id.cs-your-region.cloudshell.dev/images/fungi_frontier.jpg
      

      Das Titelbild für Fungi Frontier sollte in Ihrem Browser angezeigt werden.

  6. Beenden Sie die Container nach dem Testen, um Ressourcen freizugeben:

    1. Listen Sie die laufenden Container auf und suchen Sie nach ihren Container-IDs:

      docker ps
      
    2. Beenden Sie jeden Container:

      docker stop CONTAINER_ID
      

      Ersetzen Sie CONTAINER_ID durch die ID des Containers, den Sie stoppen möchten.

Container-Images per Push an Artifact Registry übertragen

Bevor Sie Ihre Anwendung in einem Kubernetes-Cluster bereitstellen können, müssen die Container-Images an einem Ort gespeichert werden, auf den der Cluster zugreifen kann. In diesem Schritt übertragen Sie die Images per Push an das Artifact Registry-Repository, das Sie zuvor erstellt haben. Im nächsten Tutorial stellen Sie diese Images aus dem Artifact Registry-Repository in einem GKE-Cluster bereit:

  1. Führen Sie die folgenden Befehle aus, um Ihre Container-Images per Push an Artifact Registry zu übertragen:

    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG}
    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}
    
  2. Prüfen Sie nach dem Übertragen der Bilder, ob sie erfolgreich hochgeladen wurden, indem Sie sie auflisten:

    gcloud artifacts docker images list ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}
    

    Die Ausgabe sollte in etwa so aussehen:

    Listing items under project ${PROJECT_ID}, location ${REPOSITORY_REGION}, repository ${REPOSITORY_NAME}.
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app
    DIGEST: sha256:f7b78f44d70f2eedf7f7d4dc72c36070e7c0dd05daa5f473e1ebcfd1d44b95b1
    CREATE_TIME: 2024-11-14T00:38:53
    UPDATE_TIME: 2024-11-14T00:38:53
    SIZE: 52260143
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app
    DIGEST: sha256:875ac8d94ef54db2ff637e49ad2d1c50291087623718b854a34ad657748fac86
    CREATE_TIME: 2024-11-14T00:39:04
    UPDATE_TIME: 2024-11-14T00:39:04
    SIZE: 52262041
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app
    DIGEST: sha256:70ddc54ffd683e2525d87ee0451804d273868c7143d0c2a75ce423502c10638a
    CREATE_TIME: 2024-11-14T00:33:56
    UPDATE_TIME: 2024-11-14T00:33:56
    SIZE: 52262412
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app
    DIGEST: sha256:790f0d8c2f83b09dc3b431c4c04d7dc68254fecc76c48f00a83babc2a5dc0484
    CREATE_TIME: 2024-11-14T00:39:15
    UPDATE_TIME: 2024-11-14T00:39:15
    SIZE: 53020815
    

    Die Ausgabe enthält die folgenden Informationen zu jedem Bild:

    • IMAGE: Der Repository-Pfad und der Image-Name.
    • DIGEST: Eine eindeutige Kennung für das Bild.
    • CREATE_TIME oder UPDATE_TIME: Das Datum, an dem das Bild erstellt oder zuletzt geändert wurde.
    • SIZE: Die Größe des Bildes in Byte.

Kubernetes-Manifest mit Pfaden zu Container-Images aktualisieren

Wie Sie im vorherigen Tutorial Modulare App für die Containerisierung vorbereiten gelernt haben, ist ein Kubernetes-Manifest eine YAML-Datei, die definiert, wie Ihre App in einem Kubernetes-Cluster ausgeführt wird. Sie enthält unter anderem folgende Details:

  • Die Module Ihrer App, z. B. home-app und book-details-app
  • Pfade zu den Container-Images
  • Konfigurationsdetails wie Ressourcenlimits
  • Dienstdefinitionen für das Weiterleiten von Anfragen zwischen Modulen

In diesem Abschnitt aktualisieren Sie dieselbe Manifestdatei, die Sie im vorherigen Tutorial überprüft haben. Diese Datei ist kubernetes-manifest.yaml und enthält Platzhalterwerte für die Bildpfade. Sie müssen diese Platzhalter durch die tatsächlichen Pfade zu den Container-Images ersetzen, die Sie im vorherigen Abschnitt in Ihr Artifact Registry-Repository hochgeladen haben.

So aktualisieren Sie die Kubernetes-Manifestdatei kubernetes-manifest.yaml:

  1. Öffnen Sie in Cloud Shell das Verzeichnis containerized/, das die Kubernetes-Manifestdatei kubernetes-manifest.yaml enthält:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/
    
  2. Öffnen Sie die kubernetes-manifest.yaml-Datei in einem Texteditor:

    vim kubernetes-manifest.yaml
    
  3. Suchen Sie die image-Felder, die Platzhalter wie diesen enthalten:

    image: REPOSITORY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/home-app:TAG
    

    Ersetzen Sie jeden Platzhalter durch die tatsächlichen Pfade zu den Container-Images, die Sie in Artifact Registry übertragen haben:

    So könnte ein Pfad nach diesen Ersetzungen aussehen:

    image:us-west1-docker.pkg.dev/your-project-id/book-review-service-repo/home-app:v1
    
  4. Aktualisieren Sie die Pfade für alle Container-Images:

    • home-app
    • book-details-app
    • book-reviews-app
    • images-app
  5. Speichern Sie die Manifestdatei und schließen Sie den Editor, nachdem Sie die Pfade aktualisiert haben. Wenn Sie beispielsweise vim verwenden, drücken Sie Esc, um in den Befehlsmodus zu wechseln, geben Sie wq ein und drücken Sie die Eingabetaste, um die Datei zu speichern und zu beenden.

Ihr Kubernetes-Manifest ist jetzt so konfiguriert, dass die Container-Images aus Ihrem Artifact Registry-Repository in einem Kubernetes-Cluster bereitgestellt werden.

Zusammenfassung

In dieser Anleitung haben Sie die modulare Cymbal Books-App für die Bereitstellung in einem Kubernetes-Cluster vorbereitet, indem Sie die folgenden Aufgaben ausgeführt haben:

  1. Sie haben ein Google Cloud Projekt eingerichtet und Cloud Shell für Ihre Umgebung konfiguriert.
  2. Die bereitgestellten Dockerfiles für jedes App-Modul wurden geprüft.
  3. Container-Images für die App-Module mit Docker erstellt.
  4. Container in Cloud Shell getestet, um ihre Funktionalität zu prüfen.
  5. Container-Images per Push in Artifact Registry übertragen, um sie zu speichern.
  6. Das Kubernetes-Manifest wurde aktualisiert, um die richtigen Container-Image-Pfade aus Artifact Registry zu verwenden.

Nächste Schritte

Im nächsten Tutorial Anwendung in einem GKE-Cluster bereitstellen stellen Sie die Containeranwendung in einem GKE-Cluster bereit.