Unterstützung für gebündelte App Engine-Dienste erweitern: Teil 1 (Modul 17)

1. Übersicht

Die Codelabs der Reihe „Serverless Migration Station“ (selbstgesteuerte, praktische Anleitungen) und die zugehörigen Videos sollen serverlosen Google Cloud-Entwicklern helfen, ihre Anwendungen zu modernisieren. Dazu werden sie durch eine oder mehrere Migrationen geführt, bei denen es in erster Linie darum geht, von Legacy-Diensten wegzukommen. Dadurch werden Ihre Apps portierbarer und Sie erhalten mehr Optionen und Flexibilität. Sie können eine größere Auswahl an Cloud-Produkten einbinden und darauf zugreifen und einfacher auf neuere Sprachversionen upgraden. Die Reihe konzentriert sich zwar anfangs auf die ersten Cloud-Nutzer, vor allem auf App Engine-Entwickler (Standardumgebung), ist aber breit genug, um auch andere serverlose Plattformen wie Cloud Functions und Cloud Run oder andere Plattformen einzubeziehen, sofern zutreffend.

Bisher mussten Entwickler von den alten „gebündelten Diensten“ von App Engine wie Datastore und Memcache migrieren, bevor sie Sprachversionen aktualisieren konnten. Das waren zwei potenziell schwierige Aufgaben direkt nacheinander. Da viele der wichtigsten gebündelten Dienste im App Engine-Dienst der 2. Generation verfügbar sind, können Entwickler ihre Anwendungen jetzt auf die neuesten Laufzeiten portieren und gleichzeitig (die meisten) der gebündelten Dienste weiterhin verwenden. In diesem Codelab wird gezeigt, wie Sie eine Beispielanwendung von Python 2 auf Python 3 aktualisieren und dabei den gebündelten Datastore-Dienst (über die App Engine NDB-Bibliothek) beibehalten. Für die meisten gebündelten Dienste ist nur eine geringfügige Aktualisierung des Codes erforderlich, wie in diesem Tutorial beschrieben. Für andere sind umfangreichere Änderungen erforderlich, die in „Teil 2“, einem Folgemodul und Codelab, behandelt werden.

Lerninhalte

  • Beispiel-App Engine-App von Python 2 zu Python 3 portieren
  • App-Konfiguration aktualisieren, um das App Engine SDK einzuschließen
  • SDK-Code zur App hinzufügen, der gebündelte Dienste in Laufzeiten der 2. Generation wie Python 3 unterstützt

Voraussetzungen

Umfrage

Wie werden Sie diese Anleitung verwenden?

Nur lesen Lesen und Übungen durchführen

Wie würden Sie Ihre Erfahrung mit Python bewerten?

Anfänger Mittelstufe Fortgeschrittene

Wie würden Sie Ihre Erfahrungen mit Google Cloud-Diensten bewerten?

Anfänger Mittelstufe Fortgeschritten

2. Hintergrund

Der ursprüngliche App Engine-Dienst wurde 2008 eingeführt und enthielt eine Reihe von Legacy-APIs (jetzt als gebündelte Dienste bezeichnet), um Entwicklern das Erstellen und Bereitstellen von Anwendungen weltweit zu erleichtern. Dazu gehören Datastore, Memcache und Task Queue. Das war zwar praktisch, aber Nutzer machten sich Sorgen um die Portabilität ihrer Apps, wenn sie proprietäre APIs verwendeten, die sie an App Engine banden. Sie wollten, dass ihre Apps portabler sind. Da viele dieser gebündelten Dienste zu eigenständigen Cloud-Produkten weiterentwickelt wurden, wurde 2018 die Plattform der nächsten Generation ohne sie eingeführt.

Heute sind Python 2-Entwickler bestrebt, ein Upgrade auf Python 3 durchzuführen. Bei einer 2.x-App, die gebündelte Dienste verwendet, war eine Migration von diesen Diensten erforderlich, bevor die Apps auf 3.x portiert werden konnten. Dies bedeutete zwei aufeinanderfolgende, möglicherweise schwierige, erzwungene Migrationen. Um diesen Übergang zu erleichtern, hat das App Engine-Team im Herbst 2021 ein „Wurmloch“ in die Vergangenheit eingeführt, über das Anwendungen, die in Laufzeiten der nächsten Generation ausgeführt werden, auf viele dieser gebündelten Dienste zugreifen können. Diese Version enthält zwar nicht alle in den ursprünglichen Runtimes verfügbaren Dienste, aber wichtige Dienste wie Datastore, Task Queue und Memcache sind verfügbar.

In diesem Codelab werden die erforderlichen Änderungen gezeigt, die Sie vornehmen müssen, um Ihre App auf Python 3 zu aktualisieren und gleichzeitig die Verwendung gebündelter Dienste beizubehalten. Ziel ist es, Ihre Apps in den neuesten Laufzeiten auszuführen. So können Sie die gebündelten Dienste in Ihrem eigenen Tempo durch eigenständige Cloud-Äquivalente oder Drittanbieteralternativen ersetzen, anstatt dass dies ein Hindernis für ein Upgrade auf 3.x ist. Die Migration von gebündelten Diensten ist zwar nicht mehr erforderlich, bietet Ihnen aber mehr Portabilität und Flexibilität in Bezug auf den Hostingort Ihrer Anwendungen. Sie können beispielsweise zu Plattformen wechseln, die Ihre Arbeitslasten besser unterstützen, oder einfach in App Engine bleiben und wie oben beschrieben auf eine modernere Sprachversion upgraden.

In der Python 2-Beispielanwendung aus Modul 1 wird der gebündelte Datastore-Dienst über App Engine NDB verwendet. Die App hat bereits Frameworks von webapp2 zu Flask migriert. Das wurde im Codelab zu Modul 1 abgeschlossen. Die Datastore-Nutzung ist jedoch unverändert.

Diese Anleitung umfasst die folgenden Schritte:

  1. Einrichtung/Vorbereitung
  2. Konfiguration aktualisieren
  3. Anwendungscode ändern

3. Einrichtung/Vorbereitung

In diesem Abschnitt wird Folgendes erläutert:

  1. Cloud-Projekt einrichten
  2. Beispiel-App für die Baseline abrufen
  3. Ausgangsanwendung (neu) bereitstellen und validieren

Mit diesen Schritten stellen Sie sicher, dass Sie mit funktionierendem Code beginnen.

1. Projekt einrichten

Wenn Sie das Codelab zu Modul 1 abgeschlossen haben, empfehlen wir, dasselbe Projekt (und denselben Code) wiederzuverwenden. Alternativ können Sie ein völlig neues Cloud-Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Prüfen Sie, ob das Projekt ein aktives Rechnungskonto hat, in dem der App Engine-Dienst aktiviert wurde.

2. Beispiel-App für die Baseline abrufen

Eine der Voraussetzungen für dieses Codelab ist eine funktionierende App Engine-App aus Modul 1. Führen Sie das Codelab zu Modul 1 aus (empfohlen) oder kopieren Sie die App aus Modul 1 aus dem Repository. Unabhängig davon, ob Sie Ihren oder unseren Code verwenden, ist der Code aus Modul 1 der Ausgangspunkt. In diesem Codelab werden Sie durch jeden Schritt geführt. Am Ende erhalten Sie Code, der dem im Repo-Ordner „FINISH“ von Modul 7 ähnelt.

Unabhängig davon, welche App aus Modul 1 Sie verwenden, sollte der Ordner so aussehen wie unten, möglicherweise auch mit einem lib-Ordner:

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

3. Referenz-App (erneut) bereitstellen

Führen Sie die folgenden Schritte aus, um die App aus Modul 1 (neu) bereitzustellen:

  1. Löschen Sie den Ordner lib, falls er vorhanden ist, und führen Sie pip install -t lib -r requirements.txt aus, um lib neu zu füllen. Wenn Sie sowohl Python 2 als auch Python 3 installiert haben, müssen Sie möglicherweise stattdessen den Befehl pip2 verwenden.
  2. Achten Sie darauf, dass Sie das gcloud-Befehlszeilentool installiert und initialisiert haben und sich mit der Verwendung vertraut gemacht haben.
  3. Legen Sie Ihr Cloud-Projekt mit gcloud config set project PROJECT_ID fest, wenn Sie Ihre PROJECT_ID nicht bei jedem ausgeführten gcloud-Befehl eingeben möchten.
  4. Beispiel-App mit gcloud app deploy bereitstellen
  5. Prüfen Sie, ob die App aus Modul 1 wie erwartet ausgeführt wird und die letzten Besuche ohne Probleme angezeigt werden (siehe unten).

a7a9d2b80d706a2b.png

4. Konfiguration aktualisieren

Sobald Sie diese Schritte erfolgreich ausgeführt haben und Ihre Webanwendung funktioniert, können Sie sie zu Python 3 portieren. Beginnen Sie mit der Konfiguration.

SDK zu „requirements.txt“ hinzufügen

Die App Engine-Python 3-Laufzeitumgebung reduziert den Aufwand für die Verwendung von Drittanbieterbibliotheken erheblich. Es reicht aus, sie 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 wird in Modul 1 zu Flask hinzugefügt:

flask
appengine-python-standard

app.yaml aktualisieren

Führen Sie die folgenden Schritte aus, um Konfigurationsänderungen auf Ihre app.yaml-Datei anzuwenden:

  1. Ersetzen Sie die runtime-Anweisung durch die unterstützte Python 3-Version. Geben Sie beispielsweise python310 für Python 3.10 an.
  2. Löschen Sie sowohl die threadsafe- als auch die api_version-Anweisung, da beide in Python 3 nicht verwendet werden.
  3. Löschen Sie den Abschnitt handlers vollständig, da diese App nur Skript-Handler hat. Wenn Ihre App Handler für statische Dateien hat, lassen Sie sie in handlers unverändert.
  4. Die Python 3-Laufzeit unterstützt keine integrierten Drittanbieterbibliotheken wie die Python 2-Laufzeit. Wenn Ihre App in app.yaml einen Abschnitt libraries hat, löschen Sie den gesamten Abschnitt. Erforderliche Pakete müssen nur in requirements.txt aufgeführt werden, genau wie nicht integrierte Bibliotheken. Unsere Beispiel-App hat keinen libraries-Abschnitt. Fahren Sie mit dem nächsten Schritt fort.
  5. Erstellen Sie eine app_engine_apis-Anweisung, die auf true festgelegt ist, um sie zu verwenden. Dies entspricht dem Hinzufügen des App Engine SDK-Pakets zu requirements.txt oben.

Zusammenfassung der erforderlichen Änderungen an app.yaml:

VORHER:

runtime: python27
threadsafe: yes
api_version: 1

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

DANACH:

runtime: python310
app_engine_apis: true

Andere Konfigurationsdateien

Da alle Drittanbieterpakete nur in requirements.txt aufgeführt werden müssen, ist appengine_config.py nicht erforderlich, sofern Sie dort nichts Besonderes haben. Löschen Sie die Datei daher. Da alle Drittanbieterbibliotheken während des Build-Prozesses automatisch installiert werden, müssen sie auch nicht kopiert oder eingebunden werden. Das bedeutet, dass es weder den Befehl pip install noch den Ordner lib gibt. Löschen Sie ihn also. Zusammenfassen:

  • Datei „appengine_config.py“ löschen
  • lib-Ordner löschen

Damit sind alle erforderlichen Konfigurationsänderungen abgeschlossen.

5. Anwendungscode ändern

Für den Zugriff auf die meisten der verfügbaren gebündelten Dienste in der Python 3-Laufzeitumgebung ist ein kurzer Codeabschnitt erforderlich, der das Web Server Gateway Interface (WSGI)-Anwendungsobjekt 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 damit umschließen. Nehmen Sie die folgenden Änderungen vor, um die erforderliche Aktualisierung für Flask in main.py zu berücksichtigen:

VORHER:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

DANACH:

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)

Beispiele für WSGI-Wrapping für andere Python-Frameworks finden Sie in der Dokumentation.

Dieses Beispiel funktioniert, um Ihrer App Zugriff auf die meisten gebündelten Dienste in Python 3 zu gewähren. Für andere Dienste wie Blobstore und Mail ist jedoch zusätzlicher Code erforderlich. Diese Beispiele werden in einem anderen Migrationsmodul behandelt.

Damit sind alle erforderlichen Änderungen abgeschlossen, um die Verwendung von gebündelten App Engine-Diensten in die Beispielanwendung aus Modul 1 aufzunehmen. Die Anwendung ist bereits mit Python 2 und 3 kompatibel. Daher sind keine zusätzlichen Änderungen erforderlich, um sie zu Python 3 zu portieren. Im letzten Schritt müssen Sie diese geänderte App in der App Engine-Python 3-Laufzeit der nächsten Generation bereitstellen und bestätigen, dass die Aktualisierungen erfolgreich waren.

6. Zusammenfassung/Bereinigung

In diesem Abschnitt wird das Codelab abgeschlossen, indem die App bereitgestellt und geprüft wird, ob sie wie vorgesehen funktioniert und ob die Ausgabe korrekt ist. Führen Sie nach der App-Validierung alle erforderlichen Bereinigungen durch und überlegen Sie sich die nächsten Schritte.

Anwendung bereitstellen und überprüfen

Stellen Sie die Python 3-App mit gcloud app deploy bereit und prüfen Sie, ob sie wie in Python 2 funktioniert. Die Funktionalität ändert sich nicht, daher sollte die Ausgabe mit der App aus Modul 1 identisch sein:

a7a9d2b80d706a2b.png

Abschließende Hinweise

Herzlichen Glückwunsch, dass Sie den ersten Schritt zur Portierung Ihrer Python 2-App Engine-Anwendungen zu Python 3 unternommen haben und die gebündelten Dienste weiterhin verwenden.

Bereinigen

Allgemein

Wenn Sie die App vorerst nicht mehr benötigen, empfehlen wir Ihnen, sie zu deaktivieren, um Abrechnungen zu vermeiden. Wenn Sie jedoch weitere Tests durchführen möchten, bietet die App Engine-Plattform ein kostenloses Kontingent. Solange Sie diese Nutzungsebene nicht überschreiten, werden Ihnen keine Gebühren berechnet. Das gilt für die Rechenleistung. Es können aber auch Gebühren für relevante App Engine-Dienste anfallen. Weitere Informationen finden Sie auf der Preisseite. Wenn bei dieser Migration andere Cloud-Dienste beteiligt sind, werden diese separat abgerechnet. Sehen Sie sich in beiden Fällen gegebenenfalls den Abschnitt „Spezifisch für dieses Codelab“ unten an.

Die Bereitstellung auf einer serverlosen Google Cloud-Compute-Plattform wie App Engine verursacht geringe Build- und Speicherkosten. Cloud Build und Cloud Storage haben jeweils ein eigenes kostenloses Kontingent. Das Speichern dieses Bildes verbraucht einen Teil dieses Kontingents. Möglicherweise leben Sie jedoch in einer Region, in der es kein solches kostenloses Kontingent gibt. Achten Sie daher auf Ihre Speichernutzung, um potenzielle Kosten zu minimieren. Folgende Cloud Storage-„Ordner“ sollten Sie sich ansehen:

  • 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 oben genannten Speicherlinks hängen von Ihrem PROJECT_ID und *LOC*ab, z. B. „us“, wenn Ihre App in den USA gehostet wird.

Wenn Sie diese Anwendung oder andere zugehörige Migrations-Codelabs nicht weiter verwenden und alles vollständig löschen möchten, beenden Sie Ihr Projekt.

Spezifisch für dieses Codelab

Die unten aufgeführten Dienste sind nur für dieses Codelab verfügbar. Weitere Informationen finden Sie in der Dokumentation der einzelnen Produkte:

Nächste Schritte

Es gibt mehrere Möglichkeiten, wie Sie nun vorgehen können:

  1. Code mit gebündelten Diensten aktualisieren, die mehr Codeänderungen erfordern
  2. Von gebündelten Diensten zu eigenständigen Cloud-Produkten migrieren
  3. 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. Folgende Migrationsmodule sind für die Migration von gebündelten App Engine-Legacy-Diensten relevant:

App Engine ist nicht mehr die einzige serverlose Plattform in Google Cloud. Wenn Sie eine kleine App Engine-Anwendung oder eine Anwendung 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 Anwendungsentwicklungs-Workflows geworden ist, insbesondere wenn er aus einer CI/CD-Pipeline (Continuous Integration/Continuous Delivery oder Deployment) besteht, sollten Sie eine Migration zu Cloud Run in Betracht ziehen. Diese Szenarien werden in den folgenden Modulen behandelt:

  • Von App Engine zu Cloud Functions migrieren: Modul 11
  • Von App Engine zu Cloud Run migrieren: Modul 4 enthält Informationen zum Containerisieren Ihrer App mit Docker und Modul 5 zum Containerisieren ohne Container, Docker-Kenntnisse oder Dockerfiles.

Der Wechsel zu einer anderen serverlosen Plattform ist optional. Wir empfehlen, die besten Optionen für Ihre Apps und Anwendungsfälle zu prüfen, bevor Sie Änderungen vornehmen.

Unabhängig davon, welches Migrationsmodul Sie als Nächstes in Betracht ziehen, können Sie auf alle Serverless Migration Station-Inhalte (Codelabs, Videos, Quellcode [sofern verfügbar]) über das zugehörige Open-Source-Repository zugreifen. Das README des Repositorys enthält auch Informationen dazu, welche Migrationen infrage kommen und welche Reihenfolge der Migrationsmodule relevant ist.

7. Zusätzliche Ressourcen

Unten finden Sie weitere Ressourcen für Entwickler, die sich näher mit diesem oder einem ähnlichen Migrationsmodul sowie mit zugehörigen Produkten befassen möchten. 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.

Probleme mit Codelabs/Feedback

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 1 (START) und Modul 1b (FINISH) finden Sie in der Tabelle unten. Sie können auch über das Repository für alle App Engine-Codelab-Migrationen auf sie zugreifen.

Codelab

Python 2

Python 3

Modul 1

code

–

Modul 17 (dieses Codelab)

–

code (mod1b-flask)

Onlineressourcen

Unten finden Sie Online-Ressourcen, die für diese Anleitung relevant sein könnten:

Gebündelte App Engine-Dienste

Allgemeine App Engine-Dokumentation

Andere Cloud-Informationen

Videos

Lizenz

Dieser Text ist mit einer Creative Commons Attribution 2.0 Generic License lizenziert.