1. Übersicht
Die Codelabs-Reihe zur Serverless Migration Station (zum Selbststudium, praxisorientierte Anleitungen) und ähnliche Videos sollen Entwickler von Google Cloud Serverless bei der Modernisierung ihrer Anwendungen unterstützen, indem sie eine oder mehrere Migrationen durchgehen, in erster Linie von Legacy-Diensten. Dadurch werden Ihre Anwendungen portabler und bieten mehr Optionen und Flexibilität, sodass Sie eine größere Auswahl an Cloud-Produkten einbinden und darauf zugreifen sowie einfacher auf neuere Sprachversionen upgraden können. Anfangs konzentrierte sich diese Reihe auf die ersten Cloud-Nutzer, in erster Linie auf Entwickler von App Engine (Standardumgebung). Sie ist jedoch breit genug gefasst, um auch andere serverlose Plattformen wie Cloud Functions und Cloud Run oder gegebenenfalls andere Plattformen einzubeziehen.
Bisher mussten Entwickler von den bisherigen "gebündelten Diensten" von App Engine migrieren. wie Datastore und Memcache, bevor sie Sprachversionen aktualisieren konnten, was zwei potenziell herausfordernde Schritte hintereinander darstellt. Da viele der gebündelten Schlüsseldienste im App Engine-Dienst der 2. Generation verfügbar sind, können Entwickler ihre Anwendungen jetzt auf die neuesten Laufzeiten portieren und die meisten gebündelten Dienste weiterhin verwenden. In diesem Codelab erfahren Sie, wie Sie eine Beispielanwendung von Python 2 auf 3 aktualisieren und dabei den gebündelten Datastore-Dienst über die App Engine NDB-Bibliothek weiterhin verwenden. Für die Verwendung der meisten gebündelten Dienste ist nur eine geringfügige Aktualisierung des Codes erforderlich, wie in dieser Anleitung erläutert. Es gibt jedoch auch andere, die umfangreichere Änderungen erfordern. werden in Teil 2 behandelt. ein Folgemodul und ein Codelab.
Sie werden lernen,
- App Engine-Beispielanwendung für den Port von Python 2 nach 3
- App-Konfiguration mit dem App Engine SDK aktualisieren
- SDK-Code zur App hinzufügen, die gebündelte Dienste in Laufzeiten der 2. Generation wie Python 3 unterstützt
Voraussetzungen
- Ein Google Cloud-Projekt mit einem aktiven GCP-Rechnungskonto
- Grundlegende Python-Kenntnisse
- Erfahrung mit gängigen Linux-Befehlen
- Grundkenntnisse zum Entwickeln und Bereitstellen von App Engine-Anwendungen
- Eine funktionierende App Engine-Anwendung für Modul 1 (führen Sie ihr Codelab aus [empfohlen] oder kopieren Sie die Anwendung aus dem Repository)
Umfrage
Wie möchten Sie diese Anleitung nutzen?
<ph type="x-smartling-placeholder">Wie würden Sie Ihre Erfahrung mit Python bewerten?
<ph type="x-smartling-placeholder">Wie würden Sie Ihre Erfahrungen im Umgang mit Google Cloud-Diensten bewerten?
<ph type="x-smartling-placeholder">2. Hintergrund
Der ursprüngliche App Engine-Dienst wurde 2008 auf den Markt gebracht und enthielt eine Reihe von Legacy-APIs (jetzt als gebündelte Dienste bezeichnet), die es Entwicklern erleichtern, Anwendungen weltweit zu erstellen und bereitzustellen. Zu diesen Diensten gehören Datastore, Memcache und die Aufgabenwarteschlange. Die Nutzer waren zwar praktisch, besorgten aber die Übertragbarkeit ihrer Apps, wenn sie proprietäre APIs verwenden, die sie mit App Engine verbinden, und wollten daher, dass ihre Apps portabler sein sollten. Hinzu kommt, dass viele dieser gebündelten Dienste zur Entwicklung eigener Cloud-Produkte entwickelt wurden. Das hat das App Engine-Team dazu veranlasst, 2018 ohne sie die Plattform der nächsten Generation auf den Markt zu bringen.
Python 2-Entwickler möchten gern ein Upgrade auf Python 3 durchführen. Für eine 2.x-Anwendung mit gebündelten Diensten war eine Migration weg von diesen Diensten erforderlich, bevor ihre Anwendungen auf 3.x übertragen werden konnten. Dies repräsentiert zwei aufeinanderfolgende Migrationen, die möglicherweise auch herausfordernd waren. Zur Unterstützung dieser Umstellung hat das App Engine-Team im Herbst 2021 ein „Wormhole“ eingeführt. in der Vergangenheit entwickelt. Dadurch können Anwendungen, die auf Laufzeiten der nächsten Generation ausgeführt werden, auf viele dieser gebündelten Dienste zugreifen. Diese Version umfasst zwar nicht alle Dienste, die in den ursprünglichen Laufzeiten verfügbar sind, aber auch wichtige Anbieter wie Datastore, Task Queue und Memcache sind verfügbar.
In diesem Codelab werden die Änderungen demonstriert, die erforderlich sind, um Ihre Anwendung auf Python 3 zu aktualisieren und dabei gebündelte Dienste weiterhin zu verwenden. Das Ziel besteht darin, Ihre Anwendungen mit den neuesten Laufzeiten auszuführen. So können Sie dann nach Ihrem eigenen Zeitplan von gebündelten Diensten zu eigenständigen Cloud-Diensten oder Drittanbieteralternativen migrieren, anstatt das Upgrade auf 3.x zu blockieren. Eine Migration weg von gebündelten Diensten ist zwar nicht mehr erforderlich, aber dadurch erhalten Sie mehr Portabilität und Flexibilität im Hinblick auf den Ort, an dem Ihre Anwendungen gehostet werden können. Dies schließt den Umstieg auf Plattformen ein, die Ihre Arbeitslasten möglicherweise besser bedienen, oder einfach bei App Engine zu bleiben und ein Upgrade auf eine modernere Sprachversion wie gerade beschrieben durchzuführen.
Die Python 2-Beispielanwendung für Modul 1 verwendet den gebündelten Datastore-Dienst über App Engine NDB. Die App hat bereits Frameworks von Webanwendung zu Flask migriert – abgeschlossen im Codelab für Modul 1 –, aber die Datastore-Nutzung ist intakt.
Diese Anleitung umfasst die folgenden Schritte:
- Einrichtung/Vorarbeit
- Konfiguration aktualisieren
- Anwendungscode ändern
3. Einrichtung/Vorarbeit
In diesem Abschnitt wird Folgendes erläutert:
- Cloud-Projekt einrichten
- Baseline-Beispiel-App abrufen
- Referenz-App noch einmal bereitstellen und validieren
Mit diesen Schritten stellen Sie sicher, dass Sie mit funktionierendem Code beginnen.
1. Projekt einrichten
Wenn du das Codelab für Modul 1 abgeschlossen hast, empfehlen wir dir, dasselbe Projekt (und denselben Code) wiederzuverwenden. Alternativ können Sie ein neues Cloud-Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Achten Sie darauf, dass das Projekt ein aktives Rechnungskonto hat, in dem der App Engine-Dienst aktiviert wurde.
2. Baseline-Beispiel-App abrufen
Eine der Voraussetzungen für dieses Codelab ist eine funktionierende App Engine-App für Modul 1. Schließen Sie das Codelab für Modul 1 ab (empfohlen) oder kopieren Sie die Modul 1-Anwendung aus dem Repository. Unabhängig davon, ob Sie Ihren oder unseren verwenden, starten wir im Code für Modul 1. In diesem Codelab werden Sie Schritt für Schritt durch die einzelnen Schritte geführt. Abschließend erhalten Sie Code, der dem im Repository-Ordner „FINISH“ des Moduls 7 enthaltenen Ordner ähnelt.
- START: Modul 1 Ordner (Python 2)
- FINISH: Module 1b Ordner (Python 3)
- Gesamtes Repository (um die ZIP-Datei zu klonen oder herunterzuladen)
Unabhängig davon, welche Anwendung für Modul 1 Sie verwenden, sollte der Ordner so aussehen, möglicherweise auch mit einem lib
-Ordner:
$ ls README.md appengine_config.py requirements.txt app.yaml main.py templates
3. Referenz-App noch einmal bereitstellen
Führen Sie die folgenden Schritte aus, um die Anwendung „Modul 1“ (noch einmal) bereitzustellen:
- Löschen Sie den Ordner
lib
, falls vorhanden, und führen Siepip install -t lib -r requirements.txt
aus, umlib
neu zu füllen. Wenn Sie Python 2 und 3 installiert haben, müssen Sie stattdessen möglicherweise den Befehlpip2
verwenden. - Prüfen Sie, ob Sie das
gcloud
-Befehlszeilentool installiert und initialisiert und seine Nutzung überprüft haben. - Legen Sie
gcloud config set project
PROJECT_ID
für Ihr Cloud-Projekt fest, wenn SiePROJECT_ID
nicht bei jedem ausgegebenengcloud
-Befehl eingeben möchten. - Beispielanwendung mit
gcloud app deploy
bereitstellen - Prüfen, ob die App für Modul 1 wie erwartet ausgeführt wird, ohne dass die letzten Besuche angezeigt werden (siehe Abbildung unten)
4. Konfiguration aktualisieren
Nachdem Sie diese Schritte erfolgreich ausgeführt haben und Ihre Webanwendung funktioniert, können Sie diese Anwendung zu Python 3 portieren, beginnend mit „config“.
SDK zur Datei „requirements.txt“ hinzufügen
Die Python 3-Laufzeit von App Engine reduziert den Aufwand für die Verwendung von Drittanbieterbibliotheken erheblich. Du brauchst sie nur in requirements.txt
aufzulisten. Wenn Sie die gebündelten Dienste in Python 3 verwenden möchten, fügen Sie das App Engine SDK-Paket appengine-python-standard
hinzu. Das SDK-Paket verbindet sich mit Flask aus Modul 1:
flask
appengine-python-standard
app.yaml aktualisieren
Führen Sie die folgenden Schritte aus, um Konfigurationsänderungen auf Ihre app.yaml
-Datei anzuwenden:
- Ersetzen Sie die Anweisung
runtime
durch den unterstützten Python 3-Release. Geben Sie beispielsweise für Python 3.10python310
an. - Löschen Sie die Anweisungen
threadsafe
undapi_version
, da keine dieser Anweisungen in Python 3 verwendet wird. - Löschen Sie den Abschnitt
handlers
vollständig, da diese App nur Script-Handler hat. Wenn Ihre Anwendung Handler für statische Dateien hat, lassen Sie diese inhandlers
unverändert. - Im Gegensatz zur Python 2-Laufzeit unterstützt die Python 3-Laufzeit keine integrierten Drittanbieterbibliotheken. Wenn Ihre App in
app.yaml
einenlibraries
-Abschnitt hat, löschen Sie den gesamten Bereich. Erforderliche Pakete müssen wie nicht integrierte Bibliotheken nur unterrequirements.txt
aufgelistet werden. Da unsere Beispiel-App keinenlibraries
-Abschnitt hat, fahren Sie mit dem nächsten Schritt fort. - Erstellen Sie eine
app_engine_apis
-Anweisung mit dem Werttrue
, um sie zu verwenden. Dies entspricht dem Hinzufügen des App Engine SDK-Pakets oben zurequirements.txt
.
Zusammenfassung der erforderlichen Änderungen an app.yaml
:
VORHER:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
NACHHER:
runtime: python310
app_engine_apis: true
Andere Konfigurationsdateien
Da alle Drittanbieterpakete nur in requirements.txt
aufgeführt werden müssen, wird es nicht benötigt, es sei denn, Sie haben in appengine_config.py
etwas Besonderes. Löschen Sie es daher. Da alle Bibliotheken von Drittanbietern während des Build-Prozesses automatisch installiert werden, müssen sie weder kopiert noch übernommen werden. Sie müssen also weder den pip install
-Befehl noch den lib
-Ordner mehr löschen. Zusammenfassung:
appengine_config.py
Datei löschenlib
Ordner löschen
Damit sind alle erforderlichen Konfigurationsänderungen abgeschlossen.
5. Anwendungscode ändern
Für den Zugriff auf die meisten verfügbaren gebündelten Dienste in der Python 3-Laufzeitumgebung ist ein kurzer Code erforderlich, der das Anwendungsobjekt Web Server Gateway Interface (WSGI) in main.py
umschließt. Die Wrapper-Funktion ist google.appengine.api.wrap_wsgi_app()
. Sie verwenden sie, indem Sie sie importieren und Ihr WSGI-Objekt darin einschließen. Nehmen Sie die folgenden Änderungen vor, um das erforderliche Update für Flask in main.py
widerzuspiegeln:
VORHER:
from flask import Flask, render_template, request
from google.appengine.ext import ndb
app = Flask(__name__)
NACHHER:
from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb
app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
Weitere Informationen zu Beispielen für WSGI-Wrapping für andere Python-Frameworks finden Sie in der Dokumentation.
In diesem Beispiel erhält Ihre Anwendung Zugriff auf die meisten gebündelten Dienste in Python 3. Für andere Dienste wie Blobstore und Mail ist jedoch zusätzlicher Code erforderlich. Wir behandeln diese Beispiele in einem anderen Migrationsmodul.
Damit sind alle erforderlichen Änderungen zum Hinzufügen von gebündelten App Engine-Diensten zur Beispiel-App für Modul 1 abgeschlossen. Die Anwendung ist bereits mit Python 2 und 3 kompatibel, sodass für die Portierung in Python 3 außer dem, was Sie bereits bei der Konfiguration getan haben, keine weiteren Änderungen vorgenommen wurden. Der letzte Schritt: Stellen Sie diese geänderte Anwendung in der App Engine Python 3-Laufzeit der nächsten Generation bereit und prüfen Sie, ob die Aktualisierungen erfolgreich waren.
6. Zusammenfassung/Bereinigung
In diesem Abschnitt wird dieses Codelab abgeschlossen. Dazu wird die App bereitgestellt und geprüft, ob sie wie vorgesehen und in allen ausgegebenen Ausgabedaten funktioniert. Führen Sie nach der App-Überprüfung alle Bereinigungsschritte durch und erwägen Sie die nächsten Schritte.
Anwendung bereitstellen und prüfen
Stellen Sie die Python 3-Anwendung mit gcloud app deploy
bereit und prüfen Sie, ob sie wie in Python 2 funktioniert. Da keine der Funktionen geändert wird, sollte die Ausgabe mit der App für Modul 1 identisch sein:
Abschließende Hinweise
- Vergleichen Sie Ihr Wissen mit dem im Ordner 1b des Moduls (FINISH). Wenn Sie bei der Arbeit einen Fehler gemacht haben, nehmen Sie entsprechende Anpassungen vor.
- Vergleichen Sie Modul 0
main.py
mit dem Modul 1bmain.py
auf dieser Seite, wenn Ihre App nochwebapp2
verwendet. Führen Sie dann das Codelab für Modul 1 durch, um zu erfahren, wie Sie vonwebapp2
zu Flask migrieren.
Herzlichen Glückwunsch, dass Sie den ersten Schritt zur Portierung Ihrer Python 2-App Engine-Anwendungen auf Python 3 unternommen haben, ohne die gebündelten Dienste zu nutzen.
Bereinigen
Allgemein
Falls Sie vorerst fertig sind, empfehlen wir Ihnen, Ihre App Engine-Anwendung zu deaktivieren, um Gebühren zu vermeiden. Wenn Sie jedoch weitere Tests oder Experimente durchführen möchten, bietet die App Engine-Plattform ein kostenloses Kontingent. Solange Sie diese Nutzungsstufe nicht überschreiten, sollten Ihnen keine Kosten in Rechnung gestellt werden. Das bezieht sich auf die Rechenleistung. Es können jedoch auch Gebühren für relevante App Engine-Dienste anfallen. Weitere Informationen finden Sie auf der Preisseite. Wenn diese Migration andere Cloud-Dienste betrifft, werden diese separat abgerechnet. Lesen Sie in beiden Fällen gegebenenfalls den Abschnitt „Speziell für dieses Codelab“. weiter unten.
Zur vollständigen Offenlegung fallen bei der Bereitstellung auf einer serverlosen Computing-Plattform von Google Cloud wie App Engine geringfügige Build- und Speicherkosten an. Für Cloud Build und Cloud Storage gibt es ein eigenes kostenloses Kontingent. Die Speicherung dieses Images verbraucht einen Teil dieses Kontingents. Möglicherweise leben Sie in einer Region, in der es keine solche kostenlose Stufe gibt. Achten Sie daher auf Ihre Speichernutzung, um potenzielle Kosten zu minimieren. Bestimmte Cloud Storage-„Ordner“ sollten Sie Folgendes überprüfen:
console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
- Die Speicherlinks oben hängen von Ihrer
PROJECT_ID
- und *LOC
*-Adresse ab, z. B. „us
“ wenn Ihre App in den USA gehostet wird.
Wenn Sie jedoch nicht mit dieser Anwendung oder anderen verwandten Migrations-Codelabs fortfahren und alles vollständig löschen möchten, beenden Sie Ihr Projekt.
Nur für dieses Codelab
Die unten aufgeführten Dienste gelten nur für dieses Codelab. Weitere Informationen finden Sie in der Dokumentation des jeweiligen Produkts:
- Der App Engine Datastore-Dienst wird von Cloud Datastore (Cloud Firestore im Datastore-Modus) bereitgestellt, der ebenfalls eine kostenlose Stufe hat. Weitere Informationen finden Sie auf der Preisseite.
Nächste Schritte
Von hier aus können Sie in verschiedene Richtungen gehen:
- Code mit gebündelten Diensten aktualisieren, die weitere Codeänderungen erfordern
- Von gebündelten Diensten zu eigenständigen Cloud-Produkten migrieren
- Von App Engine zu einer anderen serverlosen Cloud-Plattform migrieren
Für den Zugriff auf andere gebündelte Dienste wie Blobstore, Mail und Deferred sind weitere Codeänderungen erforderlich. Zu den Migrationsmodulen, die sich auf die Abkehr von den gebündelten Legacy-Diensten von App Engine konzentrieren, gehören:
- Modul 2: App Engine NDB zu Cloud NDB
- Module 7–9: App Engine-TaskQueue (Push-Aufgaben) für Cloud Tasks
- Module 12–13: App Engine Memcache für Cloud Memorystore
- Module 15–16: App Engine Blobstore für Cloud Storage
- Module 18–19: App Engine TaskQueue (Pull-Aufgaben) für Cloud Pub/Sub
App Engine ist nicht mehr die einzige serverlose Plattform in Google Cloud. Wenn Sie eine kleine App Engine-Anwendung oder eine mit eingeschränkter Funktionalität haben und sie in einen eigenständigen Mikrodienst umwandeln möchten oder eine monolithische Anwendung in mehrere wiederverwendbare Komponenten aufteilen möchten, sind dies gute Gründe für einen Wechsel zu Cloud Functions. Wenn die Containerisierung Teil Ihres Workflows für die Anwendungsentwicklung geworden ist, insbesondere wenn sie aus einer CI/CD-Pipeline (Continuous Integration/Continuous Delivery oder Bereitstellung) besteht, sollten Sie eine Migration zu Cloud Run in Betracht ziehen. Diese Szenarien werden in den folgenden Modulen behandelt:
- Migration von App Engine zu Cloud Functions: siehe Modul 11
- Migration von App Engine zu Cloud Run: Siehe Modul 4 zum Containerisieren Ihrer Anwendung mit Docker oder Modul 5 zur Implementierung von Containern, Docker-Kenntnissen oder
Dockerfile
Der Wechsel zu einer anderen serverlosen Plattform ist optional. Wir empfehlen Ihnen, die besten Optionen für Ihre Anwendungen und Anwendungsfälle zu erwägen, bevor Sie Änderungen vornehmen.
Unabhängig davon, welches Migrationsmodul Sie als Nächstes in Betracht ziehen, können Sie auf alle Inhalte der Serverless Migration Station (Codelabs, Videos, Quellcode [falls verfügbar]) über das Open-Source-Repository zugreifen. Im README
des Repositorys finden Sie außerdem Informationen dazu, welche Migrationen berücksichtigt werden müssen und welche relevante „Reihenfolge“ Sie haben Migrationsmodule.
7. Zusätzliche Ressourcen
Im Folgenden finden Sie zusätzliche Ressourcen für Entwickler, die sich näher mit diesem oder verwandten Migrationsmodul und ähnlichen Produkten befassen. Dazu gehören Orte, an denen Sie Feedback zu diesen Inhalten geben können, Links zum Code und verschiedene Dokumentationen, die für Sie nützlich sein könnten.
Codelab-Probleme/Feedback
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 1b (FINISH) finden Sie in der folgenden Tabelle. Sie können auch über das Repository für alle App Engine-Codelab-Migrationen aufgerufen werden.
Codelab | Python 2 | Python 3 |
– | ||
Modul 17 (dieses Codelab) | – | Code (mod1b-flask) |
Online-Ressourcen
Nachfolgend finden Sie Onlineressourcen, die für diese Anleitung relevant sein könnten:
Gebündelte App Engine-Dienste
- Auf gebündelte Dienste in der Python 3-Laufzeit der nächsten Generation zugreifen
- Anwendung in Modul 0 (Python 2) und Anwendung in Modul 1b (Python 3) im direkten Vergleich
- Beispiele für WSGI-Objekt-Wrapper des App Engine SDK
- Unterstützung von gebündelten App Engine-Diensten in Laufzeiten der nächsten Generation (2021)
Allgemeine Dokumentation zu App Engine
- App Engine-Dokumentation
- Python 2-Laufzeit der App Engine (Standardumgebung)
- Integrierte App Engine-Bibliotheken in Python 2 App Engine verwenden
- Python 3-Laufzeit von App Engine (Standardumgebung)
- Unterschiede zwischen Python 2 und 3 Laufzeiten der App Engine (Standardumgebung)
- Python 2 zu 3 Migrationsanleitung für App Engine (Standardumgebung)
- Informationen zu Preisen und Kontingenten für App Engine
- Einführung der App Engine-Plattform der zweiten Generation (2018)
- Langzeitsupport für Legacy-Laufzeiten
- Repository mit Beispielen für die Migration der Dokumentation
- Repository für Migrationsbeispiele
Weitere Cloud-Informationen
- Python auf der Google Cloud Platform
- Google Cloud-Clientbibliotheken für Python
- „Immer kostenlos“ von Google Cloud Stufe
- Google Cloud SDK (
gcloud
-Befehlszeilentool) - Gesamte Google Cloud-Dokumentation
Videos
- Serverlose Migrationsstation
- Serverlose Expeditionen
- Google Cloud Tech abonnieren
- Google Developers abonnieren
Lizenz
Dieser Text ist mit einer Creative Commons Attribution 2.0 Generic License lizenziert.