Modul 3: Von Google Cloud NDB zu Cloud Datastore migrieren

1. Übersicht

Diese Reihe von Codelabs (selbstgesteuerte, praktische Anleitungen) soll Google App Engine-Entwicklern (Standardumgebung) helfen, ihre Apps zu modernisieren. Dazu werden sie durch eine Reihe von Migrationen geführt. 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 optionalen Anleitung wird Entwicklern gezeigt, wie sie von Cloud NDB zu Cloud Datastore als Clientbibliothek für die Kommunikation mit dem Datastore-Dienst migrieren. Entwickler, die NDB bevorzugen, können es weiterhin verwenden, da es mit Python 3 kompatibel ist. Daher ist diese Migration optional. Diese Migration ist nur für Entwickler gedacht, die eine konsistente Codebasis und freigegebene Bibliotheken mit anderen Apps erstellen möchten, die bereits Cloud Datastore verwenden. Dies wird im Abschnitt „Hintergrund“ erläutert.

In diesem Kurs lernen Sie, wie Sie

  • Cloud NDB verwenden (wenn Sie damit nicht vertraut sind)
  • Von Cloud NDB zu Cloud Datastore migrieren
  • Anwendung weiter zu Python 3 migrieren

Voraussetzungen

  • Ein Google Cloud Platform-Projekt mit einem aktiven GCP-Abrechnungskonto
  • Grundlegende Python-Kenntnisse
  • Grundkenntnisse zu grundlegenden Linux-Befehlen
  • Grundlegende Kenntnisse der Entwicklung und Bereitstellung von App Engine-Anwendungen
  • Eine funktionierende App Engine-App des Moduls 2 mit 2.x oder 3.x.

Umfrage

Wie werden Sie dieses Codelab verwenden?

Nur lesen Lesen und Übungen machen

2. Hintergrund

Cloud NDB ist zwar eine hervorragende Datastore-Lösung für langjährige App Engine-Entwickler und erleichtert die Umstellung auf Python 3, aber es ist nicht die einzige Möglichkeit für App Engine-Entwickler, auf Datastore zuzugreifen. Als App Engine Datastore 2013 zu einem eigenen Produkt wurde, wurde Cloud Datastore von Google, eine neue Clientbibliothek, erstellt, damit alle Nutzer Datastore verwenden können.

Python 3-App Engine- und nicht-App Engine-Entwickler werden aufgefordert, Cloud Datastore (nicht Cloud NDB) zu verwenden. Python 2-App Engine-Entwickler sollten von ndb zu Cloud NDB migrieren und von dort zu Python 3 portieren. Sie können aber auch zu Cloud Datastore migrieren. Dies ist eine logische Entscheidung, insbesondere für Entwickler, die bereits Code mit Cloud Datastore verwenden, wie die gerade erwähnten, und die freigegebene Bibliotheken für alle ihre Anwendungen erstellen möchten. Die Wiederverwendung von Code ist eine Best Practice, ebenso wie die Konsistenz von Code. Beide tragen zu insgesamt geringeren Wartungskosten bei, wie hier zusammengefasst:

Migration von Cloud NDB zu Cloud Datastore

  • Entwickler können sich auf eine einzige Codebasis für den Datastore-Zugriff konzentrieren.
  • Sie müssen nicht für einige Codeabschnitte Cloud NDB und für andere Cloud Datastore verwenden.
  • Sorgt für mehr Konsistenz in der Codebasis und eine bessere Wiederverwendbarkeit des Codes
  • Ermöglicht die Verwendung gemeinsamer/geteilter Bibliotheken, was zu niedrigeren Wartungskosten führt

Diese Migration umfasst die folgenden Hauptschritte:

  1. Einrichtung/Vorbereitung
  2. Cloud NDB durch Cloud Datastore-Clientbibliotheken ersetzen
  3. Anwendung 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 2 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 ist, dass Sie eine funktionierende Beispiel-App für Modul 2 haben. Verwenden Sie Ihre Lösung, wenn Sie dieses Tutorial abgeschlossen haben. Sie können es jetzt abschließen (Link oben). Wenn Sie es überspringen möchten, kopieren Sie das Repo für Modul 2 (Link unten).

Unabhängig davon, ob Sie Ihren oder unseren Code verwenden, ist der Code aus Modul 2 der Ausgangspunkt. In diesem Codelab für Modul 3 werden Sie durch jeden Schritt geführt. Am Ende sollte der Code dem Code am FINISH-Punkt ähneln. Es gibt Versionen dieser Anleitung für Python 2 und Python 3. Verwenden Sie das richtige Code-Repository unten.

Python 2

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 das Tutorial zu Modul 2 abgeschlossen 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.

Python 3

Das Verzeichnis der START-Dateien für Python 3-Modul 2 (Ihre oder unsere) sollte so aussehen:

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

Weder lib noch appengine_config.py werden für Python 3 verwendet.

3. Modul 2-App (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. Cloud NDB durch Cloud Datastore-Clientbibliotheken ersetzen

Die einzige Konfigurationsänderung ist ein kleiner Paketwechsel in der Datei requirements.txt.

1. requirements.txt aktualisieren

Nach Abschluss von Modul 2 sah Ihre requirements.txt-Datei so aus:

  • VORHER (Python 2 und 3):
Flask==1.1.2
google-cloud-ndb==1.7.1

Aktualisieren Sie requirements.txt, indem Sie die Cloud NDB-Bibliothek (google-cloud-ndb) durch die neueste Version der Cloud Datastore-Bibliothek (google-cloud-datastore) ersetzen. Der Eintrag für Flask bleibt dabei unverändert. Beachten Sie, dass die letzte Version von Cloud Datastore, die mit Python 2 kompatibel ist, 1.15.3 ist:

  • DANACH (Python 2):
Flask==1.1.2
google-cloud-datastore==1.15.3
  • DANACH (Python 3):
Flask==1.1.2
google-cloud-datastore==2.1.0

Das Repository wird regelmäßig aktualisiert. Es ist also möglich, dass die Datei requirements.txt neuere Versionen enthält als dieses Tutorial. Wir empfehlen, die neuesten Versionen der einzelnen Bibliotheken zu verwenden. Wenn diese nicht funktionieren, können Sie jedoch zu einem älteren Release zurückkehren. Die Versionsnummern oben sind die neuesten, die zum Zeitpunkt der letzten Aktualisierung dieses Codelabs verfügbar waren.

2. Andere Konfigurationsdateien

Die anderen Konfigurationsdateien, app.yaml und appengine_config.py, sollten sich seit dem vorherigen Migrationsschritt nicht geändert haben:

  • app.yaml sollte (weiterhin) auf die gebündelten Drittanbieterpakete grpcio und setuptools verweisen.
  • appengine_config.py sollte (weiterhin) pkg_resources und google.appengine.ext.vendor auf die Drittanbieterressourcen in lib verweisen.

Sehen wir uns nun die Anwendungsdateien an.

5. Anwendungsdateien aktualisieren

An template/index.html wurden keine Änderungen vorgenommen, aber es gibt einige Updates für main.py.

1. Importe

Der Startcode für den Importabschnitt sollte so aussehen:

  • VORHER:
from flask import Flask, render_template, request
from google.cloud import ndb

Ersetzen Sie den google.cloud.ndb-Import durch einen für Cloud Datastore: google.cloud.datastore. Da die Datastore-Clientbibliothek das automatische Erstellen eines Zeitstempelfelds in einer Entität nicht unterstützt, müssen Sie auch das Standardbibliotheksmodul datetime importieren, um ein Zeitstempelfeld manuell zu erstellen. Konventionsgemäß werden Standardbibliotheksimporte vor Importen von Drittanbieterpaketen platziert. Wenn Sie diese Änderungen vorgenommen haben, sollte es so aussehen:

  • DANACH:
from datetime import datetime
from flask import Flask, render_template, request
from google.cloud import datastore

2. Initialisierung und Datenmodell

Nach der Initialisierung von Flask sieht das Erstellen einer NDB-Datenmodellklasse und ihrer Felder in der Beispiel-App aus Modul 2 so aus:

  • VORHER:
app = Flask(__name__)
ds_client = ndb.Client()

class Visit(ndb.Model):
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

Die Cloud Datastore-Bibliothek enthält keine solche Klasse. Löschen Sie daher die Visit-Klassendeklaration. Sie benötigen weiterhin einen Client für die Kommunikation mit Datastore. Ändern Sie daher ndb.Client() in datastore.Client(). Die Datastore-Bibliothek ist flexibler, da Sie Entitäten erstellen können, ohne ihre Struktur wie bei NDB vorab deklarieren zu müssen. Nach dieser Aktualisierung sollte dieser Teil von main.py so aussehen:

  • DANACH:
app = Flask(__name__)
ds_client = datastore.Client()

3. Datastore-Zugriff

Für die Migration zu Cloud Datastore müssen Sie ändern, wie Sie Datastore-Entitäten auf Nutzerebene erstellen, speichern und abfragen. Für Ihre Anwendungen hängt der Schwierigkeitsgrad dieser Migration davon ab, wie komplex Ihr Datastore-Code ist. In unserer Beispielanwendung haben wir versucht, das Update so einfach wie möglich zu gestalten. So sieht unser Startcode aus:

  • VORHER:
def store_visit(remote_addr, user_agent):
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    with ds_client.context():
        return (v.to_dict() for v in Visit.query().order(
                -Visit.timestamp).fetch_page(limit)[0])

Erstellen Sie mit Cloud Datastore eine generische Entität, in der gruppierte Objekte in Ihrer Entität mit einem „Schlüssel“ identifiziert werden. Erstellen Sie den Datensatz mit einem JSON-Objekt (Python dict) aus Schlüssel/Wert-Paaren und schreiben Sie ihn dann mit dem erwarteten put() in Datastore. Abfragen sind mit Datastore ähnlich, aber einfacher. Hier sehen Sie, wie sich der entsprechende Datastore-Code unterscheidet:

  • DANACH:
def store_visit(remote_addr, user_agent):
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

def fetch_visits(limit):
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    return query.fetch(limit=limit)

Aktualisieren Sie die Funktionskörper für store_visit() und fetch_visits() wie oben beschrieben und behalten Sie die Signaturen der vorherigen Version bei. Am Haupthandler root() ändert sich nichts. Nachdem Sie diese Änderungen vorgenommen haben, ist Ihre App für die Verwendung von Cloud Datastore eingerichtet und kann getestet werden.

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 in den Repository-Ordnern von Modul 3 ü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 3. Sie wissen jetzt, dass Sie sowohl die Cloud NDB- als auch die Cloud Datastore-Clientbibliotheken für den Zugriff auf Datastore verwenden können. Durch die Migration zu Letzterem können Sie jetzt von freigegebenen Bibliotheken, gemeinsamem Code und der Wiederverwendung von Code profitieren, um die Konsistenz zu erhöhen und die Wartungskosten zu senken.

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

Hier finden Sie weitere Migrationsmodule:

  • Bonus für Modul 3:Im Bonusabschnitt erfahren Sie, wie Sie zu Python 3 und zur App Engine-Laufzeit der nächsten Generation migrieren.
  • 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 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. 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: Integrierte Pakete müssen nicht in app.yaml angegeben werden und es ist 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 Datastore mit Python 2 und 3 kompatibel ist, muss kein Anwendungscode explizit zu 3.x portiert werden: Die App wird unverändert in 2.x und 3.x ausgeführt. Die einzigen erforderlichen Änderungen betreffen in diesem Fall die Konfiguration:

  1. app.yaml vereinfachen, um auf Python 3 zu verweisen und den Verweis auf gebündelte Drittanbieterbibliotheken zu entfernen.
  2. Löschen Sie appengine_config.py und den Ordner lib, da sie nicht mehr benötigt werden.

Die Anwendungsdateien main.py und templates/index.html bleiben unverändert.

requirements.txt aktualisieren

Die letzte Version von Cloud Datastore, die Python 2 unterstützt, ist 1.15.3. Aktualisieren Sie requirements.txt auf die neueste Version für Python 3 (die Version ist möglicherweise neuer). Als diese Anleitung geschrieben wurde, war die aktuelle Version 2.1.0. Bearbeiten Sie die Zeile also so, dass sie so aussieht (oder wie auch immer die aktuelle Version lautet):

google-cloud-datastore==2.1.0

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 3:

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 finden Sie auf der app.yaml-Referenzseite.

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. Das Ergebnis ist ein app.yaml, das so aussieht:

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 finden Sie auf der app.yaml-Referenzseite. Weitere Beispiele und Best Practices finden Sie in der Dokumentation zur App Engine-Standardumgebung und in der Dokumentation zur flexiblen App Engine-Umgebung.

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 3 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 3! Dokumentation zum Vorbereiten von Konfigurationsdateien für die Python 3-Laufzeit Sehen Sie sich zum Schluss die Zusammenfassung oben an, um Informationen zu den nächsten Schritten und zur Bereinigung zu erhalten.

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 2 (START) und Modul 3 (FINISH) finden Sie in der Tabelle unten. Sie können auch über das Repository für alle App Engine-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

App Engine-Ressourcen

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