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

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.

Es gibt Situationen, in denen Sie noch keine "gesamte App" haben. um die Ressourcen von App Engine oder Cloud Run zu benötigen. 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.

Sie werden lernen,

  • Cloud Shell verwenden
  • Google Cloud Translation API aktivieren
  • API-Anfragen authentifizieren
  • Kleine App Engine-Anwendung zur Ausführung in Cloud Functions konvertieren
  • Code in Cloud Functions bereitstellen

Voraussetzungen

Umfrage

Wie möchten Sie diese Anleitung nutzen?

<ph type="x-smartling-placeholder"></ph> Nur bis zum Ende lesen 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

PaaS-Systeme wie Google App Engine und Cloud Functions bieten Nutzern viele Komfort. Dank dieser serverlosen Plattformen kann sich Ihr technisches Team auf die Entwicklung von Geschäftslösungen konzentrieren, anstatt sich mit der Untersuchung der zu verwendenden Plattformen und der Menge der benötigten Hardware befassen zu müssen. Anwendungen lassen sich nach Bedarf automatisch hochskalieren und dank nutzungsbasierter Abrechnung zur Kostenkontrolle auf null herunterskalieren. Außerdem sind viele der gängigen Entwicklungssprachen verfügbar.

Die Entwicklung von Full-Stack-Webanwendungen oder komplexe Back-Ends für mobile Apps eignen sich zwar hervorragend für App Engine, es ist jedoch oft der Fall, dass Entwickler hauptsächlich versuchen, einige Funktionen online bereitzustellen, z. B. einen Nachrichtenfeed zu aktualisieren oder den aktuellen Spielstand des Play-offs der Heimmannschaft abzurufen. Es gibt zwar Programmierlogik für beide Szenarien, keine der beiden Szenarien scheint jedoch vollständig ausgeführte "Anwendungen" zu sein. die Leistung von App Engine erfordern. Hier kommen Cloud Functions-Funktionen ins Spiel.

Cloud Functions dient zur Bereitstellung der kleinen Code-Snippets, die:

  • nicht Teil einer ganzen Anwendung ist,
  • nicht im gesamten Entwicklungspaket benötigt
  • sich in einer App oder einem einzelnen mobilen App-Back-End befindet, 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 gemeinsame Datenbank wie Cloud Firestore oder Cloud SQL verwenden. Wenn Ihre Funktion oder Ihr Mikrodienst containerisiert und serverlos in Cloud Run ausgeführt werden soll, können Sie dies ebenfalls tun.

Unsere App Engine-Beispielanwendung, die in fast allen Migrationsanleitungen verwendet wurde, ist eine kurze Anwendung mit grundlegenden Funktionen, die genauso gut in Cloud Functions funktioniert. In dieser Anleitung erfahren Sie, wie Sie diese Anwendung für die Ausführung in Cloud Functions ändern. Da Funktionen aus Sicht der App Engine einfacher sind als ganze Apps, sollten die ersten Schritte einfacher (und schneller) sein und mit einem geringeren Aufwand verbunden sein. im Allgemeinen. Diese Migration umfasst folgende Schritte:

  • Einrichtung/Vorarbeit
  • Konfigurationsdateien entfernen
  • Anwendungsdateien ändern

3. Einrichtung/Vorarbeit

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

1. Projekt einrichten

Wenn Sie das Codelab für Modul 2 abgeschlossen und zu Python 3 übertragen haben, empfehlen wir Ihnen, dasselbe Projekt und denselben Code wiederzuverwenden. Alternativ können Sie ein ganz neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Achten Sie darauf, dass das Projekt ein aktives Rechnungskonto mit aktiviertem App Engine-Dienst hat.

2. Baseline-Beispiel-App abrufen

Eine der Voraussetzungen für dieses Codelab ist eine funktionierende Beispiel-App für Modul 2. Falls Sie kein Google Ads-Konto haben, gehen Sie die oben verlinkten Anleitungen durch, bevor Sie fortfahren. Falls Sie bereits mit dem Inhalt vertraut sind, können Sie damit beginnen, indem Sie sich den Code für Modul 2 unten holen.

Unabhängig davon, ob Sie Ihren oder unseren verwenden, beginnen wir mit dem Python 3-Code in Modul 2. Dieses Codelab für Modul 11 führt Sie durch die einzelnen Schritte und endet mit einem Code, der dem im Repository-Ordner von Modul 11 (FINISH) ähnelt.

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

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

3. Referenz-App noch einmal bereitstellen

Sie müssen die verbleibenden Schritte jetzt ausführen:

  1. Machen Sie sich noch einmal mit dem gcloud-Befehlszeilentool vertraut
  2. Beispielanwendung mit gcloud app deploy noch einmal bereitstellen
  3. Prüfen, ob die Anwendung in App Engine problemlos ausgeführt wird

Nachdem Sie diese Schritte erfolgreich ausgeführt haben, können Sie sie in eine Cloud Functions-Funktion konvertieren.

4. Konfigurationsdateien entfernen

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

Wenn Sie auch eine App Engine-Anwendung für Python 2 zu Python 3 übertragen, löschen Sie appengine_config.py und gegebenenfalls den Ordner lib. Es sind App Engine-Artefakte, die in der Python 3-Laufzeit nicht verwendet werden.

5. Anwendungsdateien ändern

Es gibt nur die Anwendungsdatei main.py. Daher werden alle erforderlichen Änderungen für die Verschiebung zu Cloud Functions in dieser Datei vorgenommen.

Importe

Da wir nur mit Funktionen arbeiten, wird kein Webanwendungs-Framework benötigt. Der Einfachheit halber wird ihnen jedoch beim Aufrufen von Python-basierten Cloud Functions-Funktionen 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 wurde.

Da Web-Frameworks nicht Bestandteil der Cloud Functions-Umgebung sind, gibt es keine Importe aus Flask, es sei denn, Ihre Anwendung verwendet andere Flask-Features. Dies ist in der Tat unser Fall, da das Vorlagen-Rendering immer noch nach der Konvertierung in eine Funktion stattfindet, was bedeutet, dass ein zum Aufrufen von flask.render_template() immer noch erforderlich ist, also sein Import aus Flask. Da kein Web-Framework bedeutet, dass eine Flask-Anwendung nicht instanziiert werden muss, löschen Sie app = Flask(__name__). Ihr Code sieht vor und nach dem Übernehmen der Änderungen in etwa so aus:

VORHER:

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

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

NACHHER:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Wenn Sie vom App-Objekt (app) oder einer anderen Web-Framework-Infrastruktur abhängig sind, müssen Sie alle diese Abhängigkeiten auflösen, geeignete Problemumgehungen finden oder deren Nutzung vollständig entfernen oder Proxys suchen. Nur dann können Sie Ihren Code in eine Cloud Functions-Funktion konvertieren. Andernfalls können Sie bei der App Engine bleiben oder Ihre Anwendung für Cloud Run containerisieren.

Signatur der Haupt-Handler-Funktion aktualisieren

In der Funktionssignatur sind folgende Änderungen erforderlich:

  1. Nach der Konvertierung der Anwendung in eine Cloud Functions-Funktion wird Flask nicht mehr verwendet. Entfernen Sie daher Routen-Decorators.
  2. Cloud Functions übergibt das Flask-Request-Objekt 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 benannt werden. Unser Haupt-Handler wurde in App Engine entsprechend root() benannt, um zu beschreiben, was er war (der Root-Anwendungs-Handler). Da es sich um eine Cloud Functions-Funktion handelt, ist es weniger sinnvoll, diesen Namen zu verwenden. Stattdessen stellen wir die Cloud Functions-Funktion unter dem Namen visitme bereit. Verwenden Sie diesen Namen also auch als Namen der Python-Funktion. In den Modulen 4 und 5 haben wir den Cloud Run-Dienst ebenfalls visitme genannt.

Hier sind die Vorher- und Nachher-Änderungen dieser Änderungen:

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)

NACHHER:

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)

Damit sind alle erforderlichen Aktualisierungen abgeschlossen. Beachten Sie, dass sich die vorgenommenen Änderungen nur auf die "Infrastruktur" der Anwendung auswirken. Code. Am Code der Hauptanwendung sind keine Änderungen erforderlich und die Funktionalität der App wurde nicht verändert. Hier ist eine bildliche Darstellung der Änderungen, die vorgenommen wurden, um diesen Punkt zu veranschaulichen:

668f30e3865b27a9.png

Lokale Entwicklung und Tests

Während App Engine über den lokalen dev_appserver.py-Anwendungsserver verfügt, hat Cloud Functions das Functions Framework. Mit diesem Framework können Sie lokal entwickeln und testen. Ihr Code kann in Cloud Functions, aber auch auf anderen Computing-Plattformen wie Compute Engine, Cloud Run und sogar lokalen oder Hybrid-Cloud-Systemen, die Knative unterstützen, bereitgestellt werden. Weitere Links zu Functions Framework finden Sie unten.

6. Erstellen und bereitstellen

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

$ 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 die Funktion bereitgestellt wurde, verwenden Sie die URL aus der Bereitstellungsausgabe und rufen Sie die Anwendung auf. Die URL hat das folgende Format: REGION-PROJECT_ID.cloudfunctions.net/visitme. Die Ausgabe sollte mit der vorherigen Bereitstellung in App Engine identisch sein:

2732ae9218f011a2.png

Wie bei den meisten anderen Codelabs und Videos der Reihe ändert sich die grundlegende Funktionalität der App nicht. Ziel ist es, eine Modernisierungstechnik anzuwenden, bei der die Anwendung genau wie zuvor funktioniert, aber auf einer neueren Infrastruktur basiert. Beispielsweise soll sie von einem älteren App Engine-Legacy-Dienst zu ihrem eigenständigen Cloud-Ersatzprodukt migriert werden oder, wie im Fall dieser Anleitung, das Verschieben einer Anwendung auf eine andere serverlose Google Cloud-Plattform.

7. Zusammenfassung/Bereinigung

Herzlichen Glückwunsch zum Umwandeln dieser kleinen App Engine-App in eine Cloud Functions-Funktion! Ein weiterer geeigneter Anwendungsfall: Aufteilen einer großen monolithischen App Engine-Anwendung in eine Reihe von Mikrodiensten, die jeweils als Cloud Functions-Funktion dienen. Dies ist eine modernere Entwicklungstechnik, die zu einem „Plug-and-Play“-Prinzip führt. Komponente (ala "JAM Stack") hinzu. Sie ermöglicht das Mischen und Abgleichen sowie die Wiederverwendung von Code – zwei Ziele. Ein weiterer Vorteil besteht darin, dass diese Mikrodienste im Laufe der Zeit weiterhin debuggen werden, was stabiler Code und insgesamt geringere Wartungskosten bedeutet.

Bereinigen

Nachdem Sie dieses Codelab abgeschlossen haben, können Sie die App Engine-Anwendung für Modul 2 (vorübergehend oder dauerhaft) deaktivieren, um Gebühren zu vermeiden. Die App Engine-Plattform verfügt über ein kostenloses Kontingent. Ihnen werden also keine Kosten in Rechnung gestellt, solange Sie innerhalb der Nutzungsstufe bleiben. Dasselbe gilt für Datastore. Weitere Informationen finden Sie auf der Preisseite für Cloud Datastore.

Die Bereitstellung auf Plattformen wie App Engine und Cloud Functions verursacht nur geringfügige Build- und Speicherkosten. In einigen Regionen verfügt Cloud Build und Cloud Storage über ein eigenes kostenloses Kontingent. Builds verbrauchen einen Teil dieses Kontingents. Achten Sie auf Ihre Speichernutzung, um potenzielle Kosten zu minimieren, insbesondere wenn es in Ihrer Region keine solche kostenlose Stufe gibt.

Leider ist in Cloud Functions nicht die Option „Deaktivieren“ . Sichern Sie Ihren Code und löschen Sie einfach die Funktion. Sie können sie später mit demselben Namen jederzeit noch einmal bereitstellen. Wenn Sie jedoch nicht mit anderen Migrations-Codelabs fortfahren und alles vollständig löschen möchten, beenden Sie Ihre Cloud-Projekte.

Nächste Schritte

Abgesehen von dieser Anleitung können Sie sich auch mit anderen Migrationsmodulen vertraut machen, etwa die Containerisierung Ihrer App Engine-Anwendung für Cloud Run. Weitere Informationen finden Sie unter den Links zu den Codelabs für Modul 4 und Modul 5:

  • Modul 4: Mit Docker zu Cloud Run migrieren
  • Anwendung containerisieren, um sie mit Docker in Cloud Run auszuführen
  • Durch diese Migration können Sie bei Python 2 bleiben.
  • 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 Dockerfiles wissen.
  • Erfordert, dass Ihre Anwendung bereits zu Python 3 migriert wurde (Buildpacks unterstützen Python 2 nicht)

Viele der anderen Module zeigen Entwicklern, wie sie von gebündelten App Engine-Diensten auf eigenständige Cloud-Dienste umstellen können:

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

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 anstelle von Cloud Functions in Betracht ziehen. In Modul 4 erfahren Sie, wie Sie Ihre Anwendung mit Docker containerisieren, bzw. in Modul 5, um dies ohne Container, Docker-Kenntnisse oder Dockerfiles zu tun. Unabhängig davon, ob Sie Cloud Functions oder Cloud Run in Betracht ziehen, ist der Wechsel zu einer anderen serverlosen Plattform 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.

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

Codelab

Python 3

Modul 2

code

Modul 11

code

Online-Ressourcen

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

App Engine

Cloud Functions

Weitere Cloud-Informationen

Videos

Lizenz

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