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

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

Umfrage

Wie möchten Sie diese Anleitung nutzen?

<ph type="x-smartling-placeholder"></ph> Nur bis zum Ende lesen Lies sie dir durch und absolviere die Übungen

Wie würden Sie Ihre Erfahrung mit Python bewerten?

<ph type="x-smartling-placeholder"></ph> Neuling Mittel Kompetent

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

<ph type="x-smartling-placeholder"></ph> Neuling Mittel Kompetent

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:

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

3. Einrichtung/Vorarbeit

In diesem Abschnitt wird Folgendes erläutert:

  1. Cloud-Projekt einrichten
  2. Baseline-Beispiel-App abrufen
  3. 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.

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:

  1. Löschen Sie den Ordner lib, falls vorhanden, und führen Sie pip install -t lib -r requirements.txt aus, um lib neu zu füllen. Wenn Sie Python 2 und 3 installiert haben, müssen Sie stattdessen möglicherweise den Befehl pip2 verwenden.
  2. Prüfen Sie, ob Sie das gcloud-Befehlszeilentool installiert und initialisiert und seine Nutzung überprüft haben.
  3. Legen Sie gcloud config set project PROJECT_ID für Ihr Cloud-Projekt fest, wenn Sie PROJECT_ID nicht bei jedem ausgegebenen gcloud-Befehl eingeben möchten.
  4. Beispielanwendung mit gcloud app deploy bereitstellen
  5. Prüfen, ob die App für Modul 1 wie erwartet ausgeführt wird, ohne dass die letzten Besuche angezeigt werden (siehe Abbildung unten)

a7a9d2b80d706a2b.png

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:

  1. Ersetzen Sie die Anweisung runtime durch den unterstützten Python 3-Release. Geben Sie beispielsweise für Python 3.10 python310 an.
  2. Löschen Sie die Anweisungen threadsafe und api_version, da keine dieser Anweisungen in Python 3 verwendet wird.
  3. 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 in handlers unverändert.
  4. Im Gegensatz zur Python 2-Laufzeit unterstützt die Python 3-Laufzeit keine integrierten Drittanbieterbibliotheken. Wenn Ihre App in app.yaml einen libraries-Abschnitt hat, löschen Sie den gesamten Bereich. Erforderliche Pakete müssen wie nicht integrierte Bibliotheken nur unter requirements.txt aufgelistet werden. Da unsere Beispiel-App keinen libraries-Abschnitt hat, fahren Sie mit dem nächsten Schritt fort.
  5. Erstellen Sie eine app_engine_apis-Anweisung mit dem Wert true, um sie zu verwenden. Dies entspricht dem Hinzufügen des App Engine SDK-Pakets oben zu requirements.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öschen
  • lib 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:

a7a9d2b80d706a2b.png

Abschließende Hinweise

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:

Nächste Schritte

Von hier aus können Sie in verschiedene Richtungen gehen:

  1. Code mit gebündelten Diensten aktualisieren, die weitere 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. Zu den Migrationsmodulen, die sich auf die Abkehr von den gebündelten Legacy-Diensten von App Engine konzentrieren, gehören:

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 1

code

–

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

Allgemeine Dokumentation zu App Engine

Weitere Cloud-Informationen

Videos

Lizenz

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