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

1. Übersicht

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

In diesem Codelab wird Python 2-App Engine-Entwicklern gezeigt, wie sie von App Engine-Aufgabenwarteschlangen (Push-Aufgaben) zu Cloud Tasks migrieren können. Es gibt auch 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 und migrieren diese Verwendung hier in Modul 8 zu Cloud Tasks. In Modul 9 geht es dann mit Python 3 und Cloud Datastore weiter. Nutzer, die Aufgabenwarteschlangen für Pull-Aufgaben verwenden, migrieren zu Cloud Pub/Sub und sollten stattdessen die Module 18–19 lesen.

Lerninhalte

Voraussetzungen

Umfrage

Wie werden Sie diese Anleitung verwenden?

Nur lesen Lesen und Übungen durchführen

Wie würden Sie Ihre Erfahrung mit Python bewerten?

Anfänger Mittelstufe Fortgeschrittene

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

Anfänger Mittelstufe Fortgeschritten

2. Hintergrund

Die App Engine Task Queue unterstützt sowohl Push- als auch Pull-Aufgaben. Um die Portabilität von Anwendungen zu verbessern, empfiehlt das Google Cloud-Team, von gebündelten Legacy-Diensten wie Task Queue zu anderen eigenständigen Cloud- oder Drittanbieterdiensten zu migrieren.

Die Migration von Pull-Aufgaben wird in den Migrationsmodulen 18–19 behandelt, während sich die Module 7–9 auf die Migration von Push-Aufgaben konzentrieren. Um die Migration von App Engine Task Queue-Push-Aufgaben zu ermöglichen, haben wir die Verwendung in die vorhandene Python 2-App Engine-Beispielanwendung aufgenommen, die neue Seitenbesuche registriert und die letzten Besuche anzeigt. Im Codelab zu Modul 7 wird eine Push-Aufgabe hinzugefügt, um die ältesten Besuche zu löschen. Sie werden nie wieder angezeigt. Warum sollten sie also zusätzlichen Speicherplatz im Datastore belegen? In diesem Codelab zu Modul 8 wird dieselbe Funktionalität beibehalten, aber der zugrunde liegende Warteschlangenmechanismus wird von Push-Aufgaben in der Task Queue zu Cloud Tasks migriert. Außerdem wird die Migration aus Modul 2 von App Engine NDB zu Cloud NDB für den Datastore-Zugriff wiederholt.

Diese Anleitung umfasst die folgenden Schritte:

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

3. Einrichtung/Vorbereitung

In diesem Abschnitt wird Folgendes erläutert:

  1. Cloud-Projekt einrichten
  2. Beispiel-App für die Baseline abrufen
  3. Ausgangsanwendung (neu) bereitstellen und validieren
  4. Neue Google Cloud-Dienste/APIs aktivieren

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

1. Projekt einrichten

Wenn Sie das Codelab für Modul 7 abgeschlossen haben, können Sie dasselbe Projekt (und denselben Code) wiederverwenden. Alternativ können Sie ein neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Prüfen Sie, ob das Projekt ein aktives Abrechnungskonto und eine aktivierte App Engine-Anwendung hat. Suchen Sie die Projekt-ID, da Sie sie in diesem Codelab benötigen. Verwenden Sie sie immer, wenn Sie auf die Variable PROJECT_ID stoßen.

2. Beispiel-App für die Baseline abrufen

Eine der Voraussetzungen ist eine funktionierende App Engine-App aus Modul 7. Sie können entweder das Codelab zu Modul 7 durcharbeiten (empfohlen) oder die App aus Modul 7 aus dem Repository kopieren. Unabhängig davon, ob Sie Ihren oder unseren Code verwenden, beginnen wir mit dem Code aus Modul 7 („START“). In diesem Codelab wird die Migration beschrieben. Am Ende steht Code, der dem im Repo-Ordner für Modul 8 („FINISH“) ähnelt.

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

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

3. Ausgangsanwendung (neu) bereitstellen und validieren

Führen Sie die folgenden Schritte aus, um die App aus Modul 7 bereitzustellen:

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

4aa8a2cb5f527079.png

4. Neue Google Cloud-Dienste/APIs aktivieren

In der alten App wurden gebündelte App Engine-Dienste verwendet, für die keine zusätzliche Einrichtung erforderlich ist. Für eigenständige Cloud-Dienste ist jedoch eine Einrichtung erforderlich. In der aktualisierten App werden sowohl Cloud Tasks als auch Cloud Datastore (über die Cloud NDB-Clientbibliothek) verwendet. Eine Reihe von Cloud-Produkten haben Kontingente für die kostenlose Stufe, darunter App Engine, Cloud Datastore und Cloud Tasks. Solange Sie diese Limits nicht überschreiten, sollten für diese Anleitung keine Gebühren anfallen. Cloud-APIs können je nach Bedarf über die Cloud Console oder über die Befehlszeile aktiviert werden.

Über die Cloud Console

Rufen Sie in der Cloud Console die Bibliotheksseite des API-Managers für das richtige Projekt auf und suchen Sie in der Suchleiste in der Mitte der Seite nach den Cloud Datastore- und Cloud Tasks-APIs:

c7a740304e9d35b.png

Klicken Sie für jede API separat auf die Schaltfläche Aktivieren. Möglicherweise werden Sie aufgefordert, Zahlungsinformationen anzugeben. Hier finden Sie ein Beispiel für die Seite „Cloud Pub/Sub API Library“. Aktivieren Sie für dieses Codelab nicht die Pub/Sub API, sondern nur Cloud Tasks und Datastore:

1b6c0a2a73124f6b.jpeg

Über die Befehlszeile

Das Aktivieren von APIs über die Konsole ist zwar visuell informativ, aber einige Nutzer 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 anzugeben. Wenn Sie andere Cloud APIs aktivieren möchten und wissen möchten, welche „URIs“ sie haben, finden Sie diese unten auf der Bibliotheksseite der jeweiligen API. Beachten Sie beispielsweise pubsub.googleapis.com als „Dienstname“ unten auf der Pub/Sub-Seite oben.

Danach kann Ihr Projekt auf die APIs zugreifen. Jetzt ist es an der Zeit, die App zu aktualisieren, damit sie diese APIs verwendet.

4. Konfiguration aktualisieren

Die Änderungen in der Konfiguration sind explizit auf die zusätzliche Verwendung von Cloud-Clientbibliotheken zurückzuführen. Unabhängig davon, welche Sie verwenden, müssen dieselben Änderungen an Apps vorgenommen werden, die keine Cloud-Clientbibliotheken verwenden.

requirements.txt

In Modul 8 werden App Engine NDB und Task Queue aus Modul 1 durch Cloud NDB und Cloud Tasks ersetzt. Hängen Sie sowohl google-cloud-ndb als auch google-cloud-tasks an requirements.txt an, um flask aus Modul 7 zu verbinden:

flask
google-cloud-ndb
google-cloud-tasks

Diese requirements.txt-Datei enthält keine Versionsnummern. Daher sind die neuesten Versionen ausgewählt. Wenn Inkompatibilitäten auftreten, geben Sie eine Versionsnummer an, um funktionierende Versionen für die App festzulegen.

app.yaml

Bei Verwendung von Cloud-Clientbibliotheken 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 so hinzu:

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

Wenn Sie Ihre App migrieren, hat sie möglicherweise bereits einen libraries-Abschnitt. Wenn das der Fall ist und entweder grpcio oder setuptools fehlt, fügen Sie sie einfach dem vorhandenen libraries-Abschnitt hinzu. Das aktualisierte app.yaml sollte nun 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 (manchmal auch als „Vendoring“ 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 Ihre App mit diesen integrierten Paketen in lib zu verknüpfen. Unten sehen Sie das ursprüngliche Modul 1 appengine_config.py und das Modul nach den Änderungen in Modul 8:

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)

DANACH:

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 App Engine-Migrationsdokumentation.

5. Anwendungscode ändern

In diesem Abschnitt werden Aktualisierungen der Hauptanwendungsdatei main.py beschrieben, bei denen die Verwendung von App Engine Task Queue-Push-Warteschlangen durch Cloud Tasks ersetzt wird. Es gibt keine Änderungen an der Webvorlage templates/index.html. Beide Apps sollten identisch funktionieren und dieselben Daten anzeigen. Die Änderungen an der Hauptanwendung lassen sich in diese vier Aufgaben unterteilen:

  1. Importe und Initialisierung aktualisieren
  2. Funktionen des Datenmodells aktualisieren (Cloud NDB)
  3. Zu Cloud Tasks (und Cloud NDB) migrieren
  4. Aufgaben-Handler für Updates (Push)

1. Importe und Initialisierung aktualisieren

  1. Ersetzen Sie App Engine NDB (google.appengine.ext.ndb) und Task Queue (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. In der Dokumentation zu Aufgabenwarteschlangen heißt es: „App Engine stellt eine Standard-Push-Warteschlange mit dem Namen default zur Verfügung, die fertig konfiguriert und für die Verwendung mit Standardeinstellungen bereit ist.“ Cloud Tasks bietet keine default-Warteschlange, da es sich um ein eigenständiges Cloud-Produkt handelt, das unabhängig von App Engine ist. Daher ist neuer Code erforderlich, um eine Cloud Tasks-Warteschlange mit dem Namen default zu erstellen.
  4. Für App Engine Task Queue müssen Sie keine Region angeben, da die Region verwendet wird, in der Ihre App ausgeführt wird. Da Cloud Tasks jetzt jedoch ein unabhängiges Produkt ist, ist eine Region erforderlich. Diese Region muss mit der Region übereinstimmen, in der Ihre App ausgeführt wird. Der Regionsname und die Cloud-Projekt-ID sind erforderlich, um einen „vollständig qualifizierten Pfadnamen“ als eindeutige Kennung der Warteschlange zu erstellen.

Die oben im dritten und vierten Aufzählungspunkt beschriebenen Aktualisierungen machen den Großteil der zusätzlichen Konstanten und Initialisierung aus, die erforderlich sind. Sehen Sie sich die Beispiele unten an 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__)

DANACH:

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. Funktionen des Datenmodells aktualisieren (Cloud NDB)

App Engine NDB und Cloud NDB funktionieren fast identisch. Sowohl das Datenmodell als auch die store_visit()-Funktion haben sich nicht wesentlich geändert. Der einzige nennenswerte Unterschied besteht darin, dass die Erstellung der Visit-Entität in store_visit() jetzt in einem Python-with-Block gekapselt ist. Bei Cloud NDB muss der gesamte Datastore-Zugriff innerhalb des Kontextmanagers gesteuert werden. Daher ist die with-Anweisung erforderlich. 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()

DANACH:

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

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

  1. Nach den letzten Besuchen suchen.
  2. Anstatt diese Besuche sofort zurückzugeben, speichern Sie den Zeitstempel des letzten Visit, des ältesten angezeigten. Alle Besuche, die älter als dieser sind, können gefahrlos gelöscht werden.
  3. Extrahieren Sie den Zeitstempel als Gleitkommazahl und als String mit Standard-Python-Dienstprogrammen und verwenden Sie beide in verschiedenen Funktionen, z. B. zur Anzeige für den Nutzer, zum Hinzufügen zu Protokollen oder zum Übergeben an den Handler.
  4. Erstellen Sie eine Push-Aufgabe mit diesem Zeitstempel als Nutzlast und /trim als URL.
  5. Der Aufgaben-Handler wird schließlich über eine HTTP-POST-Anfrage an diese URL aufgerufen.

Dieser Workflow wird im Code-Snippet „Vorher“ veranschaulicht:

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. Die Änderungen, die für diese Umstellung erforderlich sind, umfassen:

  1. Visit-Abfrage in einen Python-with-Block einfügen (Migration aus Modul 2 zu Cloud NDB wiederholen)
  2. Erstellen Sie Cloud Tasks-Metadaten, einschließlich erwarteter Attribute wie Zeitstempel-Nutzlast und URL. Fügen Sie außerdem den MIME-Typ hinzu und JSON-codieren Sie die Nutzlast.
  3. Erstellen Sie den Task mit den Metadaten und dem vollständigen Pfadnamen der Warteschlange mit dem Cloud Tasks API-Client.

Diese Änderungen an fetch_visits() werden unten veranschaulicht:

DANACH:

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. Aufgaben-Handler für Updates (Push)

Die (Push-)Task-Handler-Funktion erfordert keine größeren Aktualisierungen, sondern nur die Ausführung. Dies gilt für Task Queue oder Cloud Tasks. „Der Code ist der Code“, sagen sie. Es gibt jedoch einige kleinere Änderungen:

  1. Die Zeitstempel-Nutzlast wurde unverändert an die Task Queue übergeben, war aber für Cloud Tasks JSON-codiert und muss daher bei der Ankunft JSON-geparst werden.
  2. Der HTTP-POST-Aufruf von /trim mit Task Queue hatte einen impliziten MIME-Typ von application/x-www-form-urlencoded, aber mit Cloud Tasks wird er explizit als application/json angegeben. Daher gibt es eine etwas andere Möglichkeit, die Nutzlast zu extrahieren.
  3. Verwenden Sie den Cloud NDB API-Client-Kontextmanager (Modul 2: Migration zu Cloud NDB).

Unten sehen Sie die Code-Snippets vor und nach der Änderung des Task-Handlers 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

DANACH:

@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

Es gibt keine Updates für den Hauptanwendungs-Handler root() oder die Webvorlage templates/index.html.

6. Zusammenfassung/Bereinigung

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

Anwendung bereitstellen und überprüfen

Stellen Sie Ihre App mit gcloud app deploy bereit. Die Ausgabe sollte mit der App aus Modul 7 identisch sein. Sie haben jedoch zu einem völlig anderen Produkt für die Push-Warteschlange gewechselt, wodurch Ihre App portabler als zuvor ist.

4aa8a2cb5f527079.png

Bereinigen

Allgemein

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

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

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • Die oben genannten Speicherlinks hängen von Ihrem PROJECT_ID und *LOC*ab, z. B. „us“, wenn Ihre App in den USA gehostet wird.

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

Spezifisch für dieses Codelab

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

  • Für Cloud Tasks gibt es eine kostenlose Stufe. Weitere Informationen finden Sie auf der Preisseite.
  • Der Dienst App Engine Datastore wird von Cloud Datastore (Cloud Firestore im Datastore-Modus) bereitgestellt, das ebenfalls eine kostenlose Stufe bietet. Weitere Informationen finden Sie auf der Preisseite.

Nächste Schritte

Damit ist die Migration von App Engine Task Queue-Push-Aufgaben zu Cloud Tasks abgeschlossen. Wenn Sie diese App weiterhin zu Python 3 portieren und von Cloud NDB zu Cloud Datastore migrieren möchten, sollten Sie sich Modul 9 ansehen.

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

Cloud NDB und Cloud Datastore greifen beide auf Datastore zu (wenn auch auf unterschiedliche Weise). Der einzige Grund für einen Wechsel zu Cloud Datastore ist, wenn Sie bereits andere Apps, insbesondere Nicht-App Engine-Apps, haben, die Cloud Datastore verwenden, und Sie eine einheitliche Datastore-Clientbibliothek verwenden möchten. Diese optionale Migration von Cloud NDB zu Cloud Datastore wird auch separat (ohne Task Queue oder Cloud Tasks) in Modul 3 behandelt.

Neben den Modulen 3, 8 und 9 gibt es weitere Migrationsmodule, die sich mit der Umstellung von gebündelten App Engine-Legacy-Diensten befassen:

  • Modul 2: Von App Engine NDB zu Cloud NDB migrieren
  • Module 12–13: Von App Engine Memcache zu Cloud Memorystore migrieren
  • Module 15–16: Migration von App Engine Blobstore zu Cloud Storage
  • Module 18–19: App Engine Task Queue (Pull-Aufgaben) zu Cloud Pub/Sub

App Engine ist nicht mehr die einzige serverlose Plattform in Google Cloud. Wenn Sie eine kleine App Engine-Anwendung oder eine Anwendung mit eingeschränkter Funktionalität haben und sie in einen eigenständigen Mikrodienst umwandeln möchten oder eine monolithische Anwendung in mehrere wiederverwendbare Komponenten aufteilen möchten, sind dies gute Gründe für einen Wechsel zu Cloud Functions. Wenn die Containerisierung Teil Ihres Anwendungsentwicklungs-Workflows geworden ist, insbesondere wenn er aus einer CI/CD-Pipeline (Continuous Integration/Continuous Delivery oder Deployment) besteht, sollten Sie eine Migration zu Cloud Run in Betracht ziehen. Diese Szenarien werden in den folgenden Modulen behandelt:

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

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

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

7. Zusätzliche Ressourcen

Unten finden Sie weitere Ressourcen für Entwickler, die sich näher mit diesem oder einem ähnlichen Migrationsmodul sowie mit zugehörigen Produkten befassen möchten. Dazu gehören Orte, an denen Sie Feedback zu diesen Inhalten geben können, Links zum Code und verschiedene Dokumentationen, die für Sie nützlich sein könnten.

Probleme mit Codelabs/Feedback

Wenn Sie Probleme mit diesem Codelab feststellen, suchen Sie bitte zuerst nach Ihrem Problem, bevor Sie es melden. Links zum Suchen und Erstellen neuer Probleme:

Migrationsressourcen

Links zu den Repository-Ordnern für Modul 7 (START) und Modul 8 (FINISH) finden Sie in der Tabelle unten.

Codelab

Python 2

Python 3

Module 7

code

Code (nicht in diesem Tutorial enthalten)

Modul 8 (dieses Codelab)

code

(n/a)

Onlineressourcen

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

App Engine Task Queue und Cloud Tasks

App Engine NDB und Cloud NDB (Datastore)

App Engine-Plattform

Andere Cloud-Informationen

Videos

Lizenz

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