Von Push-Aufgaben der App Engine-Aufgabenwarteschlange zu Cloud Tasks migrieren (Modul 8)

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 breitere Palette von Cloud-Produkten einbinden und darauf zugreifen sowie einfacher auf neuere Sprachversionen upgraden können. Der Schwerpunkt dieser Reihe liegt anfangs auf die ersten Cloud-Nutzer, in erster Linie auf Entwicklern von App Engine (Standardumgebung). Sie ist aber umfassend genug, um auch andere serverlose Plattformen wie Cloud Functions und Cloud Run oder gegebenenfalls andere Plattformen einzubeziehen.

Zweck dieses Codelab ist es, App Engine-Entwicklern für Python 2 zu zeigen, wie sie von App Engine Task Queue (Push-Aufgaben) zu Cloud Tasks migrieren. Außerdem erfolgt eine implizite Migration von App Engine NDB zu Cloud NDB für den Datastore-Zugriff (hauptsächlich in Modul 2 behandelt).

Wir haben die Verwendung von Push-Aufgaben in Modul 7 hinzugefügt. In Modul 8 migrieren wir diese Nutzung zu Cloud Tasks und sind dann in Modul 9 mit Python 3 und Cloud Datastore fortzufahren. Diejenigen, die Aufgabenwarteschlangen für Pull-Aufgaben verwenden, migrieren zu Cloud Pub/Sub und sollten stattdessen auf die Module 18 bis 19 verweisen.

Sie werden lernen,

Voraussetzungen

Umfrage

Wie möchten Sie diese Anleitung nutzen?

<ph type="x-smartling-placeholder"></ph> Lesen Sie sie nur durch. 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

Die App Engine-Aufgabenwarteschlange unterstützt Push- und Pull-Aufgaben. Das Google Cloud-Team empfiehlt, von gebündelten Legacy-Diensten wie Task Queue zu anderen eigenständigen Cloud-Diensten oder entsprechenden Drittanbietern zu migrieren, um die Übertragbarkeit von Anwendungen zu verbessern.

Die Migration von Pull-Aufgaben wird in den Migrationsmodulen 18–19 behandelt, während sich die Module 7 bis 9 auf die Migration von Push-Aufgaben konzentrieren. Um von den Push-Aufgaben der App Engine-Aufgabenwarteschlange zu migrieren, haben wir deren Verwendung zu der vorhandenen Python 2 App Engine-Beispielanwendung hinzugefügt, die neue Seitenaufrufe registriert und die letzten Besuche anzeigt. Im Codelab für Modul 7 wird eine Push-Aufgabe hinzugefügt, mit der die ältesten Besuche gelöscht werden – sie werden nie wieder angezeigt. Warum sollten sie also zusätzlichen Speicherplatz in Datastore belegen? Dieses Codelab aus Modul 8 behält die gleiche Funktionalität bei, migriert jedoch den zugrunde liegenden Warteschlangenmechanismus von Push-Aufgaben der Aufgabenwarteschlange zu Cloud Tasks und wiederholt die Modul 2-Migration von App Engine NDB zu Cloud NDB für Datastore-Zugriff.

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
  4. Neue Google Cloud-Dienste/APIs aktivieren

Mit diesen Schritten stellen Sie sicher, dass Sie mit funktionierendem Code beginnen und Ihre Beispielanwendung bereit für die Migration zu Cloud-Diensten ist.

1. Projekt einrichten

Wenn Sie das Codelab für Modul 7 abgeschlossen haben, verwenden Sie dasselbe Projekt (und Code) wieder. Alternativ können Sie ein neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Achten Sie darauf, dass das Projekt ein aktives Rechnungskonto und eine aktivierte App Engine-Anwendung hat. Suchen Sie Ihre Projekt-ID, da Sie sie in diesem Codelab immer zur Hand haben sollten. Verwenden Sie sie immer dann, wenn Sie auf die Variable PROJECT_ID stoßen.

2. Baseline-Beispiel-App abrufen

Eine der Voraussetzungen ist eine funktionierende App Engine-App für Modul 7. Schließen Sie das Codelab für Modul 7 ab (empfohlen) oder kopieren Sie die App für Modul 7 aus dem Repository. Unabhängig davon, ob Sie Ihren oder unseren verwenden, beginnen wir mit dem Code für Modul 7 („START“). In diesem Codelab werden Sie Schritt für Schritt durch die Migration geführt. Abschließend erhalten Sie einen Code, der dem im Repository-Ordner von Modul 8 ("FINISH") ähnelt.

Unabhängig davon, welche Modul 7-App 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 und validieren

Führen Sie die folgenden Schritte aus, um die Modul 7-App 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 auf Ihrem Entwicklungscomputer sowohl Python 2 als auch Python 3 installiert sind, müssen Sie möglicherweise stattdessen pip2 verwenden.
  2. Prüfen Sie, ob das gcloud-Befehlszeilentool installiert und initialisiert und seine Nutzung geprüft wurde.
  3. (Optional) Legen Sie für Ihr Cloud-Projekt gcloud config set project PROJECT_ID fest, wenn Sie den PROJECT_ID nicht bei jedem gcloud-Befehl eingeben möchten.
  4. Beispielanwendung mit gcloud app deploy bereitstellen
  5. Prüfen Sie, ob die App wie erwartet funktioniert, ohne dass Probleme auftreten. Wenn Sie das Codelab für Modul 7 abgeschlossen haben, werden in der App die Top-Besucher zusammen mit den letzten Besuchen angezeigt (siehe siehe unten). Unten sind die älteren Aufgaben zu sehen, die gelöscht werden.

4aa8a2cb5f527079.png

4. Neue Google Cloud-Dienste/APIs aktivieren

In der alten Anwendung wurden gebündelte App Engine-Dienste verwendet, die keine zusätzliche Einrichtung erfordern. Eigenständige Cloud-Dienste hingegen schon. Die aktualisierte Anwendung verwendet sowohl Cloud Tasks als auch Cloud Datastore (über die Cloud NDB-Clientbibliothek). Bei einigen Cloud-Produkten ist das "Immer kostenlos"- Stufenkontingente, einschließlich App Engine, Cloud Datastore und Cloud Tasks. Solange Sie diese Beschränkungen nicht überschreiten, sollten Ihnen durch das Ausführen dieser Anleitung keine Kosten entstehen. Cloud APIs können je nach Bedarf entweder über die Cloud Console oder über die Befehlszeile aktiviert werden.

Über die Cloud Console

Rufen Sie in der Cloud Console die Seite API Manager-Bibliothek (für das richtige Projekt) auf und suchen Sie über die Suchleiste in der Mitte der Seite nach der Cloud Datastore API und der Cloud Tasks API:

c7a740304e9d35b.png

Klicken Sie für jede API einzeln auf die Schaltfläche Aktivieren. Dann werden Sie möglicherweise aufgefordert, Zahlungsinformationen anzugeben. In diesem Beispiel sehen Sie die Seite mit der Cloud Pub/Sub API-Bibliothek. Aktivieren Sie nicht die Pub/Sub API für dieses Codelab, sondern nur Cloud Tasks und Datastore:

1b6c0a2a73124f6b.jpeg

Über die Befehlszeile

Dies ist zwar visuell informativ, wenn APIs über die Konsole aktiviert werden, aber einige bevorzugen die Befehlszeile. Führen Sie den Befehl gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com aus, um beide APIs gleichzeitig zu aktivieren:

$ gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Möglicherweise werden Sie aufgefordert, Zahlungsinformationen einzugeben. Wenn Sie andere Cloud APIs aktivieren und deren „URIs“ wissen möchten befinden sich unten auf der Seite der API-Bibliothek. Achten Sie beispielsweise auf pubsub.googleapis.com als „Dienstname“ unten auf der Pub/Sub-Seite direkt darüber.

Nach Abschluss der Schritte kann Ihr Projekt auf die APIs zugreifen. Jetzt ist es an der Zeit, die App so zu aktualisieren, dass diese APIs verwendet werden.

4. Konfiguration aktualisieren

Konfigurationsaktualisierungen erfolgen explizit durch die zusätzliche Verwendung von Cloud-Clientbibliotheken. Unabhängig davon, welche Version Sie verwenden, müssen dieselben Änderungen an Anwendungen vorgenommen werden, die keine Cloud-Clientbibliotheken verwenden.

requirements.txt

In Modul 8 wird die Verwendung von App Engine NDB und Aufgabenwarteschlange aus Modul 1 mit Cloud NDB und Cloud Tasks ausgetauscht. Hängen Sie sowohl google-cloud-ndb als auch google-cloud-tasks an requirements.txt an, um flask aus Modul 7 zusammenzuführen:

flask
google-cloud-ndb
google-cloud-tasks

Diese requirements.txt-Datei enthält keine Versionsnummern. Es sind also die neuesten Versionen ausgewählt. Falls Inkompatibilitäten auftreten, geben Sie eine Versionsnummer an, um Arbeitsversionen für die App zu sperren.

app.yaml

Wenn Sie Cloud-Clientbibliotheken verwenden, sind für die Python 2-App Engine-Laufzeit bestimmte Drittanbieterpakete erforderlich, nämlich grpcio und setuptools. Python 2-Nutzer müssen integrierte Bibliotheken wie diese zusammen mit einer verfügbaren Version oder „latest“ in app.yaml auflisten. Wenn Sie noch keinen libraries-Abschnitt haben, erstellen Sie einen und fügen Sie beide Bibliotheken wie folgt hinzu:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

Wenn du deine App migrierst, hat sie möglicherweise bereits einen libraries-Abschnitt. Wenn dies der Fall ist und entweder grpcio oder setuptools fehlen, fügen Sie sie einfach dem vorhandenen libraries-Abschnitt hinzu. Die aktualisierte app.yaml sollte jetzt so aussehen:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

appengine_config.py

Der google.appengine.ext.vendor.add()-Aufruf in appengine_config.py verbindet Ihre kopierten (auch als „Anbieter“ oder „Selbstbündelung“ bezeichneten) Drittanbieterbibliotheken in lib mit Ihrer App. Oben in app.yaml haben wir integrierte Drittanbieterbibliotheken hinzugefügt. Diese benötigen setuptools.pkg_resources.working_set.add_entry(), um deine App mit diesen integrierten Paketen in lib zu verknüpfen. Hier sehen Sie das ursprüngliche Modul 1 appengine_config.py und nachdem Sie die Änderungen an Modul 8 vorgenommen haben:

VORHER:

from google.appengine.ext import vendor

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

NACHHER:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

Eine ähnliche Beschreibung finden Sie auch in der Dokumentation zur App Engine-Migration.

5. Anwendungscode ändern

Dieser Abschnitt enthält Aktualisierungen der Hauptanwendungsdatei main.py, wodurch die Verwendung von Push-Warteschlangen der App Engine-Aufgabenwarteschlange durch Cloud Tasks ersetzt wird. An der Webvorlage „templates/index.html“ ändert sich nichts. Beide Apps sollten identisch funktionieren und die gleichen Daten anzeigen. Die Änderungen an der Hauptanwendung lassen sich in die folgenden vier Aufgaben unterteilen:

  1. Importe und Initialisierung aktualisieren
  2. Funktionalität des Datenmodells aktualisieren (Cloud NDB)
  3. Zu Cloud Tasks (und Cloud NDB) migrieren
  4. Push-Aufgaben-Handler aktualisieren

1. Importe und Initialisierung aktualisieren

  1. Ersetzen Sie App Engine NDB (google.appengine.ext.ndb) und Aufgabenwarteschlange (google.appengine.api.taskqueue) durch Cloud NDB (google.cloud.ndb) bzw. Cloud Tasks (google.cloud.tasks).
  2. Cloud-Clientbibliotheken erfordern die Initialisierung und Erstellung von API-Clients Weisen Sie sie ds_client bzw. ts_client zu.
  3. Die Dokumentation zur Aufgabenwarteschlange besagt: "App Engine stellt eine Standard-Push-Warteschlange mit dem Namen default bereit, die konfiguriert ist und mit den Standardeinstellungen verwendet werden kann." Cloud Tasks bietet keine default-Warteschlange, da es sich um ein eigenständiges Cloud-Produkt unabhängig von App Engine handelt. Daher ist neuer Code erforderlich, um eine Cloud Tasks-Warteschlange mit dem Namen default zu erstellen.
  4. Für die App Engine-Aufgabenwarteschlange müssen Sie keine Region angeben, da sie die Region verwendet, in der Ihre Anwendung ausgeführt wird. Da Cloud Tasks jetzt jedoch ein unabhängiges Produkt ist, ist eine Region erforderlich, die mit der Region übereinstimmen muss, in der Ihre Anwendung ausgeführt wird. Der Name der Region und die Cloud-Projekt-ID sind zum Erstellen eines „voll qualifizierten Pfadnamens“ erforderlich als eindeutige Kennung der Warteschlange ein.

Die im dritten und vierten Punkt beschriebenen Aktualisierungen machen den Großteil der zusätzlichen Konstanten und erforderlichen Initialisierungen aus. Im Vorher-Nachher-Vergleich und „nachher“ unten und nehmen Sie diese Änderungen oben in main.py vor.

VORHER:

from datetime import datetime
import logging
import time
from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb

app = Flask(__name__)

NACHHER:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)

2. Funktionalität des Datenmodells aktualisieren (Cloud NDB)

App Engine NDB und Cloud NDB funktionieren nahezu identisch. Weder am Datenmodell noch an der Funktion store_visit() wurden größere Änderungen vorgenommen. Der einzige auffällige Unterschied besteht darin, dass die Erstellung der Entität Visit in store_visit() jetzt in einem Python-with-Block gekapselt ist. Für Cloud NDB muss der gesamte Datenspeicherzugriff über den Kontextmanager gesteuert werden, daher die Anweisung with. Die folgenden Code-Snippets veranschaulichen diesen geringfügigen Unterschied bei der Migration zu Cloud NDB. Implementieren Sie diese Änderung.

VORHER:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

NACHHER:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

3. Zu Cloud Tasks (und Cloud NDB) migrieren

Durch die wichtigste Änderung bei dieser Migration wird die zugrunde liegende Warteschlangeninfrastruktur umgestellt. Dies erfolgt in der Funktion fetch_visits(), in der eine Push-Aufgabe zum Löschen alter Besuche erstellt und zur Ausführung in die Warteschlange eingereiht wird. Die ursprüngliche Funktionalität von Modul 7 bleibt jedoch erhalten:

  1. Abfrage der letzten Besuche.
  2. Anstatt diese Besuche sofort zurückzugeben, sollten Sie den Zeitstempel der letzten Visit (den ältesten angezeigten) speichern. Alle Besuche, die älter sind, können gelöscht werden.
  3. Machen Sie den Zeitstempel mit standardmäßigen Python-Dienstprogrammen als Gleitkommazahl und String bekannt und verwenden Sie beides für verschiedene Funktionen, z. B. für Anzeige für Nutzer, zu Protokollen hinzufügen, an Handler übergeben usw.
  4. Erstellen Sie eine Push-Aufgabe mit diesem Zeitstempel als Nutzlast und /trim als URL.
  5. Der Aufgaben-Handler wird schließlich über ein HTTP-POST zu dieser URL aufgerufen.

Dieser Workflow wird durch die „Vorher“- Code-Snippet hinzu:

VORHER:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    taskqueue.add(url='/trim', params={'oldest': oldest})
    return data, oldest_str

Die Funktionalität bleibt unverändert, Cloud Tasks wird jedoch zur Ausführungsplattform. Diese Änderung betrifft unter anderem folgende Änderungen:

  1. Visit-Abfrage in einen Python-with-Block umschließen (die Migration von Modul 2 zu Cloud NDB wird wiederholt)
  2. Erstellen Sie Cloud Tasks-Metadaten, einschließlich erwarteter Attribute wie Zeitstempelnutzlast und URL, fügen Sie aber auch den MIME-Typ hinzu und codieren Sie die Nutzlast in JSON.
  3. Verwenden Sie den Cloud Tasks API-Client, um die Aufgabe mit den Metadaten und dem vollständigen Pfadnamen der Warteschlange zu erstellen.

Diese Änderungen am fetch_visits() sind unten dargestellt:

NACHHER:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return data, oldest_str

4. Push-Aufgaben-Handler aktualisieren

Die Push-Aufgaben-Handler-Funktion erfordert keine größeren Aktualisierungen. nur ausgeführt werden muss. Dies gilt für Aufgabenwarteschlange oder Cloud Tasks. „Der Code ist der Code.“ Das heißt es. Es gibt jedoch einige kleinere Änderungen:

  1. Die Zeitstempelnutzlast wurde wortgetreu an die Aufgabenwarteschlange übergeben, war jedoch für Cloud Tasks JSON-codiert und muss daher bei ihrem Aufruf in JSON geparst werden.
  2. Der HTTP-POST-Aufruf an /trim mit der Aufgabenwarteschlange hatte den impliziten MIME-Typ application/x-www-form-urlencoded, aber in Cloud Tasks wird er explizit als application/json festgelegt, sodass es eine etwas andere Möglichkeit gibt, die Nutzlast zu extrahieren.
  3. Verwenden Sie den Client Context Manager der Cloud NDB API (Migration von Modul 2 zu Cloud NDB).

Unten sehen Sie die Code-Snippets vor und nach diesen Änderungen am Aufgaben-Handler trim():

VORHER:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = request.form.get('oldest', type=float)
    keys = Visit.query(
            Visit.timestamp < datetime.fromtimestamp(oldest)
    ).fetch(keys_only=True)
    nkeys = len(keys)
    if nkeys:
        logging.info('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id()) for k in keys)))
        ndb.delete_multi(keys)
    else:
        logging.info('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

NACHHER:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Der Hauptanwendungs-Handler root() und die Webvorlage templates/index.html wurden nicht aktualisiert.

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

Anwendung mit gcloud app deploy bereitstellen Die Ausgabe sollte mit der App für Modul 7 identisch sein. Beachten Sie jedoch, dass Sie ein völlig anderes Push-Warteschlangen-Produkt verwendet haben, wodurch Ihre App portabler als zuvor ist.

4aa8a2cb5f527079.png

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:

  • Cloud Tasks bietet eine kostenlose Stufe. Weitere Informationen finden Sie auf der Preisseite.
  • 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

Damit ist unsere Migration von Push-Aufgaben der App Engine-Aufgabenwarteschlange zu Cloud Tasks abgeschlossen. Wenn Sie diese Anwendung weiterhin zu Python 3 portieren und noch weiter von Cloud NDB zu Cloud Datastore migrieren möchten, sollten Sie Modul 9 in Betracht ziehen.

Cloud NDB wurde speziell für Python 2-App Engine-Entwickler entwickelt und bietet eine nahezu identische Nutzererfahrung. Cloud Datastore verfügt jedoch über eine eigene native Clientbibliothek für Nutzer, die App Engine nicht verwenden oder für neue App Engine-Nutzer (Python 3). Da Cloud NDB jedoch für Python 2 und 3 verfügbar ist, ist keine Migration zu Cloud Datastore erforderlich.

Sowohl Cloud NDB als auch Cloud Datastore greifen beide auf Datastore zu (wenn auch auf unterschiedliche Weise). Der einzige Grund für einen Wechsel zu Cloud Datastore ist daher der einzige Grund, den Wechsel zu Cloud Datastore in Betracht zu ziehen, wenn Sie bereits andere Anwendungen haben, insbesondere nicht App Engine-Anwendungen, die Cloud Datastore verwenden und eine Standardisierung auf eine einzelne Datastore-Clientbibliothek wünschen. Diese optionale Migration von Cloud NDB zu Cloud Datastore wird in Modul 3 auch eigenständig (ohne Aufgabenwarteschlange oder Cloud Tasks) behandelt.

Neben den Modulen 3, 8 und 9 gibt es weitere Migrationsmodule, die sich auf den Wegfall der gebündelten Legacy-Dienste von App Engine konzentrieren:

  • Modul 2: Von App Engine NDB zu Cloud NDB migrieren
  • Module 12–13: Migration von App Engine Memcache zu Cloud Memorystore
  • Module 15–16: Migration von App Engine Blobstore zu Cloud Storage
  • Module 18–19: App Engine-Aufgabenwarteschlange (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.

Probleme/Feedback mit Codelabs

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 7 (START) und Modul 8 (FINISH) finden Sie in der folgenden Tabelle.

Codelab

Python 2

Python 3

Module 7

code

code (in dieser Anleitung nicht enthalten)

Modul 8 (dieses Codelab)

code

(nicht zutreffend)

Online-Ressourcen

Nachfolgend finden Sie Onlineressourcen, die für diese Anleitung relevant sein könnten:

App Engine-Aufgabenwarteschlange und Cloud Tasks

App Engine NDB und Cloud NDB (Datenspeicher)

App Engine-Plattform

Weitere Cloud-Informationen

Videos

Lizenz

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