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

1. Übersicht

Diese Reihe von Codelabs (Tutorials zum selbstbestimmten Lernen) soll Google App Engine-Entwicklern (Standard) helfen, ihre Apps zu modernisieren, indem sie durch eine Reihe von Migrationen geführt werden. Danach können Nutzer ihre Apps portabler machen, indem sie sie explizit für Cloud Run, den Container-Hosting-Dienst von Google Cloud, der App Engine ähnelt, und andere Container-Hosting-Dienste containerisieren.

In dieser Anleitung erfahren Sie, wie Sie App Engine-Anwendungen für die Bereitstellung im vollständig verwalteten Cloud Run-Dienst mit Docker containerisieren. Docker ist eine bekannte Plattform in der Branche zum Entwickeln, Bereitstellen und Ausführen von Anwendungen in Containern. Für Python 2-Entwickler BEGINNT dieses Tutorial mit der App Engine-Beispielanwendung für Modul 2 Cloud NDB, während Python 3-Entwickler mit dem Cloud Datastore-Beispiel für Modul 3 BEGINNEN.

HINWEIS:Eine Herausforderung bei Docker ist die Erstellung eines effizienten Dockerfile. Das Erstellen, Bereitstellen, Starten und Ausführen von suboptimalen Container-Images dauert länger. Cloud Buildpacks sind eine Alternative zu Docker. Sie entsprechen der offenen Cloud Native-Spezifikation Buildpacks, verwenden Introspection, um Anwendungsabhängigkeiten zu ermitteln, und erstellen die effizientesten Container-Images. Wenn Sie neu im Bereich Container sind und/oder ein weiteres Ökosystem vermeiden möchten, das Sie lernen müssen, können Sie diese Anleitung überspringen und stattdessen im Codelab zu Modul 5: Mit Cloud Buildpacks von Google App Engine zu Cloud Run migrieren erfahren, wie Sie Ihre App mit Cloud Buildpacks in einen Container packen.

In diesem Kurs lernen Sie, wie Sie

• Anwendung mit Docker containerisieren
• Container-Images für Cloud Run bereitstellen

Voraussetzungen

• Ein Google Cloud Platform-Projekt mit:
  • Ein aktives GCP-Rechnungskonto
  • App Engine aktiviert
• Grundlegende Python-Kenntnisse
• Grundkenntnisse zu gängigen Linux-Befehlen
• Grundlegende Kenntnisse zur Entwicklung und Bereitstellung von App Engine-Anwendungen
• Empfohlen: Codelab für Modul 2 oder Codelab für Modul 3 durcharbeiten
• Eine funktionierende App Engine-Anwendung, die containerisiert werden kann
  • Python 2: Cloud NDB-Beispiel für Modul 2
  • Python 3: Cloud Datastore-Beispiel für Modul 3

Umfrage

Wie werden Sie dieses Codelab verwenden?

Nur lesen Lesen und Übungen machen

2. Hintergrund

PaaS-Systeme wie App Engine und Cloud Functions bieten viele Vorteile für Ihr Team und Ihre Anwendung. Mit diesen serverlosen Plattformen können sich Systemadministratoren und DevOps-Teams beispielsweise auf die Entwicklung von Lösungen konzentrieren. Ihre App kann bei Bedarf automatisch hochskaliert und auf null herunterskaliert werden. Die nutzungsbasierte Abrechnung hilft Ihnen, die Kosten im Blick zu behalten. Außerdem werden verschiedene gängige Entwicklungssprachen unterstützt.

Die Flexibilität von Containern ist jedoch auch überzeugend, da Sie jede Sprache, jede Bibliothek und jedes Binärprogramm auswählen können. Google Cloud Run bietet Nutzern das Beste aus beiden Welten: den Komfort von Serverless in Kombination mit der Flexibilität von Containern.

Die Verwendung von Cloud Run ist nicht Gegenstand dieses Codelabs. Informationen dazu finden Sie in der Cloud Run-Dokumentation. Ziel ist es, dass Sie wissen, wie Sie Ihre App Engine-Anwendung für Cloud Run (oder andere Dienste) in einen Container packen. Bevor Sie fortfahren, sollten Sie einige Dinge wissen. Vor allem wird sich die Nutzerfreundlichkeit etwas ändern, da Sie nicht mehr Anwendungscode verwenden und bereitstellen.

Stattdessen müssen Sie etwas über Container lernen, z. B. wie Sie sie erstellen und bereitstellen. Sie können auch entscheiden, was Sie in das Container-Image aufnehmen möchten, z. B. einen Webserver, da Sie den Webserver von App Engine nicht mehr verwenden. Wenn Sie diesen Weg nicht gehen möchten, ist es keine schlechte Option, Ihre Apps in App Engine zu behalten.

In dieser Anleitung erfahren Sie, wie Sie Ihre App in einen Container packen, App Engine-Konfigurationsdateien durch Containerkonfiguration ersetzen, festlegen, was in den Container kommt, und angeben, wie Ihre App gestartet werden soll. Viele dieser Dinge werden automatisch von App Engine erledigt.

Diese Migration umfasst die folgenden Schritte:

1. Einrichtung/Vorbereitung
2. Anwendung
   containerisieren
   • Konfigurationsdateien ersetzen
   • Anwendungsdateien ändern

3. Einrichtung/Vorbereitung

Bevor wir mit dem Hauptteil des Tutorials beginnen, richten wir unser Projekt ein, rufen den Code ab und stellen die Baseline-App bereit, damit wir wissen, dass wir mit funktionierendem Code begonnen haben.

1. Projekt einrichten

Wenn Sie das Codelab zu Modul 2 oder Modul 3 abgeschlossen haben, empfehlen wir, dasselbe Projekt (und denselben Code) wiederzuverwenden. Alternativ können Sie ein neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Prüfen Sie, ob das Projekt ein aktives Abrechnungskonto hat und App Engine (App) aktiviert ist.

2. Beispiel-App für die Baseline abrufen

Eine der Voraussetzungen für dieses Codelab ist eine funktionierende Beispiel-App aus Modul 2 oder Modul 3. Wenn Sie keine haben, führen Sie eines der beiden Tutorials (Links oben) durch, bevor Sie hier fortfahren. Wenn Sie bereits mit den Inhalten vertraut sind, können Sie einfach den Code für Modul 2 oder 3 unten kopieren.

Unabhängig davon, ob Sie Ihren oder unseren Code verwenden, beginnen wir für die Python 2-Version dieser Anleitung mit dem Code aus Modul 2 und für Python 3 mit dem Code aus Modul 3. In diesem Codelab zu Modul 4 werden Sie durch jeden Schritt geführt. Je nach Ihren Optionen sollten Sie am Ende Code erhalten, der einem der Repository-Ordner für Modul 4 (FINISH) ähnelt.

• Python 2 (Cloud NDB-App)
  • START: Modul 2-Code
  • ABSCHLUSS: Code für Modul 4
• Python 3 (Cloud Datastore-App)
  • START: Modul 3-Code
  • ABSCHLUSS: Code für Modul 4
• Gesamtes Repository (zum Klonen oder Herunterladen als ZIP-Datei)

Das Verzeichnis der START-Dateien für Python 2, Modul 2 (Ihre oder unsere) sollte so 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. Der START-Code für Modul 3 (3.x) sollte so aussehen:

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

3. Referenz-App (erneut) bereitstellen

Das sind die verbleibenden Schritte, die Sie jetzt ausführen müssen:

1. gcloud-Befehlszeilentool
2. Beispiel-App mit gcloud app deploy noch einmal bereitstellen
3. Prüfen, ob die App problemlos in App Engine ausgeführt wird

Sobald Sie diese Schritte ausgeführt haben, können Sie die Anwendung in einen Container packen.

4. Anwendung containerisieren

Docker ist heute die Standardplattform für die Containerisierung in der Branche. Eine Herausforderung bei der Verwendung von Cloud Build besteht darin, dass es, wie bereits erwähnt, Aufwand erfordert, ein effizientes Dockerfile zu erstellen. Diese Konfigurationsdatei bestimmt, wie Ihre Container-Images erstellt werden. Buildpacks erfordern dagegen nur wenig Aufwand, da sie die Abhängigkeiten Ihrer App durch Introspection ermitteln und den Buildpacks-Container so effizient wie möglich für Ihre App gestalten.

Sie sind hier richtig, wenn Sie bereits mit Containern und Docker vertraut sind und mehr darüber erfahren möchten, wie Sie Ihre App Engine-Anwendung für Cloud Run containerisieren. Sie können danach auch das Codelab für Modul 5 durcharbeiten, das mit diesem identisch ist, aber Cloud Buildpacks verwendet. Unsere Minimalbeispiel-App ist so schlank, dass einige der oben genannten Dockerfile-Probleme vermieden werden.

Bei der Migration müssen Sie die App Engine-Konfigurationsdateien ersetzen und angeben, wie Ihre App gestartet werden soll. In der folgenden Tabelle sind die Konfigurationsdateien zusammengefasst, die für die einzelnen Plattformtypen zu erwarten sind. Vergleichen Sie die App Engine-Spalte mit der Docker-Spalte (und optional mit Buildpacks):

Beschreibung	App Engine	Docker	Buildpacks
Allgemeine Konfiguration	app.yaml	Dockerfile	(service.yaml)
Drittanbieterbibliotheken	requirements.txt	requirements.txt	requirements.txt
Drittanbieterkonfiguration	app.yaml (sowie appengine_config.py und lib [nur Version 2.x])	(n/a)	(n/a)
Starten	(n. v.) oder app.yaml (falls entrypoint verwendet wird)	Dockerfile	Procfile
Dateien ignorieren	.gcloudignore und .gitignore	.gcloudignore, .gitignore und .dockerignore	.gcloudignore und .gitignore

Sobald Ihre App containerisiert ist, kann sie in Cloud Run bereitgestellt werden. Zu den anderen Google Cloud-Containerplattformen gehören Compute Engine, GKE und Anthos.

Allgemeine Konfiguration

Bei der Migration von App Engine muss app.yaml durch ein Dockerfile ersetzt werden, in dem beschrieben wird, wie der Container erstellt und ausgeführt wird. 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. Dort finden Sie auch ein Beispiel für Dockerfile, das gunicorn startet.

Eine Alternative zur Verwendung von ENTRYPOINT oder CMD in einem Dockerfile ist die Verwendung eines Procfile. Eine .dockerignore-Datei hilft, Dateien, die nicht zur App gehören, herauszufiltern, um die Containergröße zu reduzieren. Weitere Informationen dazu folgen.

app.yaml löschen und Dockerfile erstellen

Die app.yaml wird in Containern nicht verwendet. Löschen Sie sie jetzt. Die Containerkonfigurationsdatei ist Dockerfile. Für unsere Beispiel-App ist nur eine minimale Konfiguration erforderlich. Erstellen Sie Ihre Dockerfile mit diesem Inhalt und ersetzen Sie 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"]

Der Großteil von Dockerfile gibt an, wie der Container erstellt werden soll, mit Ausnahme von ENTRYPOINT, das angibt, wie der Container gestartet werden soll. 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 Basis-Image an, mit dem begonnen werden soll. „slim“ bezieht sich auf eine minimale Python-Distribution. Weitere Informationen finden Sie auf der Seite Docker Python images.

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

Drittanbieterbibliotheken

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 zum Zeitpunkt der Erstellung dieses Dokuments ist 20.0.4), fügen Sie gunicorn==20.0.4 zu requirements.txt hinzu.

Drittanbieterkonfiguration

Python 2-App Engine-Entwickler wissen, dass Drittanbieterbibliotheken entweder in den Ordner lib kopiert, in requirements.txt referenziert, in app.yaml aufgeführt und von appengine_config.py unterstützt werden. Container wie Python 3-App Engine-Apps verwenden nur requirements.txt. Alle anderen Elemente können also entfernt werden. Wenn Sie eine App Engine-App der Version 2.x haben, löschen Sie jetzt appengine_config.py und alle lib-Ordner.

Starten

Python 2-Nutzer starten den Webserver von App Engine nicht. Wenn Sie jedoch zu einem Container wechseln, müssen Sie dies tun. Dazu fügen Sie in Ihrer Dockerfile eine CMD- oder ENTRYPOINT-Anweisung hinzu, in der angegeben wird, wie Ihre App gestartet werden soll. Dies wird unten auf dieselbe Weise wie für Python 3-Nutzer beschrieben.

Python 3-Nutzer haben die Möglichkeit, ihre app.yaml-Dateien so zu konvertieren, dass sie im Abschnitt handlers anstelle von script: auto-Anweisungen entrypoint-Anweisungen enthalten. Wenn Sie entrypoint in Ihrem Python 3-app.yaml verwenden, sieht das so aus:

runtime: python38
entrypoint: python main.py

Die entrypoint-Anweisung gibt an, wie App Engine den Server starten soll. Sie können sie fast direkt in Ihr Dockerfile (oder Procfile, wenn Sie Buildpacks [siehe Modul 5] zum Containerisieren Ihrer App verwenden) verschieben. Hier sehen Sie, wo eine Einstiegspunkt-Anweisung auf den beiden Plattformen platziert werden würde:

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

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

Dateien ignorieren

Wir empfehlen, eine .dockerignore-Datei zu erstellen, um die Größe Ihres Containers zu reduzieren und Ihr Container-Image nicht mit überflüssigen Dateien wie den folgenden zu überladen:

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

Anwendungsdateien

Alle Apps aus Modul 2 oder Modul 3 sind vollständig mit Python 2 und Python 3 kompatibel. Das bedeutet, dass sich an den Kernkomponenten von main.py nichts ändert. Wir fügen nur einige Zeilen Startcode hinzu. Fügen Sie unten in main.py ein Zeilenpaar hinzu, um den Entwicklungsserver zu starten. Cloud Run erfordert, dass Port 8080 geöffnet ist, damit Ihre App 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 Sie die Docker-Konfiguration und die Quelldateien aktualisiert haben, können Sie die Anwendung in Cloud Run ausführen. Bevor wir dazu kommen, möchten wir kurz auf Dienste eingehen.

Dienste und Apps

App Engine wurde zwar in erster Linie für das Hosting von Anwendungen entwickelt, ist aber auch eine Plattform für das Hosting von Webdiensten oder Anwendungen, die aus einer Sammlung 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. Die Verwendung sollte daher als Bereitstellung eines Dienstes und nicht einer Anwendung betrachtet werden.

Sofern Ihre App Engine-Anwendung nicht aus mehreren Diensten bestand, mussten Sie bei der Bereitstellung Ihrer Anwendungen keine Namensgebung vornehmen. Das ändert sich bei Cloud Run, wo Sie einen Dienstnamen angeben müssen. Die appspot.com-Domain einer App Engine-Anwendung enthält die Projekt-ID, z.B. https://PROJECT_ID.appspot.com, und möglicherweise die Abkürzung der Regions-ID, z.B. http://PROJECT_ID.REGION_ID.r.appspot.com.

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

Dienst bereitstellen

Führen Sie den folgenden Befehl aus, um Ihr Container-Image zu erstellen und in Cloud Run bereitzustellen. Wählen Sie bei Aufforderung Ihre Region aus und erlauben Sie nicht authentifizierte Verbindungen, um das Testen zu erleichtern. Wählen Sie Ihre Region entsprechend aus. Dabei ist SVC_NAME der Name des Dienstes, 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 bestätigen, dass die Bereitstellung erfolgreich war.

Wie der Befehl gcloud zeigt, können Nutzer verschiedene Standardeinstellungen festlegen, um die Ausgabe und Interaktivität wie oben beschrieben zu reduzieren. Um beispielsweise jegliche Interaktion zu vermeiden, können Sie stattdessen den folgenden Einzeilen-Bereitstellungsbefehl verwenden:

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

Wenn Sie diesen verwenden, wählen Sie unbedingt denselben Dienstnamen SVC_NAME und den gewünschten REGION Namen aus und nicht die indexierte Menüauswahl wie oben.

6. Zusammenfassung/Bereinigung

Prüfen Sie, ob die App in Cloud Run wie in App Engine funktioniert. Wenn Sie diese Reihe ohne die vorherigen Codelabs durchgearbeitet haben, ändert sich die App selbst nicht. Sie erfasst alle Besuche der Hauptwebseite (/) und sieht so aus, wenn Sie die Website oft genug besucht haben:

Ihr Code sollte jetzt mit dem Code im Repo-Ordner für Modul 4 übereinstimmen, unabhängig davon, ob es sich um 2.x oder 3.x handelt. Herzlichen Glückwunsch zum Abschluss dieses Codelabs für Modul 4.

Optional: Bereinigen

Was ist mit der Bereinigung, um Gebühren zu vermeiden, bis Sie bereit sind, mit dem nächsten Migrations-Codelab fortzufahren? Da Sie jetzt ein anderes Produkt verwenden, sollten Sie sich den Cloud Run-Preisleitfaden ansehen.

Optional: Dienst deaktivieren

Wenn Sie noch nicht mit dem nächsten Tutorial fortfahren möchten, deaktivieren Sie den Dienst, um zusätzliche Kosten zu vermeiden. Wenn Sie mit dem nächsten Codelab fortfahren möchten, können Sie es wieder aktivieren. Wenn Ihre App deaktiviert ist, fallen keine Gebühren für Traffic an. Allerdings können Ihnen Gebühren für die Datastore-Nutzung in Rechnung gestellt werden, wenn diese das kostenlose Kontingent überschreitet. Löschen Sie daher genügend Daten, um unter diesem Limit zu bleiben.

Wenn Sie die Migrationen nicht fortsetzen und alles vollständig löschen möchten, können Sie entweder Ihren Dienst löschen oder Ihr Projekt vollständig beenden.

Nächste Schritte

Herzlichen Glückwunsch! Sie haben Ihre App containerisiert und damit dieses Tutorial abgeschlossen. Der nächste Schritt besteht darin, zu erfahren, wie Sie dasselbe mit Cloud Buildpacks im Codelab für Modul 5 (Link unten) tun können, oder eine andere App Engine-Migration durchzuführen:

• Migrieren Sie zu Python 3, falls noch nicht geschehen. Die Beispiel-App ist bereits mit 2.x und 3.x kompatibel. Die einzige Änderung für Docker-Nutzer besteht darin, Dockerfile zu aktualisieren, damit ein Python 3-Image verwendet wird.
• 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 Dockerfile wissen.
  • Sie müssen Ihre App bereits zu Python 3 migriert haben.
• Modul 7:App Engine-Push-Aufgabenwarteschlangen (erforderlich, wenn Sie [Push-]Aufgabenwarteschlangen verwenden)
  • Fügt der App in Modul 1 taskqueue-Push-Aufgaben für App Engine hinzu
  • Bereitet Nutzer auf die Migration zu Cloud Tasks in Modul 8 vor.
• Modul 3:
  • Datastore-Zugriff von Cloud NDB auf Cloud Datastore modernisieren
  • Diese Bibliothek wird für Python 3-App Engine-Anwendungen und Nicht-App Engine-Anwendungen verwendet.
• Modul 6:Zu Cloud Firestore migrieren
  • Zu Cloud Firestore migrieren, 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

Probleme/Feedback zu Codelabs für das App Engine-Migrationsmodul

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

• Issue-Tracker für die App Engine-Migrations-Codelabs
  • Nach Problemen suchen
  • Neues Problem/Feedback einreichen

Migrationsressourcen

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

Codelab	Python 2	Python 3
Modul 2	code	(Code)
Modul 3	(Code)	code
Modul 4	code	code

App Engine- und Cloud Run-Ressourcen

Unten finden Sie zusätzliche Ressourcen zu dieser speziellen Migration:

• Container 
  • Google Cloud Run
  • Google Cloud Build
  • Google Cloud Container Registry
  • Docker
  • Cloud Buildpacks-Blogpost
  • Cloud Buildpacks deploy post
  • Cloud Buildpacks-Repository
  • CNCF Buildpacks-Spezifikation
  • Tool zur Migration von App Engine zu Cloud Run – zum Generieren Ihrer eigenen service.yaml
• Allgemein
  • Python auf der Google Cloud Platform
  • Google Cloud Python-Clientbibliotheken