Modul 3: Von Google Cloud NDB zu Cloud Datastore migrieren

1. Übersicht

Diese Reihe von Codelabs (praxisorientierte Anleitungen zum selbstbestimmten Lernen) zielt darauf ab, Entwicklern von Google App Engine (Standardumgebung) bei der Modernisierung ihrer Anwendungen zu helfen, indem sie sie durch eine Reihe von Migrationen führen. Der wichtigste Schritt besteht darin, die gebündelten Originaldienste zur Laufzeit nicht mehr zu verwenden, da die Laufzeiten der nächsten Generation flexibler sind und Nutzern eine größere Vielfalt an Dienstoptionen bieten. Durch den Wechsel zur Laufzeit der neueren Generation können Sie leichter in Google Cloud-Produkte einbinden, eine größere Auswahl an unterstützten Diensten nutzen und aktuelle Sprachversionen unterstützen.

In dieser optionalen Anleitung erfahren Entwickler, wie sie von Cloud NDB zu Cloud Datastore als Clientbibliothek migrieren, um mit dem Datastore-Dienst zu kommunizieren. Entwickler, die NDB bevorzugen, können es beibehalten, da es Python 3-kompatibel ist, sodass diese Migration optional ist. Diese Migration ist nur für Nutzer gedacht, die eine konsistente Codebasis und gemeinsam genutzte Bibliotheken mit anderen Anwendungen erstellen möchten, die bereits Cloud Datastore verwenden. Dies wird im Abschnitt „Hintergrund“ erklärt. .

Du lernst, wie du

  • Verwenden Sie Cloud NDB (falls Sie nicht damit 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-Rechnungskonto
  • Grundlegende Python-Kenntnisse
  • Erfahrung mit grundlegenden Linux-Befehlen
  • Grundkenntnisse zum Entwickeln und Bereitstellen von App Engine-Anwendungen
  • Eine funktionierende App Engine-Anwendung für Modul 2 2.x oder 3.x.

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

Obwohl Cloud NDB eine großartige Datastore-Lösung für langjährige App Engine-Entwickler ist und bei der Umstellung auf Python 3 hilft, ist dies nicht die einzige Möglichkeit, wie App Engine-Entwickler auf Datastore zugreifen können. Als Datastore von App Engine 2013 ein eigenes Produkt wurde, Google Cloud Datastore, wurde eine neue Clientbibliothek erstellt, damit alle Nutzer Datastore verwenden können.

Python 3-Entwickler in App Engine und anderen App Engine-Entwicklern werden empfohlen, Cloud Datastore und nicht Cloud NDB zu verwenden. Python 2 App Engine-Entwicklern wird empfohlen, von ndb zu Cloud NDB zu migrieren und von dort zu Python 3 zu portieren. Sie können aber auch eine weitere Migration zu Cloud Datastore ausführen. Dies ist eine logische Entscheidung, insbesondere für Entwickler, die bereits Code mit Cloud Datastore haben (wie eben erwähnt) und gemeinsam genutzte Bibliotheken für alle ihre Anwendungen erstellen möchten. Die Wiederverwendung von Code ist ebenso wie die Codekonsistenz eine Best Practice. Beide tragen zu geringeren Wartungskosten bei, wie hier zusammengefasst wird:

Migration von Cloud NDB zu Cloud Datastore

  • Ermöglicht Entwicklern, sich für den Datastore-Zugriff auf eine einzige Codebasis zu konzentrieren
  • Vermeidet die Wartung bestimmter Codes mit Cloud NDB und anderer Code mit Cloud Datastore
  • Bietet mehr Konsistenz in der Codebasis und bessere Wiederverwendung von Code
  • Ermöglicht die Verwendung gemeinsamer/gemeinsam genutzter Bibliotheken, die zu niedrigeren Gesamtkosten für die Wartung beitragen

Diese Migration umfasst die folgenden Hauptschritte:

  1. Einrichtung/Vorarbeit
  2. Cloud NDB durch Cloud Datastore-Clientbibliotheken ersetzen
  3. Anwendung aktualisieren

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 das Codelab für Modul 2 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

Dafür benötigen Sie eine funktionierende Beispiel-App für Modul 2. Verwenden Sie Ihre Lösung, wenn Sie diese Anleitung abgeschlossen haben. Sie können ihn jetzt abschließen (Link oben) oder das Modul 2-Repository kopieren (Link unten), wenn Sie ihn überspringen möchten.

Unabhängig davon, ob Sie Ihren oder unseren verwenden, beginnen wir mit dem Code für Modul 2. Dieses Codelab für Modul 3 führt Sie durch die einzelnen Schritte. Wenn Sie fertig sind, sollte es dem Code am FINISH-Punkt ähneln. Es gibt Python 2- und Python 3-Versionen dieser Anleitung. Rufen Sie das richtige Code-Repository unten ab.

Python 2

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 die Anleitung für Modul 2 abgeschlossen haben, haben Sie außerdem einen lib-Ordner mit Flask und den zugehörigen Abhängigkeiten. Wenn Sie keinen lib-Ordner haben, erstellen Sie ihn mit dem Befehl pip install -t lib -r requirements.txt, damit wir diese Referenzanwendung im nächsten Schritt bereitstellen können. Wenn Sie sowohl Python 2 als auch 3 installiert haben, empfehlen wir die Verwendung von pip2 anstelle von pip, um eine Verwechslung mit Python 3 zu vermeiden.

Python 3

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

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

Für Python 3 werden weder lib noch appengine_config.py verwendet.

3. Anwendung von Modul 2 (erneut) bereitstellen

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

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

Nachdem Sie diese Schritte erfolgreich ausgeführt und bestätigt haben, dass der Dienst betriebsbereit ist, fahren wir mit der Anleitung fort und beginnen mit den Konfigurationsdateien.

4. Cloud NDB durch Cloud Datastore-Clientbibliotheken ersetzen

Die einzige Konfigurationsänderung ist ein kleinerer Pakettausch in der Datei requirements.txt.

1. requirements.txt aktualisieren

Nachdem Sie Modul 2 abgeschlossen haben, sah Ihre Datei requirements.txt 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 und den Eintrag für Flask intakt lassen. Beachten Sie, dass die endgültige Version von Cloud Datastore, die mit Python 2 kompatibel ist, 1.15.3 ist:

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

Beachten Sie, dass das Repository regelmäßiger verwaltet wird als in dieser Anleitung. Es ist also möglich, dass die Datei requirements.txt neuere Versionen widerspiegelt. Wir empfehlen, die jeweils neueste Version jeder Bibliothek zu verwenden. Falls sie nicht funktionieren, können Sie ein Rollback auf einen älteren Release durchführen. Die Versionsnummern oben geben an, wann dieses Codelab zuletzt aktualisiert wurde.

2. Andere Konfigurationsdateien

Die anderen Konfigurationsdateien app.yaml und appengine_config.py sollten unverändert bleiben.

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

Kommen wir nun zu den Anwendungsdateien.

5. Anwendungsdateien aktualisieren

An template/index.html hat sich nichts geändert, aber es gibt ein paar 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 Import google.cloud.ndb durch einen für Cloud Datastore: google.cloud.datastore. Da die Datastore-Clientbibliothek die automatische Erstellung eines Zeitstempelfelds in einer Entität nicht unterstützt, müssen Sie auch das Modul datetime der Standardbibliothek importieren, um manuell eines zu erstellen. Konventionsgemäß gehen Standardbibliotheksimporte vor Paketimporten von Drittanbietern. Wenn Sie mit diesen Änderungen fertig sind, sollte das so aussehen:

  • NACHHER:
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 wird die Beispielanwendung aus Modul 2, die eine NDB-Datenmodellklasse und ihre Felder erstellt, so definiert:

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

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

In der Cloud Datastore-Bibliothek gibt es keine solche Klasse. Löschen Sie daher die Klassendeklaration Visit. Sie benötigen weiterhin einen Client, um mit Datastore zu kommunizieren. Ändern Sie daher ndb.Client() in datastore.Client(). Die Datastore-Bibliothek ist flexibler, Sie können Entitäten ohne Vordeklaration erstellen ihre Struktur wie NDB nutzen. Nach dieser Aktualisierung sollte dieser Teil von main.py so aussehen:

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

3. Datastore-Zugriff

Bei der Migration zu Cloud Datastore muss sich die Art und Weise ändern, wie Datastore-Entitäten erstellt, gespeichert und abgefragt werden (auf Nutzerebene). Bei Ihren Anwendungen hängt die Schwierigkeit dieser Migration davon ab, wie komplex Ihr Datastore-Code ist. In unserer Beispiel-App haben wir versucht, das Update so einfach wie möglich zu gestalten. Hier ist unser Startcode:

  • 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, die gruppierte Objekte in Ihrer Entität mit einem „Schlüssel“ identifiziert. 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 in Datastore ähnlich, aber einfacher. Hier sehen Sie, wie sich der entsprechende Datastore-Code unterscheidet:

  • NACHHER:
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 den Funktionstext für store_visit() und fetch_visits() wie oben, wobei die Signaturen der vorherigen Version identisch bleiben. Am Haupt-Handler root() wurden keine Änderungen vorgenommen. Nachdem Sie diese Änderungen vorgenommen haben, ist Ihre Anwendung für die Verwendung von Cloud Datastore ausgestattet und kann getestet werden.

6. Zusammenfassung/Bereinigung

Anwendung bereitstellen

Stellen Sie die Anwendung noch einmal mit gcloud app deploy bereit und prüfen Sie, ob sie funktioniert. Ihr Code sollte jetzt mit dem Inhalt in den Repository-Ordnern von Modul 3 übereinstimmen:

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

Glückwunsch zum Abschluss dieses Codelab 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. Wenn Sie auf Letzteres umstellen, profitieren Sie jetzt von gemeinsam genutzten Bibliotheken sowie von einheitlicher Wiederverwendung von Code und Code – für Konsistenz und geringere Wartungskosten.

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? Als Entwickler sind Sie wahrscheinlich bereits über die Preisinformationen von App Engine informiert.

Optional: Anwendung deaktivieren

Wenn Sie noch nicht mit der nächsten Anleitung fortfahren möchten, deaktivieren Sie Ihre Anwendung, um Gebühren 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 andererseits nicht mit der Migration fortfahren und alles vollständig löschen möchten, können Sie Ihr Projekt herunterfahren.

Nächste Schritte

Sie können sich nun die folgenden Migrationsmodule ansehen:

  • Bonus für Modul 3: Fahren Sie mit dem Bonusabschnitt fort, um mehr über die Portierung zu Python 3 und der App Engine-Laufzeit der nächsten Generation zu erfahren.
  • 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 4: Mit Docker zu Cloud Run migrieren
    • Anwendung containerisieren, um sie mit Docker in Cloud Run auszuführen
    • Ermöglicht es Ihnen, bei Python 2 zu bleiben
  • Modul 5: Mit Cloud Buildpacks zu Cloud Run migrieren
    • Anwendung mit Cloud Buildpacks für die Ausführung in Cloud Run containerisieren
    • Sie brauchen nichts über Docker, Container oder Dockerfiles zu wissen
    • Erfordert, dass Sie Ihre Anwendung bereits zu Python 3 migriert haben
  • 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. BONUS: Zu Python 3 migrieren

Wir empfehlen Ihnen, zu Python 3 zu migrieren, um Zugriff auf die neuesten App Engine-Laufzeiten und -Funktionen zu erhalten. In unserer Beispielanwendung war Datastore der einzige integrierte Dienst, den wir verwendet haben. Da wir von ndb zu Cloud NDB migriert haben, können wir jetzt zur Python 3-Laufzeit von App Engine portieren.

Übersicht

Die Portierung nach Python 3 ist zwar nicht im Rahmen einer Google Cloud-Anleitung enthalten, aber dieser Teil des Codelabs vermittelt Entwicklern eine Vorstellung davon, wie sich die Python 3-Laufzeit von App Engine unterscheidet. Eine herausragende Funktion der Laufzeit der nächsten Generation ist der vereinfachte Zugriff auf Drittanbieterpakete: Sie müssen weder integrierte Pakete in app.yaml angeben noch nicht integrierte Bibliotheken kopieren oder hochladen. Sie werden implizit aus der Auflistung in requirements.txt installiert.

Da unser Beispiel so einfach ist und Cloud Datastore mit Python 2-3 kompatibel ist, muss kein Anwendungscode explizit auf 3.x portiert werden: Die App wird auf 2.x und 3.x unverändert ausgeführt. Das bedeutet, dass die einzigen erforderlichen Änderungen in diesem Fall an der Konfiguration liegen:

  1. Vereinfachen Sie app.yaml, um auf Python 3 zu verweisen, und entfernen Sie Verweise auf gebündelte Drittanbieterbibliotheken.
  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 endgültige Version von Cloud Datastore, die Python 2 unterstützt, ist 1.15.3. Aktualisieren Sie requirements.txt mit der neuesten Version für Python 3 (möglicherweise neuer). Als diese Anleitung geschrieben wurde, war die neueste Version 2.1.0. Bearbeiten Sie diese Zeile daher so (bzw. die aktuelle Version):

google-cloud-datastore==2.1.0

app.yaml vereinfachen

VORHER:

Die einzige tatsächliche Änderung für diese Beispiel-App ist die deutliche Verkürzung von app.yaml. Zur Erinnerung: Hier sind die Punkte, die wir in app.yaml am Ende von Modul 3 hatten:

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

NACHHER:

In Python 3 wurden die Anweisungen threadsafe, api_version und libraries eingestellt. Alle Anwendungen gelten als threadsicher und api_version wird in Python 3 nicht verwendet. Da in App Engine-Diensten keine integrierten Drittanbieterpakete mehr vorinstalliert sind, wurde auch libraries eingestellt. Weitere Informationen zu diesen Änderungen finden Sie in der Dokumentation zu den Ä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

Darüber hinaus wurde die handlers-Anweisung, die Traffic an App Engine-Anwendungen weiterleitet, eingestellt. Da die Laufzeit der nächsten Generation zur Verwaltung des App-Routings Web-Frameworks voraussetzt, sind alle „Handler-Skripts“ muss in „auto“ geändert werden. Durch die Kombination der obigen Änderungen gelangen Sie zu diesem app.yaml:

runtime: python38

handlers:
- url: /.*
  script: auto

Weitere Informationen zu script: auto finden Sie auf der Referenzseite zu app.yaml.

handlers-Anweisung wird entfernt

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

runtime: python38

Dadurch wird standardmäßig 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 den einfachen app.yaml-Elementen 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. Der app.yaml sieht dann so aus:

runtime: python38
entrypoint: python main.py

In diesem Beispiel wird speziell die Verwendung des Flask-Entwicklungsservers anstelle von gunicorn angefordert. Code, der den Entwicklungsteam startet, muss auch zu Ihrer App hinzugefügt werden, damit sie auf der 0.0.0.0-Schnittstelle an Port 8080 gestartet wird. Fügen Sie dazu diesen kleinen Abschnitt am Ende von main.py hinzu:

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

Weitere Informationen zu entrypoint finden Sie auf der Referenzseite zu app.yaml. Weitere Beispiele und Best Practices finden Sie in den Startdokumenten für die App Engine-Standardumgebung und in den Startdokumenten für die flexible 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 übernimmt App Engine die in requirements.txt aufgeführten Pakete 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 (integrierte) vorhandene Elemente verwenden. Beim Wechsel zu Python 3 sehen Sie eine Zusammenfassung der großen Änderungen:

  1. Keine Bündelung kopierter Drittanbieterbibliotheken (aufgeführt in requirements.txt)
  2. Kein pip install in einem lib-Ordner, d. h. kein lib-Ordnerzeitraum
  3. Keine Einträge für integrierte Bibliotheken von Drittanbietern in app.yaml
  4. Auf die App muss nicht auf Bibliotheken von Drittanbietern verwiesen werden, daher ist keine appengine_config.py-Datei erforderlich.

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

Anwendung bereitstellen

Stellen Sie die Anwendung noch einmal bereit, um zu prüfen, ob sie funktioniert. Sie können auch prüfen, wie nah Ihre Lösung am Python 3-Beispielcode aus Modul 3 ist. Vergleichen Sie den Code mit der Python 2-Version, um die Unterschiede zu Python 2 zu visualisieren.

Glückwunsch! Sie haben den Bonusschritt in Modul 3 abgeschlossen. Dokumentation zum Vorbereiten von Konfigurationsdateien für die Python 3-Laufzeit Sehen Sie sich schließlich die vorherige Zusammenfassung oben an, um sich über die nächsten Schritte und die Bereinigung zu informieren.

Ihre Anwendung wird vorbereitet

Wenn es an der Zeit ist, Ihre Anwendung zu migrieren, müssen Sie Ihre main.py und andere Anwendungsdateien auf 3.x portieren. Daher empfiehlt es sich, Ihr Bestes zu geben, Ihre 2.x-Anwendung als "aufwärtskompatibel" zu gestalten. wie möglich.

Es gibt zahlreiche Online-Ressourcen, die Ihnen dabei helfen, aber einige der wichtigsten Tipps:

  1. Achten Sie darauf, dass alle Anwendungsabhängigkeiten vollständig 3.x-kompatibel sind
  2. Sorgen Sie dafür, dass Ihre Anwendung mindestens mit Version 2.6 (vorzugsweise Version 2.7) ausgeführt wird.
  3. Sicherstellen, dass die Anwendung die gesamte Test-Suite besteht (und eine Abdeckung von mindestens 80% beträgt)
  4. Kompatibilitätsbibliotheken wie six, Future und/oder Modernize verwenden
  5. Informieren Sie sich über die wichtigsten Unterschiede zwischen 2.x und 3.x, die nicht abwärtskompatibel sind
  6. Jede E/A führt wahrscheinlich zu Inkompatibilitäten zwischen Unicode und Bytestring.

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

8. 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 (START) und Modul 3 (FINISH) finden Sie in der folgenden Tabelle. Sie können auch über das Repository für alle App Engine-Migrationen auf sie zugreifen, das Sie klonen oder als ZIP-Datei herunterladen können.

Codelab

Python 2

Python 3

Modul 2

code

code

Modul 3

code

code

App Engine-Ressourcen

Nachfolgend finden Sie zusätzliche Ressourcen zu dieser Migration: