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

1. Übersicht

Diese Reihe von Codelabs – also praxisorientierten Anleitungen zum selbstbestimmten Lernen – soll Entwickler von Google App Engine (Standard) bei der Modernisierung ihrer Anwendungen unterstützen, indem sie sie durch eine Reihe von Migrationen führen. Anschließend können Nutzer ihre Anwendungen portierbarer machen, indem sie sie explizit für Cloud Run, den Container-Hosting-Dienst von Google Cloud in App Engine, sowie andere Container-Hosting-Dienste containerisieren.

In dieser Anleitung erfahren Sie, wie Sie App Engine-Anwendungen mithilfe von Cloud Buildpacks, einer Alternative zu Docker, für die Bereitstellung im vollständig verwalteten Cloud Run-Dienst containerisieren. Cloud Buildpacks containerisieren Ihre Anwendungen, ohne Dockerfile-Dateien zu verwalten oder überhaupt etwas über Docker zu wissen.

Dieses Codelab ist für Python 2-App Engine-Entwickler gedacht, die ihre Anwendungen von den ursprünglich integrierten Diensten entfernt und zu Python 3 portiert haben und nun versuchen, sie in einem Container auszuführen. Das Codelab beginnt entweder mit einer abgeschlossenen Python 3-Anwendung für Modul 2 oder Modul 3.

Du lernst, wie du

  • Anwendung mit Cloud Buildpacks containerisieren
  • Container-Images in Cloud Run bereitstellen

Voraussetzungen

Umfrage

Wie möchten Sie dieses Codelab nutzen?

<ph type="x-smartling-placeholder"></ph> Lesen Sie sie nur durch. Lies sie dir durch und absolviere die Übungen

2. Hintergrund

PaaS-Systeme wie App Engine und Cloud Functions bieten Ihrem Team und Ihrer Anwendung viele Vorteile. Diese serverlosen Plattformen ermöglichen es SysAdmin/DevOps beispielsweise, sich auf die Entwicklung von Lösungen zu konzentrieren. Ihre App kann bei Bedarf automatisch hochskaliert oder auf null herunterskaliert werden, da sie eine nutzungsabhängige Abrechnung zur Kostenkontrolle ermöglicht. Außerdem verwenden sie eine Vielzahl gängiger Entwicklungssprachen.

Die Flexibilität der Container überzeugt jedoch auch mit der Möglichkeit, jede Sprache, jede Bibliothek und jedes Binärprogramm auszuwählen. Google Cloud Run bietet Nutzern das Beste aus beiden Welten, den Komfort einer serverlosen Umgebung und die Flexibilität von Containern.

Die Verwendung von Cloud Run wird in diesem Codelab nicht behandelt. die in der Cloud Run-Dokumentation behandelt werden. Hier erfahren Sie, wie Sie Ihre App Engine-Anwendung für Cloud Run (oder andere Dienste) containerisieren. Bevor Sie fortfahren, sollten Sie ein paar Dinge beachten. Hauptsächlich ist die Nutzererfahrung etwas anders, da Sie keinen Anwendungscode mehr bereitstellen müssen.

Stattdessen müssen Sie sich etwas über Container informieren, z. B. wie sie erstellt und bereitgestellt werden. Sie können auch entscheiden, was Sie in das Container-Image einfügen möchten, einschließlich eines Webservers, da Sie den Webserver von App Engine nicht mehr verwenden werden. Wenn Sie diesem Weg nicht folgen möchten, ist es keine schlechte Option, Ihre Anwendungen in App Engine zu belassen.

In dieser Anleitung erfahren Sie, wie Sie Ihre Anwendung containerisieren, App Engine-Konfigurationsdateien entfernen, einen Webserver verwalten und Ihre Anwendung starten.

Diese Migration umfasst folgende Schritte:

  1. Einrichtung/Vorarbeit
  2. Anwendung
      in Container verpacken
    • Konfigurationsdateien ersetzen
    • Anwendungsdateien ändern

3. Einrichtung/Vorarbeit

Bevor wir mit dem Hauptteil des Tutorials fortfahren, richten wir unser Projekt ein, rufen den Code ab und stellen dann die Referenzanwendung bereit, damit wir wissen, dass wir mit funktionierendem Code beginnen.

1. Projekt einrichten

Wenn Sie die Codelabs Modul 2 oder Modul 3 abgeschlossen 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 hat und die App Engine (App) aktiviert ist.

2. Baseline-Beispiel-App abrufen

Eine der Voraussetzungen für dieses Codelab ist eine funktionierende Beispiel-App für Modul 2 oder 3. Falls Sie keines der Anleitungen haben, sollten Sie zuerst eine der beiden Anleitungen (siehe Links oben) durchgehen, bevor Sie fortfahren. Wenn Sie bereits mit dem Inhalt vertraut sind, können Sie einfach einen der unten aufgeführten Code-Ordner auswählen.

Unabhängig davon, ob Sie Ihre oder unsere verwenden, ist dies der Ausgangspunkt dieses Tutorials. Dieses Codelab führt Sie durch die Migration. Wenn Sie fertig sind, sollte es größtenteils mit den Inhalten im Repository-Ordner FINISH Modul 5 übereinstimmen.

Das Verzeichnis der START-Dateien (Ihre oder unsere) sollte wie folgt 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 ausgeführt haben, können Sie den Container in Container verlagern.

4. Anwendung containerisieren

Docker ist die standardmäßige Containerisierungsplattform in der Branche. Eine Herausforderung bei der Verwendung besteht, wie bereits erwähnt, darin, dass eine effiziente Dockerfile ausgewählt werden muss. Das ist die Konfigurationsdatei, die bestimmt, wie Ihre Container-Images erstellt werden. Buildpacks erfordern dagegen wenig Aufwand, da die Abhängigkeiten Ihrer App durch Selbstprüfung ermittelt werden. Dadurch wird der Buildpack-Container für Ihre App so effizient wie möglich.

Wenn Sie sich nicht mit Docker vertraut machen und Ihre App Engine-Anwendung containerisieren möchten, damit sie auf Cloud Run oder einer anderen Container-Hosting-Plattform ausgeführt werden kann. Wenn Sie erfahren möchten, wie Sie Docker für die App-Containerisierung verwenden, können Sie das Codelab für Modul 4 absolvieren, nachdem Sie dieses Modul abgeschlossen haben. Er ist mit diesem identisch, verwendet jedoch Docker, damit Sie besser verstehen, wie Container-Images verwaltet werden.

Die Migrationsschritte umfassen das Ersetzen der App Engine-Konfigurationsdateien und das Angeben, wie Ihre Anwendung gestartet werden soll. In der folgenden Tabelle sind die zu erwartenden Konfigurationsdateien für jeden Plattformtyp zusammengefasst. Vergleichen Sie die Spalte „App Engine“ mit der Spalte „Buildpacks“ (und optional „Docker“):

Beschreibung

App Engine

Docker

Buildpacks

Allgemeine Konfiguration

app.yaml

Dockerfile

(service.yaml)

Bibliotheken von Drittanbietern

requirements.txt

requirements.txt

requirements.txt

Drittanbieterkonfiguration

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

(nicht zutreffend)

(nicht zutreffend)

Starten

(nicht zutreffend) oder app.yaml (falls entrypoint verwendet)

Dockerfile

Procfile

Dateien ignorieren

.gcloudignore und .gitignore

.gcloudignore, .gitignore und .dockerignore

.gcloudignore und .gitignore

Sobald Ihre Anwendung containerisiert ist, kann sie in Cloud Run bereitgestellt werden. Weitere Optionen für die Google Cloud-Containerplattform sind Compute Engine, GKE und Anthos.

Allgemeine Konfiguration

App Engine startet Ihre Anwendung automatisch, Cloud Run jedoch nicht. Procfile hat eine ähnliche Funktion wie die app.yaml entrypoint-Anweisung. Für unsere Beispielanwendung führt Procfile python main.py aus, um den Flask-Entwicklungsserver zu starten. Bei Bedarf können Sie auch einen Produktions-Webserver wie gunicorn verwenden. Fügen Sie ihn in diesem Fall requirements.txt hinzu. Weitere Informationen zum Bereitstellen aus Quellcode mithilfe von Buildpacks finden Sie auf dieser Cloud Run-Dokumentationsseite.

Sie müssen nur die app.yaml entrypoint-Anweisung in eine Procfile-Datei verschieben. Wenn Sie keinen haben, verwenden Sie vorerst den Flask-Entwicklungsserver, da dies nur eine Beispiel-Testanwendung ist, um Nutzer mit dieser Migration vertraut zu machen. Ihre App ist ein spezieller Startbefehl, den Sie am besten kennen. Im Hintergrund erstellt der Cloud Run-Dienst eine service.yaml, die eher wie eine app.yaml aussieht/funktioniert. Sie können die automatisch generierte service.yaml unter einem Link wie diesem aufrufen. Für Ihren Dienst SVC_NAME und REGION gilt: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Bibliotheken von Drittanbietern

Die Datei requirements.txt 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 ist 20.0.4), dann fügen Sie gunicorn==20.0.4 zu requirements.txt hinzu.

Drittanbieterkonfiguration

Python 2 wird von Buildpacks nicht unterstützt. Deshalb wird hier nicht darauf eingegangen. Python 3-Anwendungen, die in Containern in Cloud Run ausgeführt werden, sind mit Python 3-App Engine-Anwendungen vergleichbar, da Drittanbieterbibliotheken in requirements.txt angegeben werden müssen.

Starten

Python 3-Nutzer können ihre app.yaml-Dateien so konvertieren, dass sie im Abschnitt handlers eine entrypoint anstelle von script: auto-Anweisungen haben. Wenn Sie entrypoint in Ihrem Python 3-app.yaml verwenden, sieht das in etwa so aus:

runtime: python38
entrypoint: python main.py

Die Anweisung entrypoint teilt App Engine mit, wie der Server gestartet werden soll. Sie können es fast direkt in Procfile verschieben. Zusammenfassung, wo eine Einstiegspunktanweisung zwischen beiden Plattformen eingefügt wird: Außerdem wird das Docker-Äquivalent als Hinweis angezeigt:

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

Für Test- und Staging-Zwecke ist es einfach, den Entwicklungsserver von Flask wie oben beschrieben über Python auszuführen, aber Entwickler können für die Produktion auch eine leistungsstärkere Version wählen, wie z. B. das Cloud Run-Schnellstartbeispiel, das gunicorn verwendet.

Anwendungsdateien

Alle Apps in Modul 2 oder Modul 3 sind vollständig mit Python 2-3 kompatibel. Die Kernkomponenten von main.py wurden also nicht geändert. nur ein paar Zeilen Startcode hinzufügen. Fügen Sie am Ende von main.py ein Zeilenpaar hinzu, um den Anwendungsserver zu starten, da für Cloud Run Port 8080 geöffnet sein muss, damit Ihre Anwendung 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 Ihre App Engine-Konfiguration durch Buildpacks und Aktualisierungen der Quelldateien ersetzt wurde, können Sie sie in Cloud Run ausführen. Zuvor möchten wir jedoch noch kurz auf Dienste eingehen.

Dienste und Apps im Vergleich

App Engine wurde in erster Linie zum Hosten von Anwendungen entwickelt, ist aber auch eine Plattform zum Hosten von Webdiensten oder Anwendungen, die aus einer Reihe 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. Verwenden Sie es daher als Bereitstellung eines Dienstes und nicht als Anwendung.

Sofern Ihre App Engine-Anwendung nicht aus mehreren Diensten bestand, mussten Sie bei der Bereitstellung Ihrer Anwendungen wirklich keine Benennungen vornehmen. Das ändert sich mit Cloud Run, da Sie einen Dienstnamen festlegen müssen. Während die appspot.com-Domain einer App Engine ihre Projekt-ID enthält, z.B. https://PROJECT_ID.appspot.com, möglicherweise auch die Abkürzung für die Regions-ID, z.B. http://PROJECT_ID.REGION_ID.r.appspot.com.

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

Dienst bereitstellen

Führen Sie den folgenden Befehl aus, um das Container-Image zu erstellen und in Cloud Run bereitzustellen. Wenn Sie dazu aufgefordert werden, wählen Sie Ihre Region aus und lassen Sie zum einfacheren Testen nicht authentifizierte Verbindungen zu. Wählen Sie die passende Region aus, wobei SVC_NAME der Name des Dienstes ist, 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 prüfen, ob die Bereitstellung erfolgreich war.

Wie der Befehl gcloud zeigt, können Nutzer verschiedene Standardeinstellungen festlegen, um die Ausgabe und die Interaktivität zu reduzieren (siehe oben). Wenn Sie beispielsweise jede Interaktion vermeiden möchten, können Sie stattdessen den folgenden einzeiligen Bereitstellungsbefehl verwenden:

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

Wenn Sie diesen verwenden, müssen Sie denselben Dienstnamen SVC_NAME und den gewünschten REGION-Namen auswählen, nicht die indexierte Menüauswahl wie oben interaktiv.

6. Zusammenfassung/Bereinigung

Prüfen Sie, ob die Anwendung in Cloud Run wie in App Engine funktioniert. Wenn Sie zu dieser Reihe gesprungen sind, ohne eines der vorherigen Codelabs durchzuführen, ändert sich die App selbst nicht. Alle Besuche der Hauptwebseite (/) werden registriert. Sobald Sie die Website häufig genug besucht haben, sieht sie wie folgt aus:

Besuche App

Ihr Code sollte jetzt mit dem Inhalt im Repository-Ordner des Moduls 5 übereinstimmen. Sie haben dieses Codelab für Modul 5 abgeschlossen.

Optional: Bereinigung

Wie wäre es mit einer Bereinigung, damit Ihnen erst dann Kosten in Rechnung gestellt werden, wenn Sie bereit sind, mit dem nächsten Codelab für die Migration fortzufahren? Da Sie jetzt ein anderes Produkt verwenden, sollten Sie die Preisübersicht zu Cloud Run lesen.

Optional: Dienst deaktivieren

Wenn Sie noch nicht mit der nächsten Anleitung fortfahren möchten, deaktivieren Sie den Dienst, um zusätzliche Kosten zu vermeiden. Wenn Sie bereit sind, mit dem nächsten Codelab fortzufahren, können Sie es wieder aktivieren. Solange Ihre Anwendung deaktiviert ist, wird kein Traffic berechnet. Ihnen können jedoch auch Kosten für die Datenspeichernutzung in Rechnung gestellt werden, wenn sie das kostenlose Kontingent überschreitet. Löschen Sie also so viel, dass Sie unter dieses Limit fallen.

Wenn Sie jedoch nicht mit der Migration fortfahren und alles vollständig löschen möchten, können Sie entweder den Dienst löschen oder das Projekt vollständig herunterfahren.

Nächste Schritte

Herzlichen Glückwunsch, Sie haben Ihre Anwendung containerisiert. Damit ist diese Anleitung abgeschlossen. Im nächsten Schritt erfahren Sie, wie Sie im Codelab zu Modul 4 (Link unten) dasselbe mit Docker tun oder eine weitere App Engine-Migration durchlaufen:

  • Modul 4: Mit Docker zu Cloud Run migrieren
    • Anwendung containerisieren, um sie mit Docker in Cloud Run auszuführen
    • Ermöglicht es Ihnen, bei Python 2 zu bleiben
  • Modul 7: App Engine-Push-Aufgabenwarteschlangen (erforderlich, wenn Sie [push]-Aufgabenwarteschlangen verwenden)
    • Fügt App Engine-taskqueue-Push-Aufgaben zur Anwendung in Modul 1 hinzu
    • Bereitet Nutzer auf die Migration zu Cloud Tasks in Modul 8 vor
  • Modul 3:
    • Datastore-Zugriff von Cloud NDB auf Cloud Datastore modernisieren
    • Dies ist die Bibliothek, die für Python 3-Anwendungen in App Engine und Anwendungen verwendet wird, die nicht von App Engine stammen
  • Modul 6: Zu Cloud Firestore migrieren
    • Migrieren Sie zu Cloud Firestore, 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

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

Python 3

Modul 2

code

(Code)

Modul 3

(Code)

code

Modul 5

(nicht zutreffend)

code

App Engine- und Cloud Run-Ressourcen

Nachfolgend finden Sie zusätzliche Ressourcen zu dieser Migration: