Modul 1: Von App Engine webapp2 zu Flask migrieren

1. Übersicht

Diese Reihe von Codelabs (Tutorials zum selbstbestimmten Lernen) soll Google App Engine-Entwicklern (Standard) helfen, ihre Apps zu modernisieren, indem sie durch eine Reihe von Migrationen geführt werden. Der wichtigste Schritt ist die Umstellung von den in der ursprünglichen Laufzeit gebündelten Diensten, da die Laufzeiten der nächsten Generation flexibler sind und Nutzern eine größere Auswahl an Diensten bieten. Durch die Umstellung auf die neuere Generation der Laufzeit können Sie Google Cloud-Produkte einfacher einbinden, eine größere Auswahl an unterstützten Diensten nutzen und aktuelle Sprachversionen unterstützen.

In dieser ersten Anleitung werden die ersten Migrationsschritte zur Modernisierung des Web-Frameworks in App Engine-Anwendungen gezeigt: die Umstellung von webapp2 auf Flask. In Ihrer App können Sie ein beliebiges Web-Framework verwenden, das das Routing übernimmt. In dieser Anleitung wird jedoch Flask verwendet, da es in der Community weit verbreitet ist.

In diesem Kurs lernen Sie, wie Sie

  • Bibliotheken von Drittanbietern verwenden (integriert oder anderweitig)
  • Konfigurationsdateien aktualisieren
  • Einfache App von webapp2 zu Flask migrieren

Voraussetzungen

Umfrage

Wie werden Sie dieses Codelab verwenden?

Nur lesen Lesen und Übungen machen

2. Hintergrund

Das webapp-Framework wurde gebündelt, als App Engine 2008 zum ersten Mal in Python 2.5 eingeführt wurde. Jahre später wurde es durch den Nachfolger webapp2 ersetzt, als die 2.7-Laufzeit 2013 die 2.5-Laufzeit eingestellt hat.

webapp2 (siehe Dokumentation) ist zwar weiterhin vorhanden und kann außerhalb von App Engine als WSGI-kompatibles Web-Framework verwendet werden, führt aber kein eigenes Routing von Nutzeranfragen zum entsprechenden Code in der Anwendung durch. Stattdessen wird die Weiterleitung des Webtraffics an entsprechende „Handler“ von App Engine, Konfigurationsdateien und dem Entwickler übernommen. Außerdem sind die wichtigsten Vorteile von webapp2 untrennbar mit den gebündelten Diensten von App Engine verbunden, was dazu führt, dass webapp2 effektiv eingestellt wird, obwohl es unter Python 3 funktioniert (siehe auch zugehöriges Problem).

In diesem Modul lernen Sie, wie Sie eine einfache webapp2-App zu Flask migrieren. Flask ist ein Framework, das von App Engine und vielen anderen Diensten außerhalb von Google Cloud unterstützt wird, wodurch Apps viel portabler werden. Wenn Flask nicht das gewünschte Framework für die Migration Ihrer Anwendung ist, können Sie ein anderes auswählen, sofern es ein eigenes Routing hat. In diesem Codelab erfahren IT-Entscheidungsträger und Entwickler, welche Migrationsschritte erforderlich sind. So können Sie sich mit diesem Prozess vertraut machen, unabhängig davon, zu welchem Framework Sie tatsächlich migrieren.

Das sind die wichtigsten Schritte für diese Migration:

  1. Einrichtung/Vorbereitung
  2. Flask-Drittanbieterbibliothek hinzufügen
  3. Anwendungsdateien aktualisieren
  4. HTML-Vorlagendatei aktualisieren

3. Einrichtung/Vorbereitung

Bevor wir mit dem Hauptteil des Tutorials beginnen, richten wir unser Projekt ein, rufen den Code ab und machen Sie dann (erneut) mit dem Befehl gcloud vertraut. Anschließend stellen wir die Baseline-App bereit, damit wir wissen, dass wir mit funktionierendem Code begonnen haben.

1. Projekt einrichten

Als bestehender Entwickler sehen Sie in Ihrem App Engine-Dashboard wahrscheinlich bereits, welche Dienste ausgeführt werden. Für diese Anleitung empfehlen wir, ein neues Projekt zu erstellen oder ein vorhandenes wiederzuverwenden. Prüfen Sie, ob das Projekt ein aktives Abrechnungskonto hat und App Engine (App) aktiviert ist.

2. Baseline-Beispielanwendung herunterladen

Das GAE-Migrationsrepository enthält den gesamten erforderlichen Code. Klonen Sie das Repository oder laden Sie die ZIP-Datei herunter. In dieser Anleitung beginnen Sie mit dem Code im Ordner „Module 0“ (START). Wenn Sie die Anleitung abgeschlossen haben, sollte Ihr Code mit dem Ordner „Module 1“ (FINISH) übereinstimmen. Falls nicht, sehen Sie sich die Unterschiede an, damit Sie mit dem nächsten Lab fortfahren können.

Der Ordner „Module 0“ sollte Dateien wie die folgenden enthalten, wie mit dem POSIX-Befehl ls veranschaulicht:

$ ls
app.yaml        index.html      main.py

3. gcloud-Befehle (wieder) kennenlernen

Wenn Sie den gcloud-Befehl noch nicht auf Ihrem Computer haben, installieren Sie das Google Cloud SDK und sorgen Sie dafür, dass gcloud in Ihrem Ausführungspfad verfügbar ist. Machen Sie sich mit den folgenden gcloud-Befehlen vertraut:

  1. gcloud components update – Google Cloud SDK aktualisieren
  2. gcloud auth login – Melden Sie sich in Ihrem Konto mit Anmeldedaten an.
  3. gcloud config list – GCP-Projektkonfigurationseinstellungen auflisten
  4. gcloud config set project PROJECT_ID – GCP-Projekt-ID festlegen
  5. gcloud app deploy – App Engine-Anwendung bereitstellen

Wenn Sie in letzter Zeit nicht mit gcloud für App Engine entwickelt haben, sollten Sie die ersten vier Befehle (Nr. 1 bis 4) ausführen, um sich vorzubereiten, bevor Sie mit den nächsten Schritten fortfahren. Sehen wir uns diese Befehle kurz an.

Mit gcloud components update wird sichergestellt, dass Sie die neueste Cloud SDK-Version haben. Bei Ausführung dieses Befehls sollte eine Ausgabe wie die folgende angezeigt werden:

$ gcloud components update

Your current Cloud SDK version is: 317.0.0
You will be upgraded to version: 318.0.0

┌──────────────────────────────────────────────────┐
│        These components will be updated.         │
├──────────────────────────┬────────────┬──────────┤
│           Name           │  Version   │   Size   │
├──────────────────────────┼────────────┼──────────┤
│ Cloud SDK Core Libraries │ 2020.11.06 │ 15.5 MiB │
│ gcloud cli dependencies  │ 2020.11.06 │ 10.6 MiB │
└──────────────────────────┴────────────┴──────────┘

The following release notes are new in this upgrade.
Please read carefully for information about new features, breaking changes,
and bugs fixed.  The latest full release notes can be viewed at:
  https://cloud.google.com/sdk/release_notes

318.0.0 (2020-11-10)

      . . .
      (release notes)
      . . .

    Subscribe to these release notes at
    https://groups.google.com/forum/#!forum/google-cloud-sdk-announce.

Do you want to continue (Y/n)?

╔════════════════════════════════════════════════════════════╗
╠═ Creating update staging area                             ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Uninstalling: Cloud SDK Core Libraries                   ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Uninstalling: gcloud cli dependencies                    ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: Cloud SDK Core Libraries                     ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: gcloud cli dependencies                      ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Creating backup and activating new installation          ═╣
╚════════════════════════════════════════════════════════════╝

Performing post processing steps...done.

Update done!

To revert your SDK to the previously installed version, you may run:
  $ gcloud components update --version 317.0.0

Authentifizieren Sie sich als Nächstes mit gcloud auth login für gcloud-Befehle, die Sie in Zukunft ausgeben:

$ gcloud auth login
Your browser has been opened to visit:

    https://accounts.google.com/o/oauth2/auth?response_type=code&client_id= . . .

You are now logged in as [YOUR_EMAIL].
Your current project is [PROJECT_ID].  You can change this setting by running:
  $ gcloud config set project PROJECT_ID

Mit gcloud config list können Sie sich Ihre aktuellen Projekteinstellungen ansehen:

$ gcloud config list
[core]
account = YOUR_EMAIL
disable_usage_reporting = False
project = PROJECT_ID

Your active configuration is: [default]

Mit dem Befehl oben können Sie entweder ein neues Projekt erstellen oder ein vorhandenes auswählen. Wenn die Ausgabe von gcloud config list nicht mit dem ausgewählten Projekt übereinstimmt, das Sie für diese Anleitung verwenden möchten, führen Sie gcloud config set project PROJECT_ID aus, um die Projekt-ID festzulegen. Prüfen Sie dann mit gcloud config list, ob die richtige Projekt-ID festgelegt ist.

$ gcloud config set project PROJECT_ID
Updated property [core/project].

Wenn Sie lieber die Cloud Console verwenden möchten, können Sie der Benutzeroberfläche folgen, um ein neues Projekt zu erstellen oder ein vorhandenes Projekt zu verwenden. Auf dem Dashboard Ihres Projekts sollte die Karte „Projektinformationen“ mit der ID des Projekts (sowie dem Projektnamen und der Projektnummer) angezeigt werden:

Grafik: Projekt-Infokarte

Mit dem letzten Befehl (#5), gcloud app deploy, wird Ihre App in App Engine bereitgestellt. Da wir gerade erst anfangen, ist die Ausführung jetzt optional. Wir raten jedoch dazu, den Code aus Modul 0 bereitzustellen, um zu bestätigen, dass er funktioniert. Wählen Sie bei der Ausführung die geografische Region aus, in der die App ausgeführt werden soll (in der Regel Ihr Standort). Sie kann jedoch nicht mehr geändert werden, sobald sie festgelegt wurde. Sehen Sie sich dann die restlichen Bereitstellungsinformationen an. Wenn der Vorgang abgeschlossen ist, werden Sie über die URL benachrichtigt, unter der Ihre App bereitgestellt wird. Hier ist eine gekürzte Version der Meldung, die angezeigt werden kann:

$ gcloud app deploy
Services to deploy:

descriptor:      [/private/tmp/mod0-baseline/app.yaml]
source:          [/private/tmp/mod0-baseline]
target project:  [PROJECT_ID]
target service:  [default]
target version:  [20201116t220827]
target url:      [https://PROJECT_ID.REG_ABBR.r.appspot.com]


Do you want to continue (Y/n)?

Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 1 file to Google Cloud Storage                 ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.
Setting traffic split for service [default]...done.
Deployed service [default] to [https://PROJECT_ID.REG_ABBR.r.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

Wenn Sie App Engine schon länger nicht mehr verwendet haben, werden Sie vielleicht feststellen, dass der ursprüngliche Bereitstellungsbefehl appcfg.py update durch gcloud app deploy ersetzt wurde. Weitere Informationen zu gcloud app deploy finden Sie auf der Dokumentationsseite.

Eine weitere kürzlich erfolgte Änderung betrifft die URL der bereitgestellten Apps, die von http://PROJECT_ID.appspot.com in http://PROJECT_ID.REG_ABBR.r.appspot.com geändert wurde. Die meisten Apps werden schließlich in das neue Format konvertiert. Weitere Informationen zum URL-Format finden Sie in der Dokumentation zu Anfragen und Routing.

Nachdem die App bereitgestellt wurde, aktualisieren Sie den Browser (möglicherweise mehrmals), um die letzten Besuche zu sehen:

visitme app

Wenn Ihre App neu ist, sehen Sie nur einen oder wenige Besuche.

4. Flask-Drittanbieterbibliothek hinzufügen

Die Python 2-App Engine-Laufzeit bietet eine Reihe von integrierten Bibliotheken von Drittanbietern, die Sie nur in Ihrer app.yaml-Datei angeben müssen, um sie zu verwenden. Für diese Migration sind sie nicht erforderlich, aber im nächsten Migrations-Tutorial (für Modul 2) werden sie verwendet.

Drittanbieterbibliotheken, die nicht integriert sind, müssen in einer Datei namens requirements.txt angegeben und lokal im Ordner lib im selben Verzeichnis wie der Anwendungscode installiert werden, in dem alles in App Engine hochgeladen wird. Weitere Informationen finden Sie in der Dokumentation zum Bündeln von Drittanbieterbibliotheken.

Bei kopierten Bibliotheken wie Flask müssen Sie App Engine mithilfe der Konfigurationsdatei appengine_config.py anweisen, im Ordner lib nach ihnen zu suchen. Die Konfigurationsdatei appengine_config.py befindet sich im selben Anwendungsordner der obersten Ebene wie requirements.txt und lib. In diesem Teil der Anleitung werden Sie:

  • Erstelle requirements.txt (gib kopierte [nicht integrierte] Drittanbieterbibliotheken an).
  • appengine_config.py erstellen (Drittanbieterbibliotheken erkennen)
  • Pakete und Abhängigkeiten von Drittanbietern installieren

1. requirements.txt erstellen

Erstellen Sie eine requirements.txt-Datei, um Ihre Pakete anzugeben. In unserem Fall ist Flask die erforderliche Drittanbieterbibliothek. Zum Zeitpunkt der Erstellung dieses Artikels ist die aktuelle Version 1.1.2. Erstellen Sie requirements.txt mit dieser Zeile:

Flask==1.1.2

Weitere Informationen zu akzeptierten Formaten finden Sie in der requirements.txt-Dokumentation.

2. appengine_config.py erstellen

Im nächsten Schritt muss App Engine externe Drittanbieterbibliotheken erkennen. Erstellen Sie eine Datei mit dem Namen appengine_config.py und mit folgendem Inhalt:

from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)

Dieser Code bewirkt genau das, was wir zuvor angegeben haben, nämlich dass App Engine auf den Ordner lib für kopierte Bibliotheken verweist.

3. Pakete und Abhängigkeiten installieren

Führen Sie jetzt den Befehl pip install aus, um den Ordner lib zu erstellen und Flask und seine Abhängigkeiten dort zu installieren:

$ pip install -t lib -r requirements.txt

Unabhängig davon, ob Sie pip oder pip2 verwendet haben, sollte nach Abschluss der Paketinstallation ein lib-Ordner mit einem Inhalt wie dem folgenden vorhanden sein:

$ ls lib
bin/
click/
click-7.1.2.dist-info/
flask/
Flask-1.1.2.dist-info/
itsdangerous/
itsdangerous-1.1.0.dist-info/
jinja2/
Jinja2-2.11.2.dist-info/
markupsafe/
MarkupSafe-1.1.1.dist-info/
werkzeug/
Werkzeug-1.0.1.dist-info/

5. Anwendungsdateien aktualisieren

Aktualisieren wir nun die Anwendungsdatei main.py.

1. Importe

Die Importe erfolgen wie in allen Python-Dateien zuerst. Auf den Import des webapp2-Frameworks folgt die ndb-Datastore-Bibliothek und schließlich die App Engine-Erweiterung, die Django-Vorlagen verarbeitet. Sie sollten Folgendes sehen:

  • VORHER:
import webapp2
from google.appengine.ext import ndb
from google.appengine.ext.webapp import template

Wenn Sie zu Flask wechseln, importieren Sie sowohl Flask als auch die Vorlagen-Renderer gleichzeitig. Löschen Sie die beiden webapp2-bezogenen Importe und ersetzen Sie sie wie folgt (lassen Sie den ndb-Import unverändert):

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

2. Starten

Für Apps, die webapp2 verwenden, ist ein einzelnes Array (Python-Liste) erforderlich, in dem alle Routen und Handler in einer beliebigen Python-Datei aufgeführt sind (es können auch andere vorhanden sein):

  • VORHER:
app = webapp2.WSGIApplication([
    ('/', MainHandler),
], debug=True)

app.yaml führt Routing auf höherer Ebene aus und ruft möglicherweise verschiedene Handler auf. Die Beispielanwendung ist so einfach, dass alle Routen zum main.py-Handler führen.

Flask verwendet keine solchen Routingtabellen. Löschen Sie daher diese Zeilen in main.py. Flask muss auch initialisiert werden. Fügen Sie daher die folgende Zeile oben in main.py direkt unter den Importen ein:

  • DANACH:
app = Flask(__name__)

In Flask initialisieren Sie das Framework und verwenden dann Dekoratoren, um die Routen zu definieren. Außerdem werden Routen mit Funktionen und nicht mit Klassen oder Methoden verknüpft.

Ein Flask-Tutorial ist in diesem Codelab nicht vorgesehen. Nehmen Sie sich daher etwas Zeit, um das Flask-Tutorial durchzuarbeiten und die Flask-Dokumentation zu lesen, um sich mit dem Framework vertraut zu machen.

3. Datenmodell

Hier gibt es keine Änderungen. Im nächsten Codelab geht es um Datastore.

4. Handler

Die Anwendung führt unabhängig davon, welches Framework Sie verwenden (webapp2 oder Flask), drei Aktionen aus:

  1. GET-Anfragen für den Root-Pfad (/) verarbeiten
  2. Registrieren eines Websitebesuchs (Visit-Objekt erstellen/speichern)
  3. Die zehn letzten Besuche mit einer vordefinierten Vorlage (index.html) anzeigen

Das webapp2-Framework verwendet ein klassenbasiertes Ausführungsmodell, bei dem Handler für jede unterstützte HTTP-Methode erstellt werden. In unserem einfachen Fall haben wir nur GET. Daher wird eine get()-Methode definiert:

  • VORHER:
class MainHandler(webapp2.RequestHandler):
    def get(self):
        store_visit(self.request.remote_addr, self.request.user_agent)
        visits = fetch_visits(10) or ()  # empty sequence if None
        tmpl = os.path.join(os.path.dirname(__file__), 'index.html')
        self.response.out.write(template.render(tmpl, {'visits': visits}))

Wie oben erwähnt, führt Flask ein eigenes Routing durch. Anstelle einer Handler-Klasse schreiben Sie Funktionen und versehen sie mit dem Pfad, für den sie aufgerufen werden sollen. Nutzer können HTTP-Methoden angeben, die im Decorator-Aufruf verarbeitet werden, z.B. @app.route('/app/', methods=['GET', 'POST']). Da der Standardwert nur GET (und implizit HEAD) ist, kann er weggelassen werden.

Ersetzen Sie beim Migrieren zu Flask die Klasse MainHandler und ihre Methode get() durch die folgende Flask-Routingfunktion:

  • DANACH:
@app.route('/')
def root():
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10) or ()  # empty sequence if None
    return render_template('index.html', visits=visits)

Das ist natürlich nicht repräsentativ für Ihre App, die sicherlich komplexer sein wird als dieses Beispiel. Ein Hauptziel dieser Anleitungen ist es, Ihnen den Einstieg zu erleichtern, Ihnen zu helfen, sich mit den Grundlagen vertraut zu machen, und Ihnen zu zeigen, wo Sie Änderungen im App Engine-spezifischen Code vornehmen müssen. Vergleichen Sie Ihre Änderungen mit Modul 1 main.py, um zu prüfen, ob Sie die Änderungen richtig vorgenommen haben.

5. Zusätzliche Dateien

An der Datei .gcloudignore wurden keine Änderungen vorgenommen. Damit werden Dateien angegeben, die nicht in App Engine bereitgestellt werden sollen, da sie für die Bereitstellung und Ausführung der Anwendung nicht erforderlich sind. Dazu gehören unter anderem Hilfsdateien für Python, Dateien für die Quellcodeverwaltung, Repository-Boilerplate und andere Dateien. Unsere .gcloudignore sieht so aus (Kommentare wurden aus Gründen der Übersichtlichkeit entfernt):

.gcloudignore
.git
.gitignore
.hgignore
.hg/
*.pyc
*.pyo
__pycache__/
/setup.cfg
README.md

6. HTML-Vorlagendatei aktualisieren

1. Vorlagendatei verschieben

Im Baseline-Repository-Ordner (Modul 0) befindet sich die index.html-Vorlagendatei im selben Ordner wie die Anwendungsdateien. Da für Flask HTML-Dateien in einem Ordner templates erforderlich sind, müssen Sie diesen Ordner (mkdir templates) erstellen und index.html dorthin verschieben. In einem POSIX-kompatiblen System wie Linux oder Mac OS X lauten die Befehle so:

mkdir templates
mv index.html templates

2. Vorlagendatei aktualisieren

Nachdem Sie index.html in templates verschoben haben, müssen Sie eine kleine, aber erforderliche Änderung vornehmen. Sehen wir uns die ursprüngliche Vorlagendatei im Ganzen an:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

</body>
</html>

Während webapp2 Django-Vorlagen verwendet, in denen Callables wie visit.timestamp.ctime ohne Klammern ( ) ausgeführt werden, sind sie in Jinja2 explizit erforderlich. Das mag wie eine kleine Änderung klingen, aber Jinja-Vorlagen sind von Haus aus leistungsfähiger, weil Sie Argumente in Aufrufen übergeben können.

In Django müssen Sie entweder ein „Template-Tag“ erstellen oder einen Filter schreiben. Aktualisieren Sie index.html, indem Sie dem visit.timestamp.ctime-Aufruf ein Paar Klammern hinzufügen:

  • VORHER:
<li>{{ visit.timestamp.ctime }} from {{ visit.visitor }}</li>
  • DANACH:
<li>{{ visit.timestamp.ctime() }} from {{ visit.visitor }}</li>

Das ist die einzige erforderliche Änderung. Für alle verbleibenden Migrations-Codelabs sind keine zusätzlichen Änderungen an index.html erforderlich.

7. Zusammenfassung/Bereinigung

Anwendung bereitstellen

Wenn Sie alle Änderungen in dieser Anleitung vorgenommen haben, sollten die Dateien in Ihrem Anwendungsordner mit den Dateien im Repo-Ordner für Modul 1 identisch oder nahezu identisch sein. Stellen Sie die Anwendung jetzt bereit und prüfen Sie, ob sie sich genauso verhält wie die webapp2-Version aus Modul 0.

Verwenden Sie den Befehl gcloud app deploy wie zuvor beim Bereitstellen des ursprünglichen Modul 0-Codes. Greifen Sie über einen Webbrowser oder einen curl- oder wget-Befehl auf die App unter PROJECT_ID.appspot.com zu, um zu bestätigen, dass sie wie erwartet funktioniert.

Wenn Sie einen Serverfehler erhalten, liegt das in der Regel an einem Tippfehler in Ihrem Python-Code. Sehen Sie sich Ihre Anwendungslogs an, um das Problem zu untersuchen. Vergleichen Sie Ihre Dateien auch mit denen im Repo für Modul 1 (Link oben).

Optional: Bereinigen

Was ist mit der Bereinigung, um Gebühren zu vermeiden, bis Sie bereit sind, mit dem nächsten Migrations-Codelab fortzufahren? Als bestehende Entwickler sind Sie wahrscheinlich bereits mit den Preisinformationen für App Engine vertraut.

Optional: App deaktivieren

Wenn Sie noch nicht mit dem nächsten Tutorial fortfahren möchten, deaktivieren Sie Ihre App, um Kosten zu vermeiden. Wenn Sie mit dem nächsten Codelab fortfahren möchten, können Sie es wieder aktivieren. Wenn Ihre App deaktiviert ist, fallen keine Gebühren für Traffic an. Allerdings können Ihnen Gebühren für die Datastore-Nutzung in Rechnung gestellt werden, wenn diese das kostenlose Kontingent überschreitet. Löschen Sie daher genügend Daten, um unter diesem Limit zu bleiben.

Wenn Sie die Migrationen nicht fortsetzen und alles vollständig löschen möchten, können Sie Ihr Projekt beenden.

Nächste Schritte

Es gibt zwei Migrationsmodule, die mit dem Code aus Modul 1 beginnen: Modul 2 und Modul 7:

  • Modul 2 (erforderlich, wenn Sie Datastore verwenden)
    • Von App Engine ndb zu Cloud NDB migrieren
    • Nach dem Wechsel zu Cloud NDB stehen viele weitere Optionen zur Verfügung.
      • Anwendung für die Ausführung in Cloud Run containerisieren
      • Weitere Migration Ihrer App zur Cloud Datastore-Clientbibliothek
      • App zu Cloud Firestore migrieren, um auf Firebase-Funktionen zuzugreifen
  • Modul 7 (erforderlich, wenn Sie [Push-]Aufgabenwarteschlangen verwenden)
    • App Engine (Push) taskqueue-Nutzung hinzufügen
    • Bereitet die App aus Modul 1 für die Migration zu Cloud Tasks in Modul 8 vor.

8. Zusätzliche Ressourcen

Probleme/Feedback zu Codelabs für das App Engine-Migrationsmodul

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 0 (START) und Modul 1 (FINISH) finden Sie in der Tabelle unten. Sie können auch über das Repository für alle App Engine-Migrationen auf sie zugreifen. Sie können es klonen oder eine ZIP-Datei herunterladen.

Codelab

Python 2

Python 3

Modul 0

code

(n/a)

Modul 1

code

(n/a)

App Engine-Ressourcen

Unten finden Sie zusätzliche Ressourcen zu dieser speziellen Migration: