Modul 2: Von App Engine-NDB zu Cloud NDB 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. 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 Anleitung erfahren Sie, wie Sie von der integrierten ndb-Clientbibliothek (Next Database) von App Engine zur Cloud NDB-Clientbibliothek migrieren.

Du lernst, wie du

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

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

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

Nach Abschluss dieser Migration haben Sie folgende Möglichkeiten:

  1. Zu Python 3 migrieren und zur App Engine-Laufzeit der nächsten Generation
  2. Migration zu Cloud Datastore (Clientbibliothek für Anwendungen, die nicht zur App Engine gehören)
  3. Python 2- oder Python 3-Anwendung containerisieren und zu Cloud Run migrieren
  4. Verwendung von App Engine-Aufgabenwarteschlangen (Push) hinzufügen und anschließend zu Cloud Tasks migrieren

Aber das sind wir noch nicht. Schließen Sie dieses Codelab ab, bevor Sie die nächsten Schritte in Betracht ziehen. Die Migration in dieser Anleitung umfasst die folgenden Hauptschritte:

  1. Einrichtung/Vorarbeit
  2. Cloud NDB-Bibliothek hinzufügen
  3. Anwendungsdateien 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 1 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 App Engine aktiviert ist.

2. Baseline-Beispiel-App abrufen

Dafür benötigen Sie eine funktionierende Beispiel-App für Modul 1. Verwenden Sie Ihre Lösung, wenn Sie diese Anleitung abgeschlossen haben. Sie können ihn jetzt abschließen (Link oben) oder das Modul 1-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 1. Dieses Codelab für Modul 2 führt Sie durch die einzelnen Schritte. Wenn er abgeschlossen ist, sollte es dem Code am FINISH-Punkt ähneln (einschließlich eines optionalen Bonusports von Python 2 bis 3):

Ihr Codeordner STARTing Modul 1 sollte folgende Inhalte enthalten:

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

Wenn Sie die Anleitung für Modul 1 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.

3. Anwendung von Modul 1 (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. Konfigurationsdateien aktualisieren (Cloud NDB-Bibliothek hinzufügen)

Viele der ursprünglichen integrierten App Engine-Dienste wurden in eigene Produkte integriert, darunter auch Datastore. Derzeit können Anwendungen, die nicht die App Engine sind, 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. Es 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 Anwendung. 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 deshalb das Paket requirements.txt hinzu.

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

Als dieses Codelab geschrieben wurde, ist 1.7.1 die neueste empfohlene Version. requirements.txt im Repository hat aber möglicherweise eine neuere Version. Wir empfehlen die jeweils neueste Version jeder Bibliothek. Falls sie nicht funktionieren, können Sie ein Rollback auf einen älteren Release durchführen.

Löschen Sie den Ordner lib, falls vorhanden, und diesen nicht gerade oben erstellt haben. Installieren Sie nun die aktualisierten Bibliotheken (neu) mit dem Befehl pip install -t lib -r requirements.txt und verwenden Sie dabei pip2 anstelle von pip nach Bedarf.

2. app.yaml aktualisieren

Das Hinzufügen von Google Cloud-Clientbibliotheken wie google-cloud-ndb stellt einige Anforderungen, die sich alle um die Einbeziehung „integrierter“ Bibliotheken und Drittanbieterpakete, die bereits auf Google-Servern verfügbar sind. Sie listen sie nicht in requirements.txt auf und kopieren sie auch nicht mit pip install. Die einzigen Anforderungen:

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

Hier ist die STARTE-Phase von app.yaml aus Modul 1:

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

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

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

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

Vorteile dieser integrierten Bibliotheken 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. Es gibt jetzt Gründe für das Einbeziehen von setuptools.

  • NACHHER:

Mit den oben genannten Änderungen sollte Ihre aktualisierte 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

Das pkg_resources-Tool, das zur setuptools-Bibliothek gehört, wird verwendet, damit integrierte Drittanbieterbibliotheken auf die gebündelten Bibliotheken zugreifen können. Aktualisieren Sie appengine_config.py, um mit pkg_resources auf die gebündelten Bibliotheken in lib zu verweisen. Wenn Sie diese Änderung vorgenommen haben, sollte die gesamte Datei wie folgt 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

Da Ihnen die Formalitäten der Konfigurationsdatei nicht mehr im Weg stehen, 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 den folgenden Import vor:

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

Der Wechsel von einer App Engine-Bibliothek zu einer Google Cloud-Bibliothek ist manchmal so subtil wie diese Instanz. Bei integrierten Diensten, die zu vollständigen Google Cloud-Produkten geworden sind, importieren Sie Attribute aus google.cloud statt aus google.appengine.

2. Datastore-Zugriff

Damit Sie die Cloud NDB-Bibliothek verwenden können, muss Ihre Anwendung Python-Kontextmanager verwenden. Ihr Zweck ist es, Zugriff auf Ressourcen, die erst beschafft werden müssen, bevor sie verwendet werden können. Kontextmanager basieren auf der Informatiksteuerungstechnik, die als Ressourcenzuweisung ist Initialisierung (oder RAII) bezeichnet wird. Kontextmanager werden mit Python-Dateien (die geöffnet werden müssen, bevor der Zugriff darauf möglich ist) und Nebenläufigkeit, spinlocks, verwendet. muss vor dem Code in einem kritischen Bereich erworben werden ausgeführt werden kann.

In ähnlicher Weise erfordert Cloud NDB, dass Sie den Kontext eines Clients abrufen, um mit Datastore kommunizieren zu können, bevor Datastore-Befehle ausgeführt werden können. Erstellen Sie zuerst einen Client (ndb.Client()), indem Sie ds_client = ndb.Client() in main.py direkt nach der Flask-Initialisierung hinzufügen:

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

Der Python-Befehl with wird ausschließlich verwendet, um den Kontext eines Objekts abzurufen. Verpacken Sie Codeblöcke, die auf Datastore zugreifen, mit with-Anweisungen.

Im Folgenden finden Sie die gleichen Funktionen aus Modul 1 zum Schreiben einer neuen Entität in Datastore und zum Anzeigen der zuletzt hinzugefügten Entitäten:

  • 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))
  • NACHHER:

Fügen Sie jetzt with ds_client.context(): hinzu und verschieben Sie Ihren Datastore-Zugriffscode 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 mit dem aus Modul 1 identisch, da hier keinen ndb-Code (noch 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, klar zwischen Anwendungscode und Datenzugriff zu unterscheiden. Auf diese Weise ändert sich Ihr Hauptanwendungscode nicht, wenn der zugrunde liegende Datenspeichermechanismus geändert wird, wie wir es bei dieser Migration getan haben.

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 im Modul 2-Repository ü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 2. Sie haben gerade die Ziellinie überquert, da dies die letzte der dringend empfohlenen Migrationen in dieser Reihe ist, die Datastore betrifft.

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 haben dann die Wahl, was Sie als Nächstes tun möchten. Wählen Sie eine der folgenden Optionen aus:

  • Bonus für Modul 2: Fahren Sie unten mit dem Bonusteil dieser Anleitung fort. Darin erfahren Sie mehr über die Portierung zu Python 3 und die App Engine-Laufzeit der nächsten Generation.
  • 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 müssen nichts über Docker, Container oder Dockerfiles wissen
    • Erfordert, dass Sie Ihre Anwendung bereits zu Python 3 migriert haben
  • 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

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. Ein herausragendes Feature 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 NDB 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 in der Konfiguration liegen:

  1. Vereinfachen Sie app.yaml, um auf Python 3 zu verweisen, und entfernen Sie Bibliotheken von Drittanbietern.
  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 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 2 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 Dokumentationsseite.

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, können Sie diesen mit einer entrypoint-Anweisung angeben, wobei Ihr app.yaml so aussehen würde:

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 Dokumentationsseite. Weitere Beispiele und Best Practices finden Sie in den Startdokumenten für die App Engine-Standardversion und in der Startdokumentation 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 dem Python 3-Beispielcode aus Modul 2 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 2 abgeschlossen. Dokumentation zum Vorbereiten von Konfigurationsdateien für die Python 3-Laufzeit Sehen Sie sich schließlich die (frühere) Seite „Zusammenfassung“/„Bereinigung“ auf die nächsten Schritte und die Bereinigung an.

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 1 (START) und Modul 2 (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 1

code

(nicht zutreffend)

Modul 2

code

code

App Engine-Ressourcen

Nachfolgend finden Sie zusätzliche Ressourcen zu dieser Migration: