Modul 4: Mit Docker von der Google App Engine zu Cloud Run migrieren

1. Übersicht

Diese Reihe von Codelabs – also praxisorientierten Anleitungen zum selbstbestimmten Lernen – soll Entwickler von Google App Engine (Standard) bei der Modernisierung ihrer Anwendungen unterstützen, indem sie sie durch eine Reihe von Migrationen führen. Anschließend können Nutzer ihre Anwendungen portierbarer machen, indem sie sie explizit für Cloud Run, den Container-Hosting-Dienst von Google Cloud in App Engine, sowie andere Container-Hosting-Dienste containerisieren.

In dieser Anleitung erfahren Sie, wie Sie App Engine-Anwendungen containerisieren, um sie im vollständig verwalteten Cloud Run-Dienst mit Docker bereitzustellen, einer bekannten Plattform zum Entwickeln, Versenden und Ausführen von Anwendungen in Containern. Python 2-Entwickler beginnen mit der Cloud NDB-Beispielanwendung für App Engine, während Python 3-Entwickler mit dem Cloud Datastore-Beispiel für Modul 3 beginnen.

Du lernst, wie du

  • Anwendung mit Docker containerisieren
  • Container-Images in Cloud Run bereitstellen

Voraussetzungen

Umfrage

Wie möchten Sie dieses Codelab nutzen?

<ph type="x-smartling-placeholder"></ph> Lesen Sie sie nur durch. Lies sie dir durch und absolviere die Übungen

2. Hintergrund

PaaS-Systeme wie App Engine und Cloud Functions bieten Ihrem Team und Ihrer Anwendung viele Vorteile. Diese serverlosen Plattformen ermöglichen es SysAdmin/DevOps beispielsweise, sich auf die Entwicklung von Lösungen zu konzentrieren. Ihre App kann bei Bedarf automatisch hochskaliert oder auf null herunterskaliert werden, da sie eine nutzungsabhängige Abrechnung zur Kostenkontrolle ermöglicht. Außerdem verwenden sie eine Vielzahl gängiger Entwicklungssprachen.

Die Flexibilität der Container überzeugt jedoch auch mit der Möglichkeit, jede Sprache, jede Bibliothek und jedes Binärprogramm auszuwählen. Google Cloud Run bietet Nutzern das Beste aus beiden Welten, den Komfort einer serverlosen Umgebung und die Flexibilität von Containern.

Die Verwendung von Cloud Run wird in diesem Codelab nicht behandelt. die in der Cloud Run-Dokumentation behandelt werden. Hier erfahren Sie, wie Sie Ihre App Engine-Anwendung für Cloud Run (oder andere Dienste) containerisieren. Bevor Sie fortfahren, sollten Sie ein paar Dinge beachten. Hauptsächlich ist die Nutzererfahrung etwas anders, da Sie keinen Anwendungscode mehr bereitstellen müssen.

Stattdessen müssen Sie sich etwas über Container informieren, z. B. wie sie erstellt und bereitgestellt werden. Sie können auch entscheiden, was Sie in das Container-Image einfügen möchten, einschließlich eines Webservers, da Sie den Webserver von App Engine nicht mehr verwenden werden. Wenn Sie diesem Weg nicht folgen möchten, ist es keine schlechte Option, Ihre Anwendungen in App Engine zu belassen.

In dieser Anleitung erfahren Sie, wie Sie Ihre Anwendung containerisieren, die App Engine-Konfigurationsdateien durch die Containerkonfiguration ersetzen, bestimmen, was in den Container aufgenommen wird, und dann angeben, wie Ihre Anwendung gestartet werden soll. Viele dieser Aufgaben werden von App Engine automatisch ausgeführt.

Diese Migration umfasst folgende Schritte:

  1. Einrichtung/Vorarbeit
  2. Anwendung
      in Container verpacken
    • Konfigurationsdateien ersetzen
    • Anwendungsdateien ändern

3. Einrichtung/Vorarbeit

Bevor wir mit dem Hauptteil des Tutorials fortfahren, richten wir unser Projekt ein, rufen den Code ab und stellen dann die Referenzanwendung bereit, damit wir wissen, dass wir mit funktionierendem Code beginnen.

1. Projekt einrichten

Wenn Sie die Codelabs Modul 2 oder Modul 3 abgeschlossen haben, empfehlen wir Ihnen, dasselbe Projekt und denselben Code wiederzuverwenden. Alternativ können Sie ein ganz neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Achten Sie darauf, dass das Projekt ein aktives Rechnungskonto hat und die App Engine (App) aktiviert ist.

2. Baseline-Beispiel-App abrufen

Für dieses Codelab benötigen Sie eine funktionierende Beispiel-App für Modul 2 oder Modul 3. Falls Sie keines der Anleitungen haben, lesen Sie die Links oben und folgen Sie der Anleitung, bevor Sie fortfahren. Wenn Sie bereits mit dem Inhalt vertraut sind, können Sie einfach mit dem Code für Modul 2 oder 3 unten beginnen.

Unabhängig davon, ob Sie Ihren oder unseren verwenden, STARTEN wir im Modul 2-Code für die Python 2-Version dieser Anleitung und entsprechend mit dem Modul 3-Code für Python 3. Dieses Codelab für Modul 4 führt Sie durch die einzelnen Schritte. Wenn Sie fertig sind, sollten Sie je nach Ihren Optionen Code erhalten, der einem der Repository-Ordner für Modul 4 (FINISH) ähnelt.

Das Verzeichnis der START-Dateien von Python 2 Modul 2 (Ihre oder unsere) sollte wie folgt aussehen:

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

Wenn Sie Ihren eigenen Code für Modul 2 (2.x) verwenden, haben Sie auch einen lib-Ordner. Weder lib noch appengine_config.py werden für Python 3 verwendet, wobei der STARTing-Code für Modul 3 (3.x) so aussehen sollte:

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

3. Referenz-App noch einmal bereitstellen

Sie müssen die verbleibenden Schritte jetzt ausführen:

  1. Machen Sie sich noch einmal mit dem gcloud-Befehlszeilentool vertraut
  2. Beispielanwendung mit gcloud app deploy noch einmal bereitstellen
  3. Prüfen, ob die Anwendung in App Engine problemlos ausgeführt wird

Nachdem Sie diese Schritte ausgeführt haben, können Sie den Container in Container verlagern.

4. Anwendung containerisieren

Docker ist die standardmäßige Containerisierungsplattform in der Branche. Eine Herausforderung bei der Verwendung besteht, wie bereits erwähnt, darin, dass eine effiziente Dockerfile ausgewählt werden muss. Das ist die Konfigurationsdatei, die bestimmt, wie Ihre Container-Images erstellt werden. Buildpacks erfordern dagegen wenig Aufwand, da die Abhängigkeiten Ihrer App durch Selbstprüfung ermittelt werden. Dadurch wird der Buildpack-Container für Ihre App so effizient wie möglich.

Wenn Sie bereits mit Containern und Docker vertraut sind und mehr über die Containerisierung Ihrer App Engine-Anwendung für Cloud Run erfahren möchten, sind Sie hier genau richtig. Sie können danach auch das Codelab für Modul 5 durcharbeiten (identisch mit diesem, nur mit den Cloud Buildpacks). Unsere einfache Beispiel-App ist so schlank, dass einige der zuvor erwähnten Dockerfile-Probleme vermieden werden.

Die Migrationsschritte umfassen das Ersetzen der App Engine-Konfigurationsdateien und das Angeben, wie Ihre Anwendung gestartet werden soll. In der folgenden Tabelle sind die zu erwartenden Konfigurationsdateien für jeden Plattformtyp zusammengefasst. Vergleichen Sie die App Engine-Spalte mit der Docker-Spalte (und optional den Buildpacks):

Beschreibung

App Engine

Docker

Buildpacks

Allgemeine Konfiguration

app.yaml

Dockerfile

(service.yaml)

Bibliotheken von Drittanbietern

requirements.txt

requirements.txt

requirements.txt

Drittanbieterkonfiguration

app.yaml (plus appengine_config.py und lib [nur 2.x])

(nicht zutreffend)

(nicht zutreffend)

Starten

(nicht zutreffend) oder app.yaml (falls entrypoint verwendet)

Dockerfile

Procfile

Dateien ignorieren

.gcloudignore und .gitignore

.gcloudignore, .gitignore und .dockerignore

.gcloudignore und .gitignore

Sobald Ihre Anwendung containerisiert ist, kann sie in Cloud Run bereitgestellt werden. Weitere Optionen für die Google Cloud-Containerplattform sind Compute Engine, GKE und Anthos.

Allgemeine Konfiguration

Bei der Migration von App Engine wird app.yaml durch eine Dockerfile ersetzt, die das Erstellen und Ausführen des Containers beschreibt. App Engine startet Ihre Anwendung automatisch, Cloud Run jedoch nicht. Dafür sind die Befehle Dockerfile ENTRYPOINT und CMD vorgesehen. Weitere Informationen zu Dockerfile finden Sie auf dieser Cloud Run-Dokumentationsseite sowie ein Dockerfile-Beispiel, das gunicorn generiert.

Eine Alternative zur Verwendung von ENTRYPOINT oder CMD in einer Dockerfile ist die Verwendung von Procfile. Schließlich hilft ein .dockerignore dabei, Nicht-App-Dateien herauszufiltern, um die Containergröße gering zu halten. Mehr dazu demnächst!

app.yaml löschen und Dockerfile erstellen

Die app.yaml wird in Containern nicht verwendet. Löschen Sie sie daher jetzt. Die Containerkonfigurationsdatei ist Dockerfile und für unsere Beispiel-App ist nur eine minimale Konfiguration erforderlich. Erstellen Sie die Datei Dockerfile mit diesem Inhalt und ersetzen Sie dabei NNN durch 2 oder 3, je nachdem, welche Python-Version Sie verwenden:

FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]

Die meisten Dockerfile geben an, wie der Container erstellt werden soll, mit Ausnahme von ENTRYPOINT. Hier wird angegeben, wie der Container gestartet wird. In diesem Fall wird python main.py aufgerufen, um den Flask-Entwicklungsserver auszuführen. Wenn Sie Docker noch nicht kennen, gibt die Anweisung FROM das zu startende Basis-Image an und „slim“. bezieht sich auf eine minimale Python-Distribution. Weitere Informationen finden Sie auf der Seite Docker-Python-Images.

Mit der mittleren Gruppe von Befehlen wird das Arbeitsverzeichnis (/app) erstellt, die Anwendungsdateien kopiert und dann pip install ausgeführt, um Bibliotheken von Drittanbietern in den Container zu bringen. WORKDIR kombiniert die Linux-Befehle mkdir und cd. Weitere Informationen dazu finden Sie in der WORKDIR-Dokumentation . Die Anweisungen COPY und RUN sind selbsterklärend.

Bibliotheken von Drittanbietern

Die Datei requirements.txt kann unverändert bleiben. Flask sollte zusammen mit Ihrer Datastore-Clientbibliothek (Cloud Datastore oder Cloud NDB) vorhanden sein. Wenn Sie einen anderen WSGI-kompatiblen HTTP-Server wie Gunicorn verwenden möchten (die aktuelle Version ist 20.0.4), dann fügen Sie gunicorn==20.0.4 zu requirements.txt hinzu.

Drittanbieterkonfiguration

App Engine-Entwickler von Python 2 wissen, dass Bibliotheken von Drittanbietern entweder in den Ordner lib kopiert, in requirements.txt referenziert, in app.yaml aufgeführt sind und von appengine_config.py unterstützt werden. Container, wie Python 3-App Engine-Anwendungen, verwenden nur requirements.txt, sodass alle anderen Dinge gelöscht werden können. Wenn Sie also eine 2.x-App Engine-Anwendung haben, löschen Sie appengine_config.py und alle lib-Ordner jetzt.

Starten

Python 2-Nutzer starten den Webserver von App Engine nicht, aber wenn Sie zu einem Container wechseln, müssen Sie dies tun. Fügen Sie dazu eine CMD- oder ENTRYPOINT-Anweisung in Ihre Dockerfile-Datei ein, die angibt, wie die App gestartet werden soll. Dies wird unten auf dieselbe Weise wie für Python 3-Nutzer beschrieben.

Python 3-Nutzer können ihre app.yaml-Dateien so konvertieren, dass sie im Abschnitt handlers eine entrypoint anstelle von script: auto-Anweisungen haben. Wenn Sie entrypoint in Ihrem Python 3-app.yaml verwenden, sieht das in etwa so aus:

runtime: python38
entrypoint: python main.py

Die Anweisung entrypoint teilt App Engine mit, wie der Server gestartet werden soll. Sie können es fast direkt in Ihr Dockerfile verschieben (oder Procfile, wenn Sie Buildpacks [siehe Modul 5] zum Containerisieren Ihrer App verwenden). Zusammenfassung, wo eine Einstiegspunktanweisung zwischen beiden Plattformen eingefügt wird:

  • Docker: Zeile in Dockerfile: ENTRYPOINT ["python", "main.py"]
  • Buildpacks: Zeile in Procfile: web: python main.py

Für Tests ist die Verwendung des Flask-Entwicklungsservers in Ordnung. Wenn Sie jedoch einen Produktionsserver wie gunicorn für Ihre Anwendung verwenden, sollten Sie die ENTRYPOINT- oder CMD-Anweisung darauf verweisen, wie im Cloud Run-Schnellstartbeispiel.

Dateien ignorieren

Wir empfehlen, eine .dockerignore-Datei zu erstellen, um den Container zu kürzen und das Container-Image nicht mit überflüssigen Dateien wie den folgenden zu überladen:

*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__

Anwendungsdateien

Alle Apps in Modul 2 oder Modul 3 sind vollständig mit Python 2-3 kompatibel. Die Kernkomponenten von main.py wurden also nicht geändert. nur ein paar Zeilen Startcode hinzufügen. Fügen Sie am Ende von main.py ein Zeilenpaar hinzu, um den Anwendungsserver zu starten, da für Cloud Run Port 8080 geöffnet sein muss, damit Ihre Anwendung aufgerufen werden kann:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. Erstellen und bereitstellen

Nachdem die Docker-Konfiguration und die Quelldateien aktualisiert wurden, können Sie sie in Cloud Run ausführen. Zuvor möchten wir jedoch noch kurz auf Dienste eingehen.

Dienste und Apps im Vergleich

App Engine wurde in erster Linie zum Hosten von Anwendungen entwickelt, ist aber auch eine Plattform zum Hosten von Webdiensten oder Anwendungen, die aus einer Reihe von Mikrodiensten bestehen. In Cloud Run ist alles ein Dienst, unabhängig davon, ob es sich um einen tatsächlichen Dienst oder eine Anwendung mit einer Weboberfläche handelt. Verwenden Sie es daher als Bereitstellung eines Dienstes und nicht als Anwendung.

Sofern Ihre App Engine-Anwendung nicht aus mehreren Diensten bestand, mussten Sie bei der Bereitstellung Ihrer Anwendungen wirklich keine Benennungen vornehmen. Das ändert sich mit Cloud Run, da Sie einen Dienstnamen festlegen müssen. Während die appspot.com-Domain einer App Engine ihre Projekt-ID enthält, z.B. https://PROJECT_ID.appspot.com, möglicherweise auch die Abkürzung für die Regions-ID, z.B. http://PROJECT_ID.REGION_ID.r.appspot.com.

Die Domain für einen Cloud Run-Dienst enthält jedoch seinen Dienstnamen, die Abkürzung der Regions-ID und einen Hash, aber nicht seine Projekt-ID, z.B. https://SVC_NAME-HASH-REG_ABBR.a.run.app. Fazit: Überlegen Sie sich einen Dienstnamen!

Dienst bereitstellen

Führen Sie den folgenden Befehl aus, um das Container-Image zu erstellen und in Cloud Run bereitzustellen. Wenn Sie dazu aufgefordert werden, wählen Sie Ihre Region aus und lassen Sie zum einfacheren Testen nicht authentifizierte Verbindungen zu. Wählen Sie die passende Region aus, wobei SVC_NAME der Name des Dienstes ist, den Sie bereitstellen.

$ gcloud beta run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision... Deploying Revision.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [SVC_NAME] revision [SVC_NAME-00001-vos] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Rufen Sie die angegebene URL in Ihrem Browser auf, um zu prüfen, ob die Bereitstellung erfolgreich war.

Wie der Befehl gcloud zeigt, können Nutzer verschiedene Standardeinstellungen festlegen, um die Ausgabe und die Interaktivität zu reduzieren (siehe oben). Wenn Sie beispielsweise jede Interaktion vermeiden möchten, können Sie stattdessen den folgenden einzeiligen Bereitstellungsbefehl verwenden:

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

Wenn Sie diesen verwenden, müssen Sie denselben Dienstnamen SVC_NAME und den gewünschten REGION-Namen auswählen, nicht die indexierte Menüauswahl wie oben interaktiv.

6. Zusammenfassung/Bereinigung

Prüfen Sie, ob die Anwendung in Cloud Run wie in App Engine funktioniert. Wenn Sie zu dieser Reihe gesprungen sind, ohne eines der vorherigen Codelabs durchzuführen, ändert sich die App selbst nicht. Alle Besuche der Hauptwebseite (/) werden registriert. Sobald Sie die Website häufig genug besucht haben, sieht sie wie folgt aus:

Besuche App

Ihr Code sollte jetzt mit dem Inhalt im Repository-Ordner des Moduls 4 übereinstimmen, unabhängig davon, ob er 2.x oder 3.x ist. Sie haben dieses Codelab für Modul 4 abgeschlossen.

Optional: Bereinigung

Wie wäre es mit einer Bereinigung, damit Ihnen erst dann Kosten in Rechnung gestellt werden, wenn Sie bereit sind, mit dem nächsten Codelab für die Migration fortzufahren? Da Sie jetzt ein anderes Produkt verwenden, sollten Sie die Preisübersicht zu Cloud Run lesen.

Optional: Dienst deaktivieren

Wenn Sie noch nicht mit der nächsten Anleitung fortfahren möchten, deaktivieren Sie den Dienst, um zusätzliche Kosten zu vermeiden. Wenn Sie bereit sind, mit dem nächsten Codelab fortzufahren, können Sie es wieder aktivieren. Solange Ihre Anwendung deaktiviert ist, wird kein Traffic berechnet. Ihnen können jedoch auch Kosten für die Datenspeichernutzung in Rechnung gestellt werden, wenn sie das kostenlose Kontingent überschreitet. Löschen Sie also so viel, dass Sie unter dieses Limit fallen.

Wenn Sie jedoch nicht mit der Migration fortfahren und alles vollständig löschen möchten, können Sie entweder den Dienst löschen oder das Projekt vollständig herunterfahren.

Nächste Schritte

Herzlichen Glückwunsch, Sie haben Ihre Anwendung containerisiert. Damit ist diese Anleitung abgeschlossen. Im nächsten Schritt erfahren Sie, wie Sie im Codelab für Modul 5 (Link unten) dasselbe mit Cloud-Buildpacks tun oder eine weitere App Engine-Migration durchlaufen:

  • Migrieren Sie zu Python 3, falls noch nicht geschehen. Die Beispiel-App ist bereits mit 2.x und 3.x kompatibel. Die einzige Änderung besteht also darin, dass Docker-Nutzer ihre Dockerfile aktualisieren müssen, um ein Python 3-Image zu verwenden.
  • Modul 5: Mit Cloud Buildpacks zu Cloud Run migrieren
    • Anwendung mit Cloud Buildpacks für die Ausführung in Cloud Run containerisieren
    • Sie müssen nichts über Docker, Container oder Dockerfiles wissen
    • Erfordert, dass Sie Ihre Anwendung bereits zu Python 3 migriert haben
  • Modul 7: App Engine-Push-Aufgabenwarteschlangen (erforderlich, wenn Sie [push]-Aufgabenwarteschlangen verwenden)
    • Fügt App Engine-taskqueue-Push-Aufgaben zur Anwendung in Modul 1 hinzu
    • Bereitet Nutzer auf die Migration zu Cloud Tasks in Modul 8 vor
  • Modul 3:
    • Datastore-Zugriff von Cloud NDB auf Cloud Datastore modernisieren
    • Dies ist die Bibliothek, die für Python 3-Anwendungen in App Engine und Anwendungen verwendet wird, die nicht von App Engine stammen
  • Modul 6: Zu Cloud Firestore migrieren
    • Migrieren Sie zu Cloud Firestore, um auf Firebase-Funktionen zuzugreifen
    • Cloud Firestore unterstützt zwar Python 2, dieses Codelab ist jedoch nur in Python 3 verfügbar.

7. Zusätzliche Ressourcen

Codelabs-Probleme/Feedback mit App Engine-Migrationsmodul

Wenn Sie Probleme mit diesem Codelab feststellen, suchen Sie bitte zuerst nach dem Problem, bevor Sie es einreichen. Links zum Suchen und Erstellen neuer Ausgaben:

Migrationsressourcen

Links zu den Repository-Ordnern für Modul 2 und 3 (START) und Modul 4 (FINISH) finden Sie in der folgenden Tabelle. Sie können auch über das Repository für alle App Engine-Codelab-Migrationen auf sie zugreifen. Sie können eine ZIP-Datei klonen oder herunterladen.

Codelab

Python 2

Python 3

Modul 2

code

(Code)

Modul 3

(Code)

code

Modul 4

code

code

App Engine- und Cloud Run-Ressourcen

Nachfolgend finden Sie zusätzliche Ressourcen zu dieser Migration: