Regions-ID
REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.
Dieser Leitfaden bietet eine Einführung in Cloud Run für alle, die mit App Engine vertraut sind. Darin werden die wichtigsten Gemeinsamkeiten und Unterschiede zwischen den serverlosen Plattformen erläutert, um auf die Migration aus der App Engine-Standardumgebung oder der flexiblen App Engine-Umgebung vorzubereiten.
Übersicht
Cloud Run ist die neueste Entwicklung von Google Cloud Serverless und basiert auf der Erfahrung, die aus mehr als einem Jahrzehnt der Ausführung von App Engine entstanden ist. Cloud Run wird auf derselben Infrastruktur wie die App Engine-Standardumgebung ausgeführt, sodass es viele Ähnlichkeiten zwischen diesen beiden Plattformen gibt.
Cloud Run wurde zur Verbesserung der Nutzererfahrung von App Engine entwickelt. Es beinhaltet viele der besten Features sowohl der App Engine-Standardumgebung als auch der flexiblen App Engine-Umgebung. Cloud Run-Dienste können dieselben Arbeitslasten wie App Engine-Dienste verarbeiten, Cloud Run bietet jedoch viel mehr Flexibilität bei der Implementierung dieser Dienste. Dank dieser Flexibilität und den verbesserten Einbindungen in Google Cloud und Diensten von Drittanbietern kann Cloud Run auch Arbeitslasten verarbeiten, die nicht in App Engine ausgeführt werden können.
Zusammenfassung des Vergleichs
Es gibt zwar viele Gemeinsamkeiten und Unterschiede zwischen App Engine und Cloud Run, aber diese Übersicht konzentriert sich auf die Bereiche, die für App Engine-Kunden, die die ersten Schritte mit Cloud Run unternehmen, am relevantesten sind.
| App Engine-Standardumgebung | Flexible App Engine-Umgebung | Cloud Run | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Terminologie | Anwendung | – | |||||||||||||||||||
| Dienst | Dienst | ||||||||||||||||||||
| Version | Überarbeitung | ||||||||||||||||||||
URL-Endpunkte |
|||||||||||||||||||||
| App-URL ( default-Dienst)
|
https://PROJECT_ID.REGION_ID.r.appspot.com
|
– | |||||||||||||||||||
| Service-URL |
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
https://SERVICE_IDENTIFIER.run.app
|
|||||||||||||||||||
| Versions-/Überarbeitungs-URL |
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
https://TAG---SERVICE_IDENTIFIER.run.app
|
|||||||||||||||||||
Skalierung |
|||||||||||||||||||||
| Autoscaling | Ja | Ja | Ja | ||||||||||||||||||
| Manuelle Skalierung | Ja | Ja | Es gibt zwar keine bestimmte manuelle Skalierungseinstellung, aber das gleiche Verhalten kann durch Konfiguration der maximalen Anzahl von Instanzen gleich der Mindestanzahl von Instanzen repliziert werden. | ||||||||||||||||||
| Skalierung auf null | Ja | Nein | Ja | ||||||||||||||||||
| Aufwärmanfragen | Konfigurierbar | Nein | Automatisch | ||||||||||||||||||
| Zeitüberschreitung für inaktive Instanzen (nach Abschluss der letzten Anfrage) | Bis zu 15 Minuten | Abhängig von der Einstellung der CPU-Zuweisung. Verwenden Sie die Immer zugewiesene CPU, um App Engine-Verhalten zu emulieren. | |||||||||||||||||||
| Zeitüberschreitung bei Anfrage |
|
60 Minuten | Bis zu 60 Minuten konfigurierbar (Standard: 5 Minuten) | ||||||||||||||||||
Bereitstellung |
|||||||||||||||||||||
| Über die Quelle. | Ja | Ja | |||||||||||||||||||
| Container-Image | Nein | Ja (benutzerdefinierte Laufzeiten) | Ja | ||||||||||||||||||
Ressourcen berechnen |
|||||||||||||||||||||
| vCPU |
|
Bis zu 80 vCPUs | Bis zu 8 vCPUs | ||||||||||||||||||
| Arbeitsspeicher | Bis zu 6,5 GB pro vCPU | Bis zu 32 GB | |||||||||||||||||||
Preismodell |
|||||||||||||||||||||
| Gebühr pro Anfrage | Nein |
Nein, wenn CPU immer zugewiesen ist. Ja, wenn die CPU nur während der Anfrageverarbeitung zugewiesen wird. |
|||||||||||||||||||
| Mindestanzahl inaktiver Instanzen | Dieselben Kosten wie für aktive Instanzen | Niedrigere Kosten für Mindestanzahl inaktiver Instanzen (siehe abrechenbare Containerinstanzzeit) | |||||||||||||||||||
| Rabatte für zugesicherte Nutzung (CUD) | Nein | Ja | |||||||||||||||||||
Sicherheit |
|||||||||||||||||||||
| Einstellungen für eingehenden Traffic | Ja | Ja | Ja | ||||||||||||||||||
| Rolle „Aufrufer“ | Nein | Ja | |||||||||||||||||||
| IAP | Ja | Ja | Mit Cloud Load Balancing konfigurieren | ||||||||||||||||||
| Firewalls | Ja | Ja | Mit Google Cloud Armor konfigurieren | ||||||||||||||||||
Verbindung |
|||||||||||||||||||||
| Benutzerdefinierte Domains | Ja | Ja | Mit Cloud Load Balancing konfigurieren | ||||||||||||||||||
| VPC-Konnektivität (einschließlich freigegebener VPC) | Ja | – | Ja | ||||||||||||||||||
| Einstellungen für ausgehenden VPC-Traffic | Ja | – | Ja | ||||||||||||||||||
| Multiregionales Load-Balancing | Nein | Ja | |||||||||||||||||||
Auf Google Cloud-Dienste zugreifen |
|||||||||||||||||||||
| Cloud SQL | Ja | Ja | Ja | ||||||||||||||||||
| Cloud-Clientbibliotheken | Wenn Sie Cloud-Clientbibliotheken in App Engine verwenden, müssen Sie bei der Migration zu Cloud Run nichts ändern. Diese Clientbibliotheken sind überall einsatzfähig, d. h., Ihre Anwendung wird portabler. | ||||||||||||||||||||
| Gebündelte App Engine Legacy-Dienste | Ja (nur Java, Python, Go, PHP) | Nein | Nein | ||||||||||||||||||
Ressourcenmodell
Das Cloud Run-Ressourcenmodell ähnelt App Engine sehr, es gibt jedoch einige wichtige Unterschiede:
- Cloud Run hat keine Anwendungsressource auf oberster Ebene oder den entsprechenden
default-Dienst. - Cloud Run-Dienste im selben Projekt können in verschiedenen Regionen bereitgestellt werden. In der App Engine befinden sich alle Dienste im Projekt in derselben Region.
- Cloud Run verwendet den Begriff Überarbeitung anstelle von Version, um sich dem Knative-Ressourcenmodell anzupassen.
- Cloud Run-Überarbeitungsnamen haben das Format
SERVICE_NAME-REVISION_SUFFIX, wobeiREVISION_SUFFIXentweder automatisch generiert oder mit dem Bereitstellungsflag--revision-suffix=REVISION_SUFFIXfestgelegt wird. - Cloud Run-Überarbeitungen sind nicht veränderbar. Das bedeutet, dass Sie Namen nicht wie in App Engine-Versionen (mit dem Bereitstellungs-Flag
--version=VERSION_ID) wiederverwenden können. - Cloud Run-Dienst-URLs basieren auf einer Dienst-ID, die bei der ersten Bereitstellung des Dienstes automatisch generiert wird. Die Dienst-IDs haben das Format:
SERVICE_NAME-<auto-generated identifier>. Die Dienst-ID ist eindeutig und bleibt für die gesamte Lebensdauer des Dienstes gleich. - In Cloud Run werden standardmäßig nur die Dienst-URLs (
SERVICE_IDENTIFIER.run.app) bereitgestellt. Um eine bestimmte Überarbeitung in den Blick zu nehmen, müssen Sie ein Traffic-Tag konfigurieren. In App Engine werden sowohl die Dienst- als auch die Versions-URL automatisch bereitgestellt.
Bereitstellung und Konfiguration
In App Engine erfolgt der Großteil der Konfiguration in der app.yaml, die in jeder Bereitstellung enthalten sind. Diese Einfachheit hat ihren Preis, der darin liegt, dass zwar einige Einstellungen über die Admin API aktualisiert werden können; die meisten Änderungen erfordern jedoch eine erneute Bereitstellung des Dienstes.
Obwohl Cloud Run die Konfigurationsdatei service.yaml hat, wird sie nicht auf dieselbe Weise wie app.yaml verwendet. Die Cloud Run-service.yaml kann beim Bereitstellen aus der Quelle nicht verwendet werden, da eines der erforderlichen Elemente der Pfad zum endgültigen Container-Image ist. Außerdem entspricht service.yaml der Knative-Spezifikation und kann für Nutzer schwierig zu lesen sein, die mit Konfigurationsdateien im Kubernetes-Stil nicht vertraut sind. Weitere Informationen zur Verwendung von service.yaml zum Verwalten der Konfiguration finden Sie in der Cloud Run-Dokumentation.
Für App Engine-Kunden, die mit Cloud Run beginnen, entspricht die Verwendung der Bereitstellungs-Flags der gcloud CLI viel eher der der App Engine-Konfigurationsverwaltung bei der Bereitstellung.
Verwenden Sie das Flag gcloud run deploy, um die Konfiguration beim Bereitstellen von neuem Code in Cloud Run festzulegen:
gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY
Es ist nicht erforderlich, die Konfigurations-Flags bei jeder Bereitstellung zu verwenden (siehe Konfigurationen verwalten). Dies ist jedoch hilfreich, um die Konfigurationsverwaltung zu vereinfachen.
In Cloud Run können Sie die Konfiguration auch mit gcloud run services update aktualisieren, ohne den Quellcode neu bereitzustellen:
gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY
Da Cloud Run-Überarbeitungen unveränderlich sind, erstellt dieser Befehl eine neue Überarbeitung mit der aktualisierten Konfiguration, verwendet jedoch dasselbe Container-Image wie die vorhandene Überarbeitung.
Konfigurationen verwalten
Bei App Engine-Bereitstellungen müssen alle Einstellungen für jede Bereitstellung angegeben werden. Allen nicht angegebenen Einstellungen werden Standardwerte zugewiesen. Nehmen wir als Beispiel die App Engine service-a, deren Versionen die unten aufgeführten app.yaml-Dateien nutzt:
| App Engine service-a version1 | App Engine service-a version2 |
|---|---|
| app.yaml | |
runtime: python39 service: service-a instance_class: F4 |
runtime: python39 service: service-a |
| Angewendete Konfiguration | |
runtime: python39 service: service-a instance_class: F4 default values: |
runtime: python39 service: service-a default values: |
version1 wird mit instance_class: F4 konfiguriert. version2 ohne Wert für instance_class wird hingegeben mit dem Standardwert instance_class: F1 konfiguriert.
Für Cloud Run werden alle Konfigurationseinstellungen angewendet. Alle nicht festgelegten Einstellungen behalten ihre vorhandenen Werte jedoch bei. Sie müssen nur Werte für Einstellungen angeben, die Sie ändern möchten. Beispiel:
| Cloud Run service-a revision1 | Cloud Run service-a revision2 |
|---|---|
| Bereitstellungsbefehl | |
gcloud run deploy service-a \ --cpu=4 |
gcloud run deploy service-a |
| Angewendete Konfiguration | |
service: service-a vCPUs: 4 default values: |
service: service-a vCPUs: 4 default values: |
In der App Engine wird bei der Bereitstellung ohne Konfigurationseinstellungen eine Version mit allen Standardeinstellungen erstellt. In Cloud Run wird bei der Bereitstellung ohne Konfigurationseinstellungen eine Überarbeitung mit denselben Konfigurationseinstellungen wie die vorherige Überarbeitung erstellt. Bei der ersten Überarbeitung eines Cloud Run-Dienstes wird bei der Bereitstellung ohne Konfigurationseinstellungen eine Überarbeitung mit allen Standardeinstellungen erstellt.
Standardeinstellungen für die Konfiguration
| Konfigurationseinstellung | App Engine-Standardumgebung | Flexible App Engine-Umgebung | Cloud Run |
|---|---|---|---|
| Ressourcen berechnen | F1 | 1 vCPU, 6 GB | 1 vCPU, 512 MB |
| Maximale Nebenläufigkeit (Anfragen) | 10 | – | 80 |
| Zeitüberschreitung bei Anfrage |
|
60 Minuten | 5 Minuten |
| CPU-Auslastungsziel | 60 % | 50 % | 60 % |
| Maximale Anzahl von Instanzen | – | 20 | 100 |
| Mindestanzahl von Instanzen | 0 | 2 | 0 |
Einstiegspunkt
Bei der Bereitstellung aus der Quelle liest App Engine den Einstiegspunktbefehl aus dem Attribut entrypoint in app.yaml. Wenn kein Einstiegspunkt angegeben ist, wird ein laufzeitspezifischer Standardwert verwendet. Cloud Run verwendet bei der Bereitstellung aus der Quelle Buildpacks von Google Cloud. Einige Sprachen haben keinen Standardeinstiegspunkt. Sie müssen daher einen angeben, oder der Build schlägt fehl. Python-Buildpacks erfordern beispielsweise entweder eine Procfile oder die Build-Umgebungsvariable GOOGLE_ENTRYPOINT.
Informationen zu sprachspezifischen Konfigurationsanforderungen finden Sie in der Buildpack-Dokumentation.
Skalierung
Während Cloud Run und die App Engine-Standardumgebung einen Großteil der Skalierungsinfrastruktur gemeinsam haben, wurde Cloud Run optimiert, um eine viel schnellere Skalierung zu ermöglichen. Im Rahmen dieser Vereinfachung sind die konfigurierbaren Einstellungen auf Folgendes beschränkt:
- Maximale Nebenläufigkeit
- Maximal- und Mindestanzahl von Instanzen
Bei Cloud Run-Instanzen ist die Ziel-CPU-Auslastung nicht konfigurierbar und beträgt 60 %. Weitere Informationen zum Autoscaling finden Sie in der Cloud Run-Dokumentation.
In der flexiblen App Engine-Umgebung wird der Autoscaler von Compute Engine verwendet. Sie unterscheidet sich daher deutlich von den Skalierungsmerkmalen sowohl von der App Engine-Standardumgebung als auch von Cloud Run.
Zeitüberschreitung für inaktive Instanzen
In App Engine sind inaktive Instanzen bis zu 15 Minuten nach Abschluss der letzten Anfrage aktiv. In Cloud Run können Sie dieses Verhalten mithilfe der CPU-Zuweisung konfigurieren. Legen Sie die CPU-Zuweisung auf CPU wird immer zugewiesen fest, um dasselbe Verhalten wie bei App Engine zu erzielen. Verwenden Sie alternativ CPU nur während der Anfrageverarbeitung zugewiesen, um inaktive Instanzen sofort zu beenden (wenn keine ausstehenden Anfragen vorhanden sind).
Aufwärmanfragen
Cloud Run wärmt Instanzen automatisch mithilfe des Befehls des Containereinstiegspunkts auf. Sie müssen also weder Aufwärmanfragen manuell aktivieren noch einen /_ah/warmup-Handler konfigurieren. Wenn Sie Code haben, den Sie beim Start der Instanz ausführen möchten, bevor Anfragen verarbeitet werden, haben Sie folgende Möglichkeiten:
Statischer Inhalt
In der App Engine-Standardumgebung können Sie statische Inhalte bereitstellen, ohne Rechenressourcen zu verwenden, indem Sie Cloud Storage bereitstellen oder Handler konfigurieren. Cloud Run bietet keine Handler-Option zum Bereitstellen statischer Inhalte. Deshalb können Sie entweder den Inhalt aus dem Cloud Run-Dienst (wie den dynamischen Inhalt) oder aus Cloud Storage bereitstellen.
Rolle „Cloud Run-Aufrufer“
Cloud Run bietet auch die Möglichkeit, den Zugriff auf einen Dienst mit Identity and Access Management (IAM) zu steuern. Die IAM-Richtlinienbindungen für einen Dienst können mit der gcloud CLI, der Console oder Terraform festgelegt werden.
Zum Replizieren des App Engine-Verhaltens können Sie den Dienst öffentlich machen, indem Sie nicht authentifizierte Anfragen zulassen. Dies kann bei der Bereitstellung oder durch Aktualisieren der IAM-Richtlinienbindungen für einen vorhandenen Dienst festgelegt werden.
Bereitstellung
Verwenden Sie das Bereitstellungsflag --allow-unauthenticated:
gcloud run deploy SERVICE_NAME ... --allow-unauthenticated
Vorhandener Dienst
Führen Sie den Befehl gcloud run services add-iam-policy-binding aus:
gcloud run services add-iam-policy-binding SERVICE_NAME \ --member="allUsers" \ --role="roles/run.invoker"
Dabei ist SERVICE_NAME der Name des Cloud Run-Dienstes.
Alternativ können Sie den Zugriff auf den Dienst steuern. Weisen Sie dazu die IAM-Rolle Cloud Run Invoker zu, die pro Dienst konfigurierbar ist.
Bereitstellung
gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated gcloud run services add-iam-policy-binding SERVICE_NAME \ --member=MEMBER_TYPE \ --role="roles/run.invoker"
Dabei ist SERVICE_NAME der Dienstname und MEMBER_TYPE der Hauptkontotyp. Beispiel: user:email@domain.com
Eine Liste der zulässigen Werte für MEMBER_TYPE finden Sie auf der Seite für IAM-Konzepte.
Vorhandener Dienst
gcloud run services add-iam-policy-binding SERVICE_NAME \ --member=MEMBER_TYPE \ --role="roles/run.invoker"
Dabei ist SERVICE_NAME der Dienstname und MEMBER_TYPE der Hauptkontotyp. Beispiel: user:email@domain.com
Eine Liste der zulässigen Werte für MEMBER_TYPE finden Sie auf der Seite für IAM-Konzepte.
Umgebungsvariablen und Metadaten
Sowohl die App Engine als auch Cloud Run haben bestimmte Umgebungsvariablen, die automatisch festgelegt werden. In der folgenden Tabelle sind die App Engine-Umgebungsvariablen zusammen mit ihren Cloud Run-Entsprechungen aufgeführt. Cloud Run implementiert im Vergleich zu App Engine nur wenige Umgebungsvariablen. Die vom Metadatenserver verfügbaren Daten sind jedoch weitgehend gleichwertig.
Standardumgebungsvariablen
| App Engine-Name | Cloud Run-Name | Beschreibung |
|---|---|---|
GAE_SERVICE
|
K_SERVICE
|
Der Name des aktuellen Dienstes. Für App Engine ist dies auf „Standard“ gesetzt, wenn keine Angabe erfolgt. |
GAE_VERSION
|
K_REVISION
|
Aktuelle Versionsbezeichnung Ihres Dienstes. |
PORT
|
PORT
|
Port, der HTTP-Anfragen empfängt. |
| – | K_CONFIGURATION
|
Der Name der Cloud Run-Konfiguration, mit der die Überarbeitung erstellt wurde. |
GOOGLE_CLOUD_PROJECT
|
– | Cloud-Projekt-ID, die der Anwendung zugeordnet ist. |
GAE_APPLICATION
|
ID der App Engine-Anwendung. Diese ID hat das Präfix „Regionscode~“, z. B. „e~“ für Anwendungen, die in Europa bereitgestellt werden. | |
GAE_DEPLOYMENT_ID
|
ID der aktuellen Bereitstellung. | |
GAE_ENV
|
App Engine-Umgebung. Legen Sie „Standard“ fest, wenn Sie diese in der Standardumgebung verwenden. | |
GAE_INSTANCE
|
ID der Instanz, auf der Ihr Dienst gerade ausgeführt wird. | |
GAE_MEMORY_MB
|
Größe des für den Anwendungsprozess verfügbaren Speichers in MB. | |
NODE_ENV (nur in der Node.js-Laufzeit verfügbar)
|
Erhält den Wert „Production“, wenn der Dienst bereitgestellt wird. | |
GAE_RUNTIME
|
Laufzeit, die in der Datei app.yaml angegeben ist. |
Gängige Pfade für Metadatenserver
| Pfad | Beschreibung | Beispiel |
|---|---|---|
/computeMetadata/v1/project/project-id
|
Projekt-ID des Projekts, zu dem der Dienst gehört | test_project |
/computeMetadata/v1/project/numeric-project-id
|
Projektnummer des Projekts, zu dem der Dienst gehört | 12345678912 |
/computeMetadata/v1/instance/id
|
Eindeutige Kennung der Containerinstanz (auch in Logs verfügbar). | 16a61494692b7432806a16
(String aus alphanumerischen Zeichen) |
/computeMetadata/v1/instance/region
** Nicht für die flexible App Engine-Umgebung verfügbar |
Region dieses Dienstes, gibt projects/PROJECT_NUMBER/regions/REGION zurück
|
projects/12345678912/regions/us-central1 |
/computeMetadata/v1/instance/service-accounts/default/email
|
E-Mail-Adresse für das Laufzeitdienstkonto dieses Dienstes. | service_account@test_project.iam.gserviceaccount.com |
/computeMetadata/v1/instance/service-accounts/default/token
|
Generiert ein OAuth2-Zugriffstoken für das Dienstkonto dieses Dienstes. Dieser Endpunkt gibt eine JSON-Antwort mit einem access_token-Attribut zurück.
|
{ "access_token":"<TOKEN>", "expires_in":1799, "token_type":"Bearer" } |
Nächste Schritte
- Kurzanleitung: Webdienst mit Cloud Run bereitstellen
- Ist meine Anwendung für Cloud Run geeignet?
- Benutzerdefinierte App Engine-Domain zu Cloud Load Balancing migrieren
- Andere Ressourcen: