Modul 1: Von App Engine webapp2 zu Flask migrieren

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.

Diese erste Anleitung zeigt die ersten Migrationsschritte zur Modernisierung des Web-Frameworks in App Engine-Anwendungen: der Wechsel von webapp2 zu Flask. In Ihrer Anwendung können Sie ein beliebiges Web-Framework verwenden, das das Routing verarbeitet. Für diese Anleitung verwenden wir jedoch Flask, da es in der Community weit verbreitet ist.

Du lernst, wie du

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

Voraussetzungen

Umfrage

Wie möchten Sie dieses Codelab nutzen?

<ph type="x-smartling-placeholder"></ph> Lesen Sie sie nur durch. Lies sie dir durch und absolviere die Übungen

2. Hintergrund

Das webapp-Framework wurde beim ersten Markteinführung von App Engine unter Python 2.5 im Jahr 2008 gebündelt. Jahre später wurde es durch den Nachfolger webapp2 ersetzt, als 2013 die Laufzeit 2.7 mit 2.5 eingestellt wurde.

webapp2 (siehe Dokumentation) ist zwar weiterhin vorhanden und kann außerhalb von App Engine als WSGI-kompatibles Web-Framework verwendet werden, führt jedoch keine eigene Weiterleitung von Nutzeranfragen an den entsprechenden Code in der Anwendung durch. Stattdessen werden die Web-Traffic-Weiterleitung an die entsprechenden "Handler" von App Engine, Konfigurationsdateien und dem Entwickler durchgeführt. Darüber hinaus sind die Hauptvorteile von webapp2 untrennbar mit den gebündelten Diensten von App Engine verknüpft, sodass sie eingestellt wird, obwohl sie unter Python 3 funktioniert (siehe auch verwandtes Problem).

Dieses Modul vermittelt praktische Erfahrungen mit der Migration einer einfachen webapp2-Anwendung zu Flask, einem von App Engine und vielen weiteren Diensten außerhalb von Google Cloud unterstützten Framework. Dadurch werden Anwendungen wesentlich portabler. Wenn Flask nicht das gewünschte Framework ist, in das Ihre Anwendung verschoben werden soll, können Sie ein anderes auswählen, solange es ein eigenes Routing durchführt. Dieses Codelab zeigt Entscheidungsträgern der Informationstechnologie (ITDMs) und Entwickler die Migrationsschritte, damit Sie sich mit diesem Prozess vertraut machen können – unabhängig davon, zu welchem Framework Sie migrieren.

Dies sind die wichtigsten Schritte für diese Migration:

  1. Einrichtung/Vorarbeit
  2. Flask-Drittanbieter-Bibliothek hinzufügen
  3. Anwendungsdateien aktualisieren
  4. HTML-Vorlagendatei aktualisieren

3. Einrichtung/Vorarbeit

Bevor wir mit dem Hauptteil des Tutorials fortfahren, richten wir unser Projekt ein, rufen den Code ab, machen sich dann (noch einmal) mit dem Befehl gcloud vertraut und stellen die Referenz-App bereit, damit wir mit dem funktionierenden Code beginnen.

1. Projekt einrichten

Als bestehender Entwickler zeigt Ihr App Engine-Dashboard wahrscheinlich bereits an, welche Dienste Sie ausführen. Für diese Anleitung empfehlen wir, ein neues Projekt zu erstellen oder ein vorhandenes für diese Anleitung wiederzuverwenden. Achten Sie darauf, dass das Projekt ein aktives Rechnungskonto hat und die App Engine (App) aktiviert ist.

2. Baseline-Beispiel-App herunterladen

Das GAE-Migrations-Repository enthält den gesamten Code, den Sie benötigen. Klonen Sie den Client oder laden Sie die zugehörige ZIP-Datei herunter. Für diese Anleitung beginnen Sie mit dem Code im Ordner für Modul 0 (START). Wenn Sie die Anleitung abgeschlossen haben, sollte Ihr Code mit dem Ordner für Modul 1 (FINISH) übereinstimmen. Falls nicht, sehen Sie sich die Unterschiede an, damit Sie mit dem nächsten Lab fortfahren.

Der Ordner „Modul 0“ sollte Dateien enthalten, die so aussehen, wie mit dem POSIX-Befehl ls veranschaulicht:

$ ls
app.yaml        index.html      main.py

3. (Wieder) Sich mit den gcloud-Befehlen vertraut machen

Wenn der Befehl gcloud noch nicht auf Ihrem Computer vorhanden ist, installieren Sie das Google Cloud SDK und achten Sie darauf, dass gcloud als Teil Ihres Ausführungspfads verfügbar ist. Machen Sie sich außerdem 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 keine App Engine-Entwicklung mit gcloud durchgeführt haben, sollten Sie zur Einrichtung die ersten vier Befehle (Nr. 1–4) ausführen, bevor Sie mit den nächsten Schritten fortfahren. Sehen wir uns diese Befehle kurz an.

Erstens sorgt gcloud components update dafür, dass Sie die neueste Cloud SDK-Version haben. Die Ausgabe dieses Befehls sollte in etwa so aussehen:

$ 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

Verwenden Sie als Nächstes gcloud auth login, um sich für gcloud-Befehle zu authentifizieren, die Sie im weiteren Verlauf ausführen werden:

$ 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

Verwenden Sie gcloud config list, um Ihre aktuellen Projekteinstellungen zu sehen:

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

Your active configuration is: [default]

Der obige Befehl soll Sie dabei unterstützen, ein neues Projekt zu erstellen oder ein vorhandenes auszuwä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, ob die richtige Projekt-ID festgelegt ist, indem Sie gcloud config list noch einmal ausführen.

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

Wenn Sie stattdessen die Cloud Console verwenden möchten, können Sie der Benutzeroberfläche folgen, um bei Bedarf ein neues Projekt zu erstellen, oder ein bereits vorhandenes Projekt verwenden. Im Dashboard Ihres Projekts sollten Sie die Projekt-Infokarte mit der zugehörigen ID (zusammen mit dem Projektnamen und der Projektnummer) sehen:

Grafik: Projekt-Infokarte

Mit dem letzten Befehl (#5), gcloud app deploy, stellen Sie die Anwendung in App Engine bereit. Da wir gerade erst damit beginnen, ist die Ausführung jetzt optional. Wir raten jedoch auf jeden Fall nicht davon ab, den Code für 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). Er kann jedoch nicht mehr geändert werden, sobald er einmal festgelegt wurde. Beobachten Sie dann den Rest der Bereitstellungsinformationen. Anschließend werden Sie über die URL benachrichtigt, unter der Ihre App bereitgestellt wird. Hier ist eine gekürzte Version dessen, was angezeigt werden könnte:

$ 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 längere Zeit nicht verwendet haben, stellen Sie möglicherweise fest, dass der ursprüngliche appcfg.py update-Bereitstellungsbefehl durch gcloud app deploy ersetzt wurde. Weitere Informationen zu gcloud app deploy finden Sie auf der Dokumentationsseite.

Eine weitere kürzliche Änderung betrifft die URL, geändert von http://PROJECT_ID.appspot.com bis http://PROJECT_ID.REG_ABBR.r.appspot.com. Die meisten Apps werden nach einer gewissen Zeit in das neue Format konvertiert. Weitere Informationen zum URL-Format finden Sie in der Dokumentation zu Anfragen und Weiterleitungen.

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

Besuche App

Wenn deine App neu ist, siehst du nur einen oder wenige Besuche.

4. Flask-Drittanbieter-Bibliothek hinzufügen

Die Python 2-Laufzeit von App Engine bietet eine Reihe integrierter Drittanbieterbibliotheken. Sie müssen diese lediglich in der app.yaml-Datei angeben, die verwendet werden soll. Diese Migration erfordert zwar keine Verwendung, wird aber in der nächsten Migrationsanleitung (für Modul 2) behandelt.

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

Für kopierte Bibliotheken wie Flask müssen Sie App Engine anweisen, im Ordner lib mithilfe der Konfigurationsdatei appengine_config.py 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:

  • requirements.txt erstellen (kopierte [nicht integrierte] Drittanbieterbibliotheken angeben)
  • appengine_config.py erstellen (Bibliotheken von Drittanbietern 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 Bibliothek des Drittanbieters, die benötigt wird. Zum Zeitpunkt der Veröffentlichung dieses Dokuments ist die neueste Version 1.1.2. Erstellen Sie daher requirements.txt mit dieser Zeile:

Flask==1.1.2

Weitere Informationen zu zulässigen Formaten finden Sie in der requirements.txt-Dokumentation.

2. appengine_config.py erstellen

Im nächsten Schritt muss App Engine externe Bibliotheken von Drittanbietern erkennen lassen. 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 tut genau das, was wir zuvor angegeben haben, d. h., App Engine wird auf den Ordner lib für kopierte Bibliotheken verwiesen.

3. Pakete und Abhängigkeiten installieren

Führen Sie nun 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 ähnlichen Inhalt wie diesem 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

Als Nächstes aktualisieren wir die Anwendungsdatei main.py.

1. Importe

Die Importe stehen wie in allen Python-Dateien an erster Stelle. Auf den Framework-Import für webapp2 folgen die Datastore-Bibliothek ndb und schließlich die App Engine-Erweiterung, die Django-basierte Vorlagen verarbeitet. Sie sollten Folgendes sehen:

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

Beim Wechsel zu Flask importieren Sie sowohl die Teile von Flask als auch die Teile des Vorlagen-Renderers gleichzeitig. Löschen Sie das Paar webapp2-bezogener Importe und ersetzen Sie sie so. Belassen Sie den ndb-Import unverändert:

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

2. Starten

Für Anwendungen, die webapp2 verwenden, ist ein einzelnes Array (Python-Liste) erforderlich, in dem alle Routen und Handler in jeder Python-Datei aufgelistet sind (es können weitere sein):

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

Beachten Sie, dass app.yaml ein übergeordnetes Routing durchführt und verschiedene Handler aufrufen kann. Die Beispiel-App ist so einfach, dass alle Routen zum main.py-Handler kommen.

Flask verwendet keine Routingtabellen wie diese. Löschen Sie diese Zeilen daher in main.py. Flask erfordert ebenfalls eine Initialisierung. Fügen Sie deshalb die folgende Zeile oben in main.py direkt unter den Importen ein:

  • NACHHER:
app = Flask(__name__)

In Flask initialisieren Sie das Framework und verwenden dann Decorators, um die Routen zu definieren. Außerdem sind Routen mit Funktionen gekoppelt, nicht mit Klassen oder Methoden.

Es ist nicht im Projektumfang enthalten, in dieses Codelab ein Flask-Tutorial aufzunehmen. Nehmen Sie sich daher etwas Zeit, um die Flask-Anleitung durchzugehen 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 vom verwendeten Framework (webapp2 oder Flask) drei Dinge aus:

  1. GET-Anfragen für den Stammpfad (/) verarbeiten
  2. „Besuchen“ einer Webseite registrieren (Visit-Objekt erstellen/speichern)
  3. Die 10 letzten Besuche mit den meisten Besuchen anzeigen (mit einer vordefinierten Vorlage, index.html)

Das Framework webapp2 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, sodass eine get()-Methode definiert ist:

  • 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 sein eigenes Routing durch. Anstelle einer Handler-Klasse schreiben Sie Funktionen und dekorieren sie mit der Route, für die 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 bei der Migration zu Flask die MainHandler-Klasse und ihre get()-Methode durch die folgende Flask-Routingfunktion:

  • NACHHER:
@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)

Natürlich ist dies nicht repräsentativ für Ihre App, was sicherlich komplexer sein wird als dieses Beispiel. Ein wichtiges Ziel dieser Tutorials ist es, Ihnen den Einstieg zu erleichtern, und verstehen, wo Änderungen im App Engine-spezifischen Code vorgenommen werden können. Um zu prüfen, ob Sie diese Änderung richtig vorgenommen haben, vergleichen Sie sie mit den Angaben in Modul 1 main.py.

5. Zusatzdateien

An der Datei .gcloudignore wurden keine Änderungen vorgenommen. Damit werden Dateien angegeben, die nicht in App Engine bereitgestellt werden sollen und die für die Bereitstellung und Ausführung der Anwendung nicht erforderlich sind. Dazu gehören unter anderem Hilfsdateien für Python, Versionsverwaltung, Repository-Boilerplate und andere Dateien. .gcloudignore sieht so aus (mit entfernten Kommentaren der Einfachheit halber):

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

6. HTML-Vorlagendatei aktualisieren

1. Vorlagendatei verschieben

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

mkdir templates
mv index.html templates

2. Vorlagendatei aktualisieren

Nachdem Sie index.html in templates verschoben haben, ist es an der Zeit, eine kleine, aber erforderliche Änderung vorzunehmen. Sehen wir uns die gesamte Vorlagendatei 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, die Callables wie visit.timestamp.ctime ohne Klammern ( ) ausführen, verlangt Jinja2 diese explizit. Das klingt zwar nach einer kleinen Optimierung, doch Jinja-Vorlagen sind sofort einsatzbereit, da Sie Argumente in Aufrufen übergeben können.

In Django müssen Sie entweder ein "Vorlagen-Tag" erstellen. oder einen Filter schreiben. Aktualisieren Sie daher index.html, indem Sie dem visit.timestamp.ctime-Aufruf ein Klammernpaar hinzufügen:

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

Dies ist die einzige erforderliche Änderung: Für alle verbleibenden Migrations-Codelabs sind keine weiteren Änderungen an index.html erforderlich.

7. Zusammenfassung/Bereinigung

Anwendung bereitstellen

Wenn Sie alle Änderungen in dieser Anleitung abgeschlossen haben, sollten die Dateien in Ihrem Anwendungsordner mit den Dateien im Repository-Ordner des Moduls 1 identisch sein oder annähernd genau sein. Stellen Sie nun die Bereitstellung bereit und sehen Sie, dass Ihre Flask-Anwendung für Modul 1 identisch mit der webapp2-Version von Modul 0 ausgeführt wird.

Verwenden Sie den Befehl gcloud app deploy wie zuvor beim Bereitstellen des ursprünglichen Modul-0-Codes. Zugriff auf die Anwendung unter PROJECT_ID.appspot.com über einen Webbrowser oder einen curl- oder wget-Befehl, um zu prüfen, ob sie wie erwartet funktioniert.

Wenn ein Serverfehler auftritt, bedeutet dies in der Regel einen Tippfehler in Ihrem Python-Code. Werfen Sie einen Blick auf Ihre Anwendungsprotokolle, um dies herauszufinden. Vergleichen Sie Ihre Dateien auch mit denen im Repository für Modul 1 (Link oben).

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

Es gibt zwei Migrationsmodule, die mit dem abgeschlossenen Code für Modul 1, Module 2 und 7 beginnen:

  • 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
      • Anwendung weiter zur Cloud Datastore-Clientbibliothek migrieren
      • Anwendung zu Cloud Firestore migrieren, um auf Firebase-Funktionen zuzugreifen
  • Modul 7 (erforderlich, wenn Sie [push]-Aufgabenwarteschlangen verwenden)
    • taskqueue-Nutzung für App Engine (Push) hinzufügen
    • Die App in Modul 1 wird auf die Migration zu Cloud Tasks in Modul 8 vorbereitet.

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

Codelab

Python 2

Python 3

Modul 0

code

(nicht zutreffend)

Modul 1

code

(nicht zutreffend)

App Engine-Ressourcen

Nachfolgend finden Sie zusätzliche Ressourcen zu dieser Migration: