Modul 11: Von der Google App Engine zu Cloud Functions migrieren

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.

Es gibt Situationen, in denen Sie keine „gesamte App“ haben, für die die Ressourcen von App Engine oder Cloud Run erforderlich sind. Wenn Ihr Code nur aus einem Mikrodienst oder einer einfachen Funktion besteht, ist Cloud Functions wahrscheinlich besser geeignet. In diesem Codelab erfahren Sie, wie Sie einfache App Engine-Anwendungen migrieren (oder größere Anwendungen in mehrere Mikrodienste aufteilen) und in Cloud Functions bereitstellen, einer weiteren serverlosen Plattform, die speziell für solche Anwendungsfälle entwickelt wurde.

Lerninhalte

  • Cloud Shell verwenden
  • Google Cloud Translation API aktivieren
  • API-Anfragen authentifizieren
  • Kleine App Engine-Anwendung für die Ausführung in Cloud Functions umstellen
  • Code in Cloud Functions bereitstellen

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

PaaS-Systeme wie Google App Engine und Cloud Functions bieten Nutzern viele Vorteile. Mit diesen serverlosen Plattformen kann sich Ihr technisches Team auf die Entwicklung von Geschäftslösungen konzentrieren, anstatt Zeit mit der Suche nach geeigneten Plattformen und der Ermittlung der benötigten Hardware zu verbringen. Anwendungen können bei Bedarf automatisch skaliert werden und mit der nutzungsbasierten Abrechnung auf null herunterskaliert werden, um die Kosten zu kontrollieren. Außerdem unterstützen sie eine Vielzahl der heute gängigen Entwicklungssprachen.

Die Entwicklung von Full-Stack-Webanwendungen oder komplexen Back-Ends für mobile Apps ist zwar ideal für App Engine, aber oft möchten Entwickler nur einige Funktionen online stellen, z. B. einen Newsfeed aktualisieren oder den aktuellen Punktestand des Playoff-Spiels des Heimteams abrufen. Es gibt zwar eine Codierungslogik für beide Szenarien, aber keines scheint eine vollwertige „Anwendung“ zu sein, die die Leistung von App Engine erfordert. Hier kommen Cloud Functions ins Spiel.

Cloud Functions ist für die Bereitstellung des kleinen Code-Ausschnitts vorgesehen, der:

  • Kein Teil einer gesamten Anwendung
  • Nicht im gesamten Entwicklungs-Stack erforderlich
  • Befindet sich in einer Anwendung oder einem einzelnen Backend für mobile Apps, das sich auf eine Sache konzentriert

Sie können Cloud Functions auch verwenden, um eine große, monolithische Anwendung in mehrere Mikrodienste aufzuteilen, die jeweils eine gemeinsame Datenbank wie Cloud Firestore oder Cloud SQL verwenden. Wenn Sie Ihre Funktion oder Ihren Mikrodienst containerisieren und serverlos in Cloud Run ausführen möchten, ist das ebenfalls möglich.

Unsere App Engine-Beispiel-App, die in fast allen Migrationsanleitungen verwendet wird, ist eine kurze App mit grundlegenden Funktionen, die auch in Cloud Functions funktioniert. In dieser Anleitung erfahren Sie, wie Sie diese App so ändern, dass sie in Cloud Functions ausgeführt wird. Aus App Engine-Sicht sind Funktionen einfacher als ganze Apps. Daher sollte der Einstieg einfacher (und schneller) sein und es gibt weniger allgemeinen „Overhead“. Diese Migration umfasst die folgenden Schritte:

  • Einrichtung/Vorbereitung
  • Konfigurationsdateien entfernen
  • Anwendungsdateien ändern

3. Einrichtung/Vorbereitung

Dieses Codelab beginnt mit der Python 3-Version der App Engine-Beispielanwendung für Modul 2 mit Cloud NDB, da Cloud Functions Python 2 nicht unterstützt. Richten wir zuerst unser Projekt ein, rufen wir den Code ab und stellen wir dann die Baseline-App bereit, um zu bestätigen, dass wir mit funktionierendem Code beginnen.

1. Projekt einrichten

Wenn Sie das Codelab zu Modul 2 abgeschlossen und zu Python 3 portiert haben, empfehlen wir, dasselbe Projekt und denselben Code wiederzuverwenden. Alternativ können Sie ein neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Prüfen Sie, ob das Projekt ein aktives Rechnungskonto hat, für das der App Engine-Dienst aktiviert ist.

2. Beispiel-App für die Baseline abrufen

Eine der Voraussetzungen für dieses Codelab ist eine funktionierende Beispiel-App aus Modul 2. Wenn Sie keine haben, führen Sie eines der oben verlinkten Tutorials durch, bevor Sie hier fortfahren. Wenn Sie sich bereits mit den Inhalten vertraut gemacht haben, können Sie direkt mit dem Code aus Modul 2 unten beginnen.

Unabhängig davon, ob Sie Ihren oder unseren Code verwenden, ist der Python 3-Code aus Modul 2 der Ausgangspunkt. In diesem Codelab für Modul 11 werden Sie durch jeden Schritt geführt. Am Ende erhalten Sie Code, der dem im Repo-Ordner für Modul 11 (FINISH) ähnelt.

Das Verzeichnis der START-Dateien für Python 3-Modul 2 (Ihre oder unsere) sollte so aussehen:

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

3. Referenz-App (erneut) bereitstellen

Das sind die verbleibenden Schritte, die Sie jetzt ausführen müssen:

  1. gcloud-Befehlszeilentool
  2. Beispiel-App mit gcloud app deploy noch einmal bereitstellen
  3. Prüfen, ob die App problemlos in App Engine ausgeführt wird

Nachdem Sie diese Schritte ausgeführt haben, können Sie die Funktion in eine Cloud-Funktion umwandeln.

4. Konfigurationsdateien entfernen

Die Datei app.yaml ist ein App Engine-Artefakt, das nicht mit Cloud Functions verwendet wird. Löschen Sie sie jetzt. Wenn Sie dies nicht tun oder vergessen, ist das kein Problem, da Cloud Functions die Datei nicht verwendet. Das ist die einzige Konfigurationsänderung, da requirements.txt mit dem aus Modul 2 identisch bleibt.

Wenn Sie auch eine Python 2-App Engine-Anwendung zu Python 3 portieren, löschen Sie appengine_config.py und den Ordner lib, falls vorhanden. Es handelt sich um App Engine-Artefakte, die in der Python 3-Laufzeit nicht verwendet werden.

5. Anwendungsdateien ändern

Es gibt nur eine Anwendungsdatei, main.py. Alle notwendigen Änderungen für die Migration zu Cloud Functions werden daher in dieser Datei vorgenommen.

Importe

Da wir nur mit Funktionen arbeiten, ist kein Webanwendungs-Framework erforderlich. Aus Gründen der Einfachheit wird jedoch beim Aufrufen von Python-basierten Cloud Functions automatisch ein Anfrageobjekt übergeben, das Ihr Code nach Bedarf verwenden kann. (Das Cloud Functions-Team hat es als Flask-Anfrageobjekt ausgewählt, das an Ihre Funktion übergeben wird.)

Da Web-Frameworks nicht Teil von Cloud Functions sind, gibt es keine Importe aus Flask, es sei denn, Ihre App verwendet andere Flask-Funktionen. Das ist in unserem Fall tatsächlich so, da das Rendern der Vorlage auch nach der Umwandlung in eine Funktion erfolgt. Daher ist weiterhin ein Aufruf von flask.render_template() erforderlich und somit auch der Import aus Flask. Da kein Web-Framework verwendet wird, muss keine Flask-App instanziiert werden. Löschen Sie also app = Flask(__name__). Ihr Code sieht vor und nach dem Anwenden der Änderungen so aus:

VORHER:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

DANACH:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Wenn Sie vom App-Objekt (app) oder einer anderen Webframework-Infrastruktur abhängig sind, müssen Sie alle diese Abhängigkeiten auflösen, indem Sie geeignete Problemumgehungen finden, die Verwendung vollständig entfernen oder Proxys finden. Erst dann können Sie Ihren Code in eine Cloud Functions-Funktion umwandeln. Andernfalls sollten Sie bei App Engine bleiben oder Ihre App für Cloud Run containerisieren.

Signatur der main-Handler-Funktion aktualisieren

Die erforderlichen Änderungen an der Funktionssignatur sind:

  1. Flask wird nach der Umwandlung der App in eine Cloud-Funktion nicht mehr verwendet. Entfernen Sie daher die Routendekoratoren.
  2. Cloud Functions übergibt das Flask-Objekt Request automatisch als Parameter. Erstellen Sie daher eine Variable dafür. In unserer Beispiel-App nennen wir sie request.
  3. Bereitgestellte Cloud Functions-Funktionen müssen einen Namen haben. Unser Haupthandler hieß in App Engine passenderweise root(), um zu beschreiben, was er war (der Root-Anwendungshandler). Als Cloud-Funktion ist es weniger sinnvoll, diesen Namen zu verwenden. Stattdessen stellen wir die Cloud-Funktion mit dem Namen visitme bereit. Verwenden Sie diesen Namen also auch für die Python-Funktion. In den Modulen 4 und 5 haben wir den Cloud Run-Dienst ebenfalls visitme genannt.

Hier sehen Sie die Änderungen im Vorher-Nachher-Vergleich:

VORHER:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

DANACH:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

Das war alles. Die vorgenommenen Änderungen betrafen nur den „Infrastruktur“-Code der Anwendung. Am Kernanwendungscode sind keine Änderungen erforderlich und die Funktionalität der App wurde nicht geändert. Hier eine bildliche Darstellung der Änderungen, die vorgenommen wurden, um diesen Punkt zu veranschaulichen:

668f30e3865b27a9.png

Lokale Entwicklung und Tests

Während App Engine den dev_appserver.py lokalen Entwicklungsserver hat, gibt es für Cloud Functions das Functions Framework. Mit diesem Framework können Sie lokal entwickeln und testen. Ihr Code kann in Cloud Functions bereitgestellt werden, aber auch auf anderen Compute-Plattformen wie Compute Engine, Cloud Run oder sogar in lokalen oder Hybrid-Cloud-Systemen, die Knative unterstützen. Unten finden Sie weitere Links zu Functions Framework.

6. Erstellen und bereitstellen

Die Bereitstellung in Cloud Functions unterscheidet sich geringfügig von der in App Engine. Da außerhalb von requirements.txt keine Konfigurationsdateien verwendet werden, müssen weitere Informationen zum Code in der Befehlszeile angegeben werden. Stellen Sie Ihre neue HTTP-getriggerte Cloud Functions-Funktion, die unter Python 3.10 ausgeführt wird, mit diesem Befehl bereit:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

Die Ausgabe sollte in etwa so aussehen:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

Nachdem Ihre Funktion bereitgestellt wurde, rufen Sie Ihre App über die URL aus der Bereitstellungsausgabe auf. Die URL hat das Format REGION-PROJECT_ID.cloudfunctions.net/visitme. Die Ausgabe sollte identisch mit der Ausgabe sein, die Sie bei der vorherigen Bereitstellung in App Engine erhalten haben:

2732ae9218f011a2.png

Wie bei den meisten anderen Codelabs und Videos der Reihe ändert sich die grundlegende App-Funktionalität nicht. Ziel ist es, eine Modernisierungstechnik anzuwenden und die App genau wie zuvor zu betreiben, aber mit einer neueren Infrastruktur. Das kann beispielsweise durch die Migration von einem alten App Engine-Legacy-Dienst zu seinem Ersatzprodukt in der Cloud oder, wie in dieser Anleitung, durch die Migration einer App zu einer anderen serverlosen Google Cloud-Plattform erreicht werden.

7. Zusammenfassung/Bereinigung

Herzlichen Glückwunsch, dass Sie diese kleine App Engine-Anwendung in eine Cloud-Funktion umgewandelt haben. Ein weiterer geeigneter Anwendungsfall ist das Aufteilen einer großen monolithischen App Engine-Anwendung in eine Reihe von Mikrodiensten, die jeweils als Cloud-Funktion ausgeführt werden. Dies ist eine modernere Entwicklungstechnik, die zu einer „Plug-and-Play“-Komponente im Stil des JAM-Stacks führt. Das ermöglicht das Kombinieren und Wiederverwenden von Code, was zwei Ziele sind. Ein weiterer Vorteil ist, dass diese Mikrodienste im Laufe der Zeit weiter debuggt werden, was zu stabilem Code und insgesamt niedrigeren Wartungskosten führt.

Bereinigen

Nach Abschluss dieses Codelabs können Sie die App Engine-App aus Modul 2 deaktivieren (vorübergehend oder dauerhaft), um Kosten zu vermeiden. Die App Engine-Plattform bietet ein kostenloses Kontingent. Solange Sie die Nutzungsgrenze nicht überschreiten, werden Ihnen keine Kosten in Rechnung gestellt. Das Gleiche gilt für Datastore. Weitere Informationen finden Sie auf der Preisseite für Cloud Datastore.

Bei der Bereitstellung auf Plattformen wie App Engine und Cloud Functions fallen geringe Build- und Speicherkosten an. In einigen Regionen hat Cloud Build ein eigenes kostenloses Kontingent, ebenso wie Cloud Storage. Für Builds wird ein Teil dieses Kontingents verwendet. Behalten Sie Ihre Speichernutzung im Blick, um potenzielle Kosten zu minimieren, insbesondere wenn in Ihrer Region kein solches kostenloses Kontingent verfügbar ist.

Cloud Functions bietet leider keine Funktion zum Deaktivieren. Sichern Sie Ihren Code und löschen Sie die Funktion. Sie können sie später jederzeit mit demselben Namen neu bereitstellen. Wenn Sie jedoch nicht mit anderen Migrations-Codelabs fortfahren und alles vollständig löschen möchten, fahren Sie Ihre Cloud-Projekte herunter.

Nächste Schritte

Neben dieser Anleitung gibt es weitere Migrationsmodule, z. B. zur Containerisierung Ihrer App Engine-Anwendung für Cloud Run. Hier finden Sie die Links zu den Codelabs für Modul 4 und Modul 5:

  • Modul 4: Migration zu Cloud Run mit Docker
  • Anwendung mit Docker für die Ausführung in Cloud Run containerisieren
  • Bei dieser Migration können Sie weiterhin Python 2 verwenden.
  • Modul 5: Mit Cloud Buildpacks zu Cloud Run migrieren
  • Anwendung mit Cloud Buildpacks für die Ausführung in Cloud Run containerisieren
  • Sie müssen nichts über Docker, Container oder Dockerfile wissen.
  • Ihre App muss bereits zu Python 3 migriert sein (Buildpacks unterstützen Python 2 nicht).

Viele der anderen Module konzentrieren sich darauf, Entwicklern zu zeigen, wie sie von gebündelten App Engine-Diensten zu eigenständigen Cloud-Ersatzdiensten migrieren können:

  • Modul 2: Von App Engine ndb zu Cloud NDB migrieren
  • Module 7–9: Push-Aufgaben von App Engine Task Queue zu Cloud Tasks 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: Von App Engine-Aufgabenwarteschlange (Pull-Aufgaben) zu Cloud Pub/Sub migrieren

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 statt Cloud Functions zu Cloud Run migrieren. Modul 4 enthält Informationen zur Containerisierung Ihrer App mit Docker und Modul 5 zur Containerisierung ohne Container, Docker-Kenntnisse oder Dockerfiles. Ob Sie Cloud Functions oder Cloud Run in Betracht ziehen, ist ein Wechsel zu einer anderen serverlosen Plattform 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.

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

Codelab

Python 3

Modul 2

code

Modul 11

code

Onlineressourcen

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

App Engine

Cloud Functions

Andere Cloud-Informationen

Videos

Lizenz

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