Modul 2: Von App Engine-NDB zu Cloud NDB 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. Der wichtigste Schritt ist die Umstellung von den in der ursprünglichen Laufzeit gebündelten Diensten, da die Laufzeiten der nächsten Generation flexibler sind und Nutzern eine größere Auswahl an Diensten bieten. Durch die Umstellung auf die neuere Generation der Laufzeit können Sie Google Cloud-Produkte einfacher einbinden, eine größere Auswahl an unterstützten Diensten nutzen und aktuelle Sprachversionen unterstützen.

In dieser Anleitung erfahren Sie, wie Sie von der integrierten ndb-Clientbibliothek (Next Database) von App Engine zur Cloud NDB-Clientbibliothek migrieren.

In diesem Kurs lernen Sie, wie Sie

  • App Engine-Bibliothek ndb verwenden (falls Sie damit nicht vertraut sind)
  • Von ndb zu Cloud NDB migrieren
  • Anwendung weiter zu Python 3 migrieren

Voraussetzungen

Umfrage

Wie werden Sie dieses Codelab verwenden?

Nur lesen Lesen und Übungen machen

2. Hintergrund

In Modul 1 haben wir Web-Frameworks vom integrierten webapp2 von App Engine zu Flask migriert. In diesem Codelab entfernen wir uns weiter von den integrierten Diensten von App Engine, indem wir von der ndb-Bibliothek von App Engine zu Cloud NDB von Google wechseln.

Nach Abschluss der Migration haben Sie folgende Möglichkeiten:

  1. Zur Python 3-Laufzeit migrieren
  2. Zu Cloud Datastore migrieren (Clientbibliothek für Nicht-App Engine-Apps)
  3. Containerisieren Sie Ihre Python 2- oder Python 3-Anwendung und migrieren Sie zu Cloud Run.
  4. App Engine-Aufgabenwarteschlangen (Push) hinzufügen und dann zu Cloud Tasks migrieren

Aber wir sind noch nicht so weit. Schließen Sie dieses Codelab ab, bevor Sie sich mit diesen nächsten Schritten befassen. Die Migration in dieser Anleitung umfasst die folgenden Hauptschritte:

  1. Einrichtung/Vorbereitung
  2. Cloud NDB-Bibliothek hinzufügen
  3. Anwendungsdateien aktualisieren

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 1 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 aktiviert ist.

2. Beispiel-App für die Baseline abrufen

Eine der Voraussetzungen ist eine funktionierende Beispiel-App aus Modul 1. Verwenden Sie Ihre Lösung, wenn Sie dieses Tutorial abgeschlossen haben. Sie können es jetzt abschließen (Link oben) oder das Repo für Modul 1 kopieren (Link unten).

Unabhängig davon, ob Sie Ihren oder unseren Code verwenden, ist der Code aus Modul 1 der Ausgangspunkt. In diesem Codelab für Modul 2 werden Sie durch jeden Schritt geführt. Wenn Sie fertig sind, sollte der Code dem Code am ENDE entsprechen (einschließlich einer optionalen Portierung von Python 2 zu Python 3):

Der Codeordner für Modul 1 sollte die folgenden Inhalte haben:

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

Wenn Sie das Tutorial zu Modul 1 durchgearbeitet haben, haben Sie auch einen lib-Ordner mit Flask und seinen Abhängigkeiten. Wenn Sie keinen lib-Ordner haben, erstellen Sie ihn mit dem Befehl pip install -t lib -r requirements.txt, damit wir diese Baseline-App im nächsten Schritt bereitstellen können. Wenn Sie sowohl Python 2 als auch Python 3 installiert haben, empfehlen wir, pip2 anstelle von pip zu verwenden, um Verwechslungen mit Python 3 zu vermeiden.

3. App für Modul 1 (neu) bereitstellen

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

  1. Machen Sie sich (falls erforderlich) noch einmal mit dem gcloud-Befehlszeilentool vertraut.
  2. Modul 1-Code in App Engine (neu) bereitstellen (falls erforderlich)

Sobald Sie diese Schritte ausgeführt und bestätigt haben, dass die Appliance betriebsbereit ist, fahren wir mit dieser Anleitung fort und beginnen mit den Konfigurationsdateien.

4. Konfigurationsdateien aktualisieren (Cloud NDB-Bibliothek hinzufügen)

Viele der ursprünglichen integrierten App Engine-Dienste haben sich zu eigenen Produkten entwickelt. Datastore ist einer davon. Heute können Nicht-App Engine-Apps Cloud Datastore verwenden. Für langjährige ndb-Nutzer hat das Google Cloud-Team die Cloud NDB-Clientbibliothek für die Kommunikation mit Cloud Datastore erstellt. Sie ist sowohl für Python 2 als auch für Python 3 verfügbar.

Wir aktualisieren die Bestätigungsdateien, um App Engine ndb durch Cloud NDB zu ersetzen, und ändern dann unsere Anwendung.

1. requirements.txt aktualisieren

In Modul 1 war Flask die einzige externe Abhängigkeit für unsere App. Jetzt fügen wir Cloud NDB hinzu. So sah Ihre requirements.txt-Datei am Ende von Modul 1 aus:

  • VORHER:
Flask==1.1.2

Für die Migration von App Engine ndb ist die Cloud NDB-Bibliothek (google-cloud-ndb) erforderlich. Fügen Sie daher das Paket zu requirements.txt hinzu.

  • DANACH:
Flask==1.1.2
google-cloud-ndb==1.7.1

Als dieses Codelab geschrieben wurde, war die empfohlene Version 1.7.1. Im Repository requirements.txt ist möglicherweise eine neuere Version verfügbar. Wir empfehlen die neuesten Versionen der einzelnen Bibliotheken. Wenn diese nicht funktionieren, können Sie jedoch zu einer älteren Version zurückkehren.

Löschen Sie den Ordner lib, falls er vorhanden ist und Sie ihn nicht gerade erstellt haben. Installieren Sie die aktualisierten Bibliotheken jetzt mit dem Befehl pip install -t lib -r requirements.txt neu. Verwenden Sie dabei nach Bedarf pip2 anstelle von pip.

2. app.yaml aktualisieren

Das Hinzufügen von Google Cloud-Clientbibliotheken wie google-cloud-ndb unterliegt einigen Anforderungen, die sich alle auf die Einbeziehung von integrierten Bibliotheken beziehen, also Drittanbieterpaketen, die bereits auf Google-Servern verfügbar sind. Sie werden weder in requirements.txt aufgeführt noch mit pip install kopiert. Die einzigen Anforderungen:

  1. Integrierte Bibliotheken in app.yaml angeben
  2. Verweisen Sie sie auf kopierte Drittanbieterbibliotheken, mit denen sie möglicherweise arbeiten (in lib).

Hier ist der START von app.yaml aus Modul 1:

  • VORHER:
runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

Fügen Sie nun die folgenden Zeilen zu app.yaml hinzu, um in einem neuen Abschnitt libraries auf ein Paar gebündelter Drittanbieterpakete zu verweisen: grpcio und setuptools:

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

Warum sollten Sie diese integrierten Bibliotheken verwenden? gRPC ist ein offenes RPC-Framework, das von allen Google Cloud-Clientbibliotheken verwendet wird, einschließlich google-cloud-ndb. Die grpcio-Bibliothek ist der Python-gRPC-Adapter und daher erforderlich. Die Begründung für die Einbeziehung von setuptools folgt.

  • DANACH:

Mit den oben genannten Änderungen sollte die aktualisierte Datei app.yaml jetzt so aussehen:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

3. appengine_config.py aktualisieren

Mit dem Tool pkg_resources, das Teil der Bibliothek setuptools ist, können integrierte Drittanbieterbibliotheken auf die gebündelten Bibliotheken zugreifen. Aktualisieren Sie appengine_config.py, sodass pkg_resources verwendet wird, um auf die gebündelten Bibliotheken in lib zu verweisen. Wenn Sie diese Änderung vorgenommen haben, sollte die gesamte Datei so aussehen:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

5. Anwendungsdateien aktualisieren

Nachdem Sie die Formalitäten für die Konfigurationsdatei erledigt haben, können Sie jetzt von ndb zu Cloud NDB migrieren. Aktualisieren Sie importierte Bibliotheken und fügen Sie die Verwendung der Kontextverwaltung in main.py hinzu, um die Migration abzuschließen.

1. Importe

Nehmen Sie in main.py die folgenden Änderungen vor:

  • VORHER
from google.appengine.ext import ndb
  • DANACH:
from google.cloud import ndb

Der Wechsel von einer App Engine-Bibliothek zu einer Google Cloud-Bibliothek kann manchmal so subtil sein wie in diesem Beispiel. Bei integrierten Diensten, die zu vollständigen Google Cloud-Produkten geworden sind, importieren Sie Attribute aus google.cloud anstelle von google.appengine.

2. Datastore-Zugriff

Damit Sie die Cloud NDB-Bibliothek verwenden können, muss Ihre App Python-Kontextmanager verwenden. Sie sollen den Zugriff auf Ressourcen so „beschränken“, dass sie erst erworben werden müssen, bevor sie verwendet werden können. Kontextmanager basieren auf der in der Informatik bekannten Steuerungstechnik Resource Allocation Is Initialization (RAII) (Ressourcenzuweisung ist Initialisierung). Kontextmanager werden mit Python-Dateien verwendet, die geöffnet werden müssen, bevor auf sie zugegriffen werden kann. Bei der Parallelität müssen Spinlocks abgerufen werden, bevor Code in einem kritischen Abschnitt ausgeführt werden kann.

Ebenso müssen Sie bei Cloud NDB den Kontext eines Clients abrufen, um mit Datastore zu kommunizieren, bevor Datastore-Befehle ausgeführt werden können. Erstellen Sie zuerst einen Client (ndb.Client()), indem Sie ds_client = ndb.Client() in main.py unmittelbar nach der Flask-Initialisierung hinzufügen:

app = Flask(__name__)
ds_client = ndb.Client()

Der Python-Befehlwithwird nur verwendet, um den Kontext eines Objekts abzurufen. Schließen Sie alle Codeblöcke, die auf Datastore zugreifen, in with-Anweisungen ein.

Unten sehen Sie dieselben Funktionen aus Modul 1 zum Schreiben einer neuen Entität in den Datenspeicher und zum Lesen, um die zuletzt hinzugefügten Entitäten anzuzeigen:

  • VORHER:

Hier ist der ursprüngliche Code ohne Kontextverwaltung:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return (v.to_dict() for v in Visit.query().order(
            -Visit.timestamp).fetch(limit))
  • DANACH:

Fügen Sie nun with ds_client.context(): hinzu und verschieben Sie den Code für den Datastore-Zugriff in den with-Block:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return (v.to_dict() for v in Visit.query().order(
                -Visit.timestamp).fetch(limit))

Die Haupttreiberanwendung bleibt unverändert gegenüber Modul 1, da hier kein ndb-Code (oder Cloud NDB-Code) vorhanden ist:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

Es empfiehlt sich, eine klare Trennung zwischen Anwendungscode und Datenzugriff zu schaffen. So ändert sich der Hauptanwendungscode nicht, wenn der zugrunde liegende Datenspeichermechanismus geändert wird, wie es bei dieser Migration der Fall war.

6. Zusammenfassung/Bereinigung

Anwendung bereitstellen

Stellen Sie die App mit gcloud app deploy noch einmal bereit und prüfen Sie, ob sie funktioniert. Ihr Code sollte jetzt mit dem Code im Modul 2-Repository übereinstimmen.

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:

visitme app

Herzlichen Glückwunsch zum Abschluss dieses Codelabs für Modul 2. Sie haben es geschafft. Dies ist die letzte der dringend empfohlenen Migrationen in dieser Reihe, was Datastore betrifft.

Optional: Bereinigen

Was ist mit der Bereinigung, um Gebühren zu vermeiden, bis Sie bereit sind, mit dem nächsten Migrations-Codelab fortzufahren? Als bestehende Entwickler sind Sie wahrscheinlich bereits mit den Preisinformationen für App Engine vertraut.

Optional: App deaktivieren

Wenn Sie noch nicht mit dem nächsten Tutorial fortfahren möchten, deaktivieren Sie Ihre App, um 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 Ihr Projekt beenden.

Nächste Schritte

Von hier aus haben Sie verschiedene Möglichkeiten. Wählen Sie eine der folgenden Optionen aus:

  • Bonus für Modul 2:Fahren Sie unten mit dem Bonusabschnitt dieses Tutorials fort, um die Migration zu Python 3 und die nächste Generation der App Engine-Laufzeit zu erkunden.
  • 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 4:Mit Docker zu Cloud Run migrieren 
    • Anwendung mit Docker für die Ausführung in Cloud Run containerisieren
    • Sie können weiterhin Python 2 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 Dockerfile wissen.
    • Sie müssen Ihre App bereits zu Python 3 migriert haben.
  • 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.

7. BONUS: Zu Python 3 migrieren

Wenn Sie auf die neueste App Engine-Laufzeitumgebung und die neuesten Funktionen zugreifen möchten, empfehlen wir Ihnen, zu Python 3 zu migrieren. In unserer Beispielanwendung war Datastore der einzige integrierte Dienst, den wir verwendet haben. Da wir von ndb zu Cloud NDB migriert sind, können wir jetzt zur Python 3-Laufzeit von App Engine portieren.

Übersicht

Die Portierung zu Python 3 fällt nicht in den Rahmen eines Google Cloud-Tutorials. In diesem Teil des Codelabs erhalten Entwickler jedoch einen Eindruck davon, wie sich die Python 3-App Engine-Laufzeitumgebung unterscheidet. Ein herausragendes Merkmal der Runtime der nächsten Generation ist der vereinfachte Zugriff auf Drittanbieterpakete. Es ist nicht erforderlich, integrierte Pakete in app.yaml anzugeben, und es ist auch nicht erforderlich, nicht integrierte Bibliotheken zu kopieren oder hochzuladen. Sie werden implizit installiert, wenn sie in requirements.txt aufgeführt sind.

Da unser Beispiel so einfach ist und Cloud NDB mit Python 2 und 3 kompatibel ist, muss kein Anwendungscode explizit zu 3.x portiert werden. Die Anwendung wird unverändert unter 2.x und 3.x ausgeführt. Die einzigen erforderlichen Änderungen sind in diesem Fall die Konfiguration:

  1. Vereinfachen Sie app.yaml, um auf Python 3 zu verweisen und Bibliotheken von Drittanbietern zu entfernen.
  2. Löschen Sie appengine_config.py und den Ordner lib, da sie nicht mehr benötigt werden.

Zusätzlich zu main.py bleiben die Dateien requirements.txt und templates/index.html unverändert.

app.yaml vereinfachen

VORHER:

Die einzige wirkliche Änderung für diese Beispiel-App besteht darin, app.yaml deutlich zu verkürzen. Zur Erinnerung: Das hatten wir in app.yaml am Ende von Modul 2:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

DANACH:

In Python 3 sind die Direktiven threadsafe, api_version und libraries alle veraltet. Alle Apps gelten als threadsicher und api_version wird in Python 3 nicht verwendet. In App Engine-Diensten sind keine integrierten Drittanbieterpakete mehr vorinstalliert. Daher ist auch libraries veraltet. Weitere Informationen zu diesen Änderungen finden Sie in der Dokumentation zu Änderungen an app.yaml. Daher sollten Sie alle drei aus app.yaml löschen und auf eine unterstützte Python 3-Version aktualisieren (siehe unten).

Optional: Verwendung der handlers-Anweisung

Außerdem wurde die handlers-Anweisung, mit der Traffic an App Engine-Anwendungen weitergeleitet wird, eingestellt. Da die Next-Gen-Laufzeitumgebung erwartet, dass Web-Frameworks das App-Routing verwalten, müssen alle „Handler-Skripts“ in „auto“ geändert werden. Wenn Sie die Änderungen von oben kombinieren, erhalten Sie Folgendes: app.yaml:

runtime: python38

handlers:
- url: /.*
  script: auto

Weitere Informationen zu script: auto

Entfernen der handlers-Anweisung

Da handlers veraltet ist, können Sie auch den gesamten Abschnitt entfernen und nur eine einzeilige app.yaml beibehalten:

runtime: python38

Standardmäßig wird der Gunicorn WSGI-Webserver gestartet, der für alle Anwendungen verfügbar ist. Wenn Sie mit gunicorn vertraut sind, ist dies der Befehl, der ausgeführt wird, wenn er standardmäßig mit dem Barebone app.yaml gestartet wird:

gunicorn main:app --workers 2 -c /config/gunicorn.py

Optional: Verwendung der entrypoint-Anweisung

Wenn Ihre Anwendung jedoch einen bestimmten Startbefehl erfordert, kann dieser mit einer entrypoint-Anweisung angegeben werden. Ihr app.yaml würde dann so aussehen:

runtime: python38
entrypoint: python main.py

In diesem Beispiel wird speziell der Flask-Entwicklungsserver anstelle von gunicorn angefordert. Außerdem muss Code zum Starten des Entwicklungsservers in Ihre App eingefügt werden, damit sie über die 0.0.0.0-Schnittstelle auf Port 8080 gestartet wird. Fügen Sie dazu diesen kleinen Abschnitt am Ende von main.py ein:

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080, debug=True)

Weitere Informationen zu entrypoint Weitere Beispiele und Best Practices finden Sie in der Dokumentation zum Starten von App Engine Standard und in der Dokumentation zum Starten von App Engine Flexible.

Löschen Sie appengine_config.py und lib.

Löschen Sie die Datei appengine_config.py und den Ordner lib. Bei der Migration zu Python 3 ruft App Engine die in requirements.txt aufgeführten Pakete ab und installiert sie.

Die Konfigurationsdatei appengine_config.py wird verwendet, um Bibliotheken/Pakete von Drittanbietern zu erkennen, unabhängig davon, ob Sie sie selbst kopiert haben oder bereits auf App Engine-Servern verfügbare (integrierte) Bibliotheken/Pakete verwenden. Beim Umstieg auf Python 3 sind die wichtigsten Änderungen:

  1. Keine Bündelung kopierter Drittanbieterbibliotheken (siehe requirements.txt)
  2. Kein pip install in einem lib-Ordner, d. h. kein lib-Ordnerzeitraum
  3. Keine integrierten Drittanbieterbibliotheken in app.yaml aufgeführt
  4. Es ist nicht erforderlich, in der App auf Drittanbieterbibliotheken zu verweisen. Daher ist keine appengine_config.py-Datei erforderlich.

Es reicht aus, alle erforderlichen Drittanbieterbibliotheken in requirements.txt aufzulisten.

Anwendung bereitstellen

Stellen Sie die App noch einmal bereit, um sicherzugehen, dass sie funktioniert. Sie können auch prüfen, wie nah Ihre Lösung am Python 3-Beispielcode für Modul 2 ist. Um die Unterschiede zu Python 2 zu visualisieren, vergleichen Sie den Code mit der Python 2-Version.

Herzlichen Glückwunsch zum Abschluss des Bonusschritts in Modul 2! Dokumentation zum Vorbereiten von Konfigurationsdateien für die Python 3-Laufzeit Sehen Sie sich abschließend die Seite „Zusammenfassung/Bereinigung“ an, um die nächsten Schritte und die Bereinigung zu prüfen.

Ihren Antrag vorbereiten

Wenn es an der Zeit ist, Ihre Anwendung zu migrieren, müssen Sie Ihre main.py- und anderen Anwendungsdateien zu Version 3.x portieren. Es empfiehlt sich daher, Ihre 2.x-Anwendung so „zukunftssicher“ wie möglich zu gestalten.

Dazu gibt es viele Online-Ressourcen. Hier sind einige wichtige Tipps:

  1. Alle Anwendungsabhängigkeiten müssen vollständig mit Version 3.x kompatibel sein.
  2. Achten Sie darauf, dass Ihre Anwendung mindestens auf Version 2.6 (vorzugsweise 2.7) ausgeführt wird.
  3. Sicherstellen, dass die Anwendung die gesamte Testsuite besteht (und eine Mindestabdeckung von 80% erreicht)
  4. Verwenden Sie Kompatibilitätsbibliotheken wie six, Future und/oder Modernize.
  5. Wichtige nicht abwärtskompatible Unterschiede zwischen Version 2.x und Version 3.x
  6. Bei jeder Ein-/Ausgabe kommt es wahrscheinlich zu Inkompatibilitäten zwischen Unicode- und Byte-Strings.

Die Beispiel-App wurde unter Berücksichtigung all dieser Aspekte entwickelt. Daher kann sie sofort unter 2.x und 3.x ausgeführt werden. So können wir uns darauf konzentrieren, Ihnen zu zeigen, was geändert werden muss, um die Plattform der nächsten Generation zu verwenden.

8. 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:

Migrationsressourcen

Links zu den Repository-Ordnern für Modul 1 (START) und Modul 2 (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 1

code

(n/a)

Modul 2

code

code

App Engine-Ressourcen

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