Modul 5: Mit Cloud Buildpacks von der Google App Engine zu Cloud Run migrieren

1. Übersicht

Diese Reihe von Codelabs (Tutorials zum selbstbestimmten Lernen) soll Google App Engine-Entwicklern (Standard) helfen, ihre Apps zu modernisieren, indem sie durch eine Reihe von Migrationen geführt werden. Danach können Nutzer ihre Apps portabler machen, indem sie sie explizit für Cloud Run, den Container-Hosting-Dienst von Google Cloud, der App Engine ähnelt, und andere Container-Hosting-Dienste containerisieren.

In dieser Anleitung erfahren Sie, wie Sie App Engine-Anwendungen für die Bereitstellung im vollständig verwalteten Cloud Run-Dienst mithilfe von Cloud Buildpacks containerisieren. Cloud Buildpacks sind eine Alternative zu Docker. Mit Cloud Buildpacks werden Ihre Anwendungen containerisiert, ohne dass Sie Dockerfile-Dateien verwalten oder sich mit Docker auskennen müssen.

Dieses Codelab richtet sich an Python 2-App Engine-Entwickler, die ihre Apps von den ursprünglichen integrierten Diensten entfernt und zu Python 3 portiert haben und die sie jetzt in einem Container ausführen möchten. Das Codelab BEGINNT entweder mit einer fertigen Python 3-App aus Modul 2 oder Modul 3.

In diesem Kurs lernen Sie, wie Sie

  • Anwendung mit Cloud Buildpacks containerisieren
  • Container-Images für Cloud Run bereitstellen

Voraussetzungen

Umfrage

Wie werden Sie dieses Codelab verwenden?

Nur lesen Lesen und Übungen machen

2. Hintergrund

PaaS-Systeme wie App Engine und Cloud Functions bieten viele Vorteile für Ihr Team und Ihre Anwendung. Mit diesen serverlosen Plattformen können sich Systemadministratoren und DevOps-Teams beispielsweise auf die Entwicklung von Lösungen konzentrieren. Ihre App kann bei Bedarf automatisch hochskaliert und auf null herunterskaliert werden. Die nutzungsbasierte Abrechnung hilft Ihnen, die Kosten im Blick zu behalten. Außerdem werden verschiedene gängige Entwicklungssprachen unterstützt.

Die Flexibilität von Containern ist jedoch auch überzeugend, da Sie jede Sprache, jede Bibliothek und jedes Binärprogramm auswählen können. Google Cloud Run bietet Nutzern das Beste aus beiden Welten: den Komfort von Serverless in Kombination mit der Flexibilität von Containern.

Die Verwendung von Cloud Run ist nicht Gegenstand dieses Codelabs. Informationen dazu finden Sie in der Cloud Run-Dokumentation. Ziel ist es, dass Sie wissen, wie Sie Ihre App Engine-Anwendung für Cloud Run (oder andere Dienste) in einen Container packen. Bevor Sie fortfahren, sollten Sie einige Dinge wissen. Vor allem wird sich die Nutzerfreundlichkeit etwas ändern, da Sie nicht mehr Anwendungscode verwenden und bereitstellen.

Stattdessen müssen Sie etwas über Container lernen, z. B. wie Sie sie erstellen und bereitstellen. Sie können auch entscheiden, was Sie in das Container-Image aufnehmen möchten, z. B. einen Webserver, da Sie den Webserver von App Engine nicht mehr verwenden. Wenn Sie diesen Weg nicht gehen möchten, ist es keine schlechte Option, Ihre Apps in App Engine zu behalten.

In dieser Anleitung erfahren Sie, wie Sie Ihre App in einen Container packen, App Engine-Konfigurationsdateien entfernen und einen Webserver verwalten, einschließlich des Startens Ihrer App.

Diese Migration umfasst die folgenden Schritte:

  1. Einrichtung/Vorbereitung
  2. Anwendung
      containerisieren
    • Konfigurationsdateien ersetzen
    • Anwendungsdateien ändern

3. Einrichtung/Vorbereitung

Bevor wir mit dem Hauptteil des Tutorials beginnen, richten wir unser Projekt ein, rufen den Code ab und stellen die Baseline-App bereit, damit wir wissen, dass wir mit funktionierendem Code begonnen haben.

1. Projekt einrichten

Wenn Sie das Codelab zu Modul 2 oder Modul 3 abgeschlossen 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 Abrechnungskonto hat und App Engine (App) 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 oder 3. Wenn Sie keine haben, empfehlen wir Ihnen, eines der beiden Tutorials (Links oben) durchzuarbeiten, bevor Sie hier fortfahren. Wenn Sie sich bereits mit den Inhalten vertraut gemacht haben, können Sie einfach einen der Codeordner unten auswählen.

Ganz gleich, ob Sie Ihre eigene oder unsere verwenden – hier beginnt diese Anleitung. In diesem Codelab wird die Migration beschrieben. Am Ende sollte der Code weitgehend dem Code im Ordner „Module 5 FINISH“ im Repository entsprechen.

Das Verzeichnis der START-Dateien (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

Sobald Sie diese Schritte ausgeführt haben, können Sie die Anwendung in einen Container packen.

4. Anwendung containerisieren

Docker ist heute die Standardplattform für die Containerisierung in der Branche. Eine Herausforderung bei der Verwendung von Cloud Build besteht darin, dass es, wie bereits erwähnt, Aufwand erfordert, ein effizientes Dockerfile zu erstellen. Diese Konfigurationsdatei bestimmt, wie Ihre Container-Images erstellt werden. Buildpacks erfordern dagegen nur wenig Aufwand, da sie die Abhängigkeiten Ihrer App durch Introspection ermitteln und den Buildpacks-Container so effizient wie möglich für Ihre App gestalten.

Sie sind hier richtig, wenn Sie Docker nicht kennen müssen und Ihre App Engine-Anwendung containerisieren möchten, um sie in Cloud Run oder auf einer anderen Container-Hosting-Plattform auszuführen. Wenn Sie wissen möchten, wie Sie Docker für die Containerisierung von Apps verwenden, können Sie nach Abschluss dieses Codelabs das Codelab zu Modul 4 durcharbeiten. Es ist identisch mit diesem, verwendet aber Docker, um Ihnen ein besseres Verständnis dafür zu vermitteln, wie Sie Container-Images verwalten.

Bei der Migration müssen Sie die App Engine-Konfigurationsdateien ersetzen und angeben, wie Ihre App gestartet werden soll. In der folgenden Tabelle sind die Konfigurationsdateien zusammengefasst, die für die einzelnen Plattformtypen zu erwarten sind. Vergleichen Sie die App Engine-Spalte mit der Spalte „Buildpacks“ (und optional „Docker“):

Beschreibung

App Engine

Docker

Buildpacks

Allgemeine Konfiguration

app.yaml

Dockerfile

(service.yaml)

Drittanbieterbibliotheken

requirements.txt

requirements.txt

requirements.txt

Drittanbieterkonfiguration

app.yaml (sowie appengine_config.py und lib [nur Version 2.x])

(n/a)

(n/a)

Starten

(n. v.) oder app.yaml (falls entrypoint verwendet wird)

Dockerfile

Procfile

Dateien ignorieren

.gcloudignore und .gitignore

.gcloudignore, .gitignore und .dockerignore

.gcloudignore und .gitignore

Sobald Ihre App containerisiert ist, kann sie in Cloud Run bereitgestellt werden. Zu den anderen Google Cloud-Containerplattformen gehören Compute Engine, GKE und Anthos.

Allgemeine Konfiguration

App Engine startet Ihre Anwendung automatisch, Cloud Run jedoch nicht. Die Procfile hat eine ähnliche Funktion wie die app.yaml entrypoint-Anweisung. In unserer Beispielanwendung wird durch Procfile der Befehl python main.py ausgeführt, um den Flask-Entwicklungsserver zu starten. Sie können bei Bedarf auch einen Produktionswebserver wie gunicorn verwenden. Wenn Sie dies tun, müssen Sie ihn requirements.txt hinzufügen. Weitere Informationen zum Bereitstellen aus Quellcode mit Buildpacks

Sie müssen nur die app.yaml entrypoint-Anweisung in ein Procfile verschieben. Wenn Sie keinen haben, verwenden Sie vorerst den Flask-Entwicklungsserver, da es sich hierbei nur um eine Beispiel-Testanwendung handelt, mit der Nutzer mit dieser Migration vertraut gemacht werden sollen. Ihre App ist ein bestimmter Startbefehl, den Sie am besten kennen. Im Hintergrund wird durch den Cloud Run-Dienst eine service.yaml erstellt, die eher wie eine app.yaml aussieht und sich auch so verhält. Sie können die automatisch generierte service.yaml aufrufen, indem Sie einen Link wie diesen für Ihren Dienst SVC_NAME und REGION aufrufen: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Drittanbieterbibliotheken

Die requirements.txt-Datei muss nicht geändert werden. Flask sollte zusammen mit Ihrer Datastore-Clientbibliothek (Cloud Datastore oder Cloud NDB) vorhanden sein. Wenn Sie einen anderen WSGI-kompatiblen HTTP-Server wie Gunicorn verwenden möchten (die aktuelle Version zum Zeitpunkt der Erstellung dieses Dokuments ist 20.0.4), fügen Sie gunicorn==20.0.4 zu requirements.txt hinzu.

Drittanbieterkonfiguration

Buildpacks unterstützt Python 2 nicht. Daher wird das hier nicht behandelt. Python 3-Anwendungen, die in Containern in Cloud Run ausgeführt werden, ähneln Python 3-App Engine-Anwendungen insofern, als Drittanbieterbibliotheken in requirements.txt angegeben werden müssen.

Starten

Python 3-Nutzer haben die Möglichkeit, ihre app.yaml-Dateien so zu konvertieren, dass sie im Abschnitt handlers anstelle von script: auto-Anweisungen entrypoint-Anweisungen enthalten. Wenn Sie entrypoint in Ihrem Python 3-app.yaml verwenden, sieht das so aus:

runtime: python38
entrypoint: python main.py

Die entrypoint-Anweisung gibt an, wie App Engine den Server starten soll. Sie können sie fast direkt in Ihre Procfile verschieben. Zusammenfassend lässt sich sagen, dass eine Einstiegspunkt-Anweisung auf beiden Plattformen an derselben Stelle steht. Das Docker-Äquivalent ist unten aufgeführt:

  • Buildpacks: Zeile in Procfile: web: python main.py
  • Docker: Zeile in Dockerfile: ENTRYPOINT ["python", "main.py"]

Für Tests und Staging ist es einfach, den Entwicklungsserver von Flask wie oben beschrieben über Python auszuführen. Entwickler können sich für die Produktion jedoch für etwas Leistungsfähigeres entscheiden, z. B. für das Cloud Run-Schnellstartbeispiel, in dem gunicorn verwendet wird.

Anwendungsdateien

Alle Apps aus Modul 2 oder Modul 3 sind vollständig mit Python 2 und Python 3 kompatibel. Das bedeutet, dass sich an den Kernkomponenten von main.py nichts ändert. Wir fügen nur einige Zeilen Startcode hinzu. Fügen Sie unten in main.py ein Zeilenpaar hinzu, um den Entwicklungsserver zu starten. Cloud Run erfordert, dass Port 8080 geöffnet ist, damit Ihre App aufgerufen werden kann:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. Erstellen und bereitstellen

Nachdem Sie Ihre App Engine-Konfiguration durch Buildpacks ersetzt und die Quelldateien aktualisiert haben, können Sie die Anwendung in Cloud Run ausführen. Bevor wir dazu kommen, möchten wir kurz auf Dienste eingehen.

Dienste und Apps

App Engine wurde zwar in erster Linie für das Hosting von Anwendungen entwickelt, ist aber auch eine Plattform für das Hosting von Webdiensten oder Anwendungen, die aus einer Sammlung von Mikrodiensten bestehen. In Cloud Run ist alles ein Dienst, unabhängig davon, ob es sich um einen tatsächlichen Dienst oder eine Anwendung mit einer Weboberfläche handelt. Die Verwendung sollte daher als Bereitstellung eines Dienstes und nicht einer Anwendung betrachtet werden.

Sofern Ihre App Engine-Anwendung nicht aus mehreren Diensten bestand, mussten Sie bei der Bereitstellung Ihrer Anwendungen keine Namensgebung vornehmen. Das ändert sich bei Cloud Run, wo Sie einen Dienstnamen angeben müssen. Die appspot.com-Domain einer App Engine-Anwendung enthält die Projekt-ID, z.B. https://PROJECT_ID.appspot.com, und möglicherweise die Abkürzung der Regions-ID, z.B. http://PROJECT_ID.REGION_ID.r.appspot.com.

Die Domain für einen Cloud Run-Dienst enthält jedoch den Dienstnamen, die Abkürzung der Regions-ID und einen Hash, aber nicht die Projekt-ID, z.B. https://SVC_NAME-HASH-REG_ABBR.a.run.app. Sie sollten sich also einen Dienstnamen überlegen.

Dienst bereitstellen

Führen Sie den folgenden Befehl aus, um Ihr Container-Image zu erstellen und in Cloud Run bereitzustellen. Wählen Sie bei Aufforderung Ihre Region aus und erlauben Sie nicht authentifizierte Verbindungen, um das Testen zu erleichtern. Wählen Sie Ihre Region entsprechend aus. Dabei ist SVC_NAME der Name des Dienstes, den Sie bereitstellen.

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Rufen Sie die angegebene URL in Ihrem Browser auf, um zu bestätigen, dass die Bereitstellung erfolgreich war.

Wie der Befehl gcloud zeigt, können Nutzer verschiedene Standardeinstellungen festlegen, um die Ausgabe und Interaktivität wie oben beschrieben zu reduzieren. Um beispielsweise jegliche Interaktion zu vermeiden, können Sie stattdessen den folgenden Einzeilen-Bereitstellungsbefehl verwenden:

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

Wenn Sie diesen verwenden, wählen Sie unbedingt denselben Dienstnamen SVC_NAME und den gewünschten REGION Namen aus und nicht die indexierte Menüauswahl wie oben.

6. Zusammenfassung/Bereinigung

Prüfen Sie, ob die App in Cloud Run wie in App Engine funktioniert. Wenn Sie diese Reihe ohne die vorherigen Codelabs durchgearbeitet haben, ändert sich die App selbst nicht. Sie erfasst alle Besuche der Hauptwebseite (/) und sieht so aus, wenn Sie die Website oft genug besucht haben:

visitme app

Ihr Code sollte jetzt mit dem Code im Repo-Ordner für Modul 5 übereinstimmen. Herzlichen Glückwunsch zum Abschluss dieses Codelabs zu Modul 5.

Optional: Bereinigen

Was ist mit der Bereinigung, um Gebühren zu vermeiden, bis Sie bereit sind, mit dem nächsten Migrations-Codelab fortzufahren? Da Sie jetzt ein anderes Produkt verwenden, sollten Sie sich den Cloud Run-Preisleitfaden ansehen.

Optional: Dienst deaktivieren

Wenn Sie noch nicht mit dem nächsten Tutorial fortfahren möchten, deaktivieren Sie den Dienst, um zusätzliche Kosten zu vermeiden. Wenn Sie mit dem nächsten Codelab fortfahren möchten, können Sie es wieder aktivieren. Wenn Ihre App deaktiviert ist, fallen keine Gebühren für Traffic an. Allerdings können Ihnen Gebühren für die Datastore-Nutzung in Rechnung gestellt werden, wenn diese das kostenlose Kontingent überschreitet. Löschen Sie daher genügend Daten, um unter diesem Limit zu bleiben.

Wenn Sie die Migrationen nicht fortsetzen und alles vollständig löschen möchten, können Sie entweder Ihren Dienst löschen oder Ihr Projekt vollständig beenden.

Nächste Schritte

Herzlichen Glückwunsch! Sie haben Ihre App containerisiert und damit dieses Tutorial abgeschlossen. Als Nächstes können Sie im Codelab für Modul 4 (Link unten) erfahren, wie Sie dasselbe mit Docker tun, oder eine andere App Engine-Migration durchführen:

  • Modul 4:Mit Docker zu Cloud Run migrieren 
    • Anwendung mit Docker für die Ausführung in Cloud Run containerisieren
    • Sie können weiterhin Python 2 verwenden
  • Modul 7:App Engine-Push-Aufgabenwarteschlangen (erforderlich, wenn Sie [Push-]Aufgabenwarteschlangen verwenden)
    • Fügt der App in Modul 1 taskqueue-Push-Aufgaben für App Engine hinzu
    • Bereitet Nutzer auf die Migration zu Cloud Tasks in Modul 8 vor.
  • Modul 3:
    • Datastore-Zugriff von Cloud NDB auf Cloud Datastore modernisieren
    • Diese Bibliothek wird für Python 3-App Engine-Anwendungen und Nicht-App Engine-Anwendungen verwendet.
  • Modul 6:Zu Cloud Firestore migrieren
    • Zu Cloud Firestore migrieren, um auf Firebase-Funktionen zuzugreifen
    • Cloud Firestore unterstützt zwar Python 2, dieses Codelab ist jedoch nur in Python 3 verfügbar.

7. 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 2 und 3 (START) sowie Modul 5 (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 2

Python 3

Modul 2

code

(Code)

Modul 3

(Code)

code

Modul 5

(n/a)

code

App Engine- und Cloud Run-Ressourcen

Unten finden Sie zusätzliche Ressourcen zu dieser speziellen Migration: