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
- Ein Google Cloud Platform-Projekt mit:
- Grundlegende Python-Kenntnisse
- Erfahrung mit gängigen Linux-Befehlen
- Grundkenntnisse zum Entwickeln und Bereitstellen von App Engine-Anwendungen
- Eine funktionierende Modul 1 App Engine-Anwendung
Umfrage
Wie möchten Sie dieses Codelab nutzen?
<ph type="x-smartling-placeholder">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:
- Zu Python 3 migrieren und zur App Engine-Laufzeit der nächsten Generation
- Migration zu Cloud Datastore (Clientbibliothek für Anwendungen, die nicht zur App Engine gehören)
- Python 2- oder Python 3-Anwendung containerisieren und zu Cloud Run migrieren
- 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:
- Einrichtung/Vorarbeit
- Cloud NDB-Bibliothek hinzufügen
- 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):
- START: Modul 1: Code
- FINISH: Modul 2 Python 2-Code (BONUS: Python 3-Code)
- Gesamtes Repository (zum Klonen oder Herunterladen der ZIP-Datei)
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:
- Machen Sie sich noch einmal mit dem
gcloud
-Befehlszeilentool vertraut (falls erforderlich). - 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:
- Integrierte Bibliotheken in
app.yaml
angeben - 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:
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
- Fügt App Engine-
- 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
Dockerfile
s 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:
- Vereinfachen Sie
app.yaml
, um auf Python 3 zu verweisen, und entfernen Sie Bibliotheken von Drittanbietern. - Löschen Sie
appengine_config.py
und den Ordnerlib
, 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:
- Keine Bündelung kopierter Drittanbieterbibliotheken (aufgeführt in
requirements.txt
) - Kein
pip install
in einemlib
-Ordner, d. h. keinlib
-Ordnerzeitraum - Keine Einträge für integrierte Bibliotheken von Drittanbietern in
app.yaml
- 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:
- Achten Sie darauf, dass alle Anwendungsabhängigkeiten vollständig 3.x-kompatibel sind
- Sorgen Sie dafür, dass Ihre Anwendung mindestens mit Version 2.6 (vorzugsweise Version 2.7) ausgeführt wird.
- Sicherstellen, dass die Anwendung die gesamte Test-Suite besteht (und eine Abdeckung von mindestens 80% beträgt)
- Kompatibilitätsbibliotheken wie
six
, Future und/oder Modernize verwenden - Informieren Sie sich über die wichtigsten Unterschiede zwischen 2.x und 3.x, die nicht abwärtskompatibel sind
- 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 |
(nicht zutreffend) | ||
Modul 2 |
App Engine-Ressourcen
Nachfolgend finden Sie zusätzliche Ressourcen zu dieser Migration:
- Python NDB-Referenzen
- (ALT) Migration von Python 2.5 und
webapp
zu 2.7 undwebapp2
- Migration zur Python 3- und GAE-Laufzeit der nächsten Generation
- Allgemein