App Engine und Cloud Run im Vergleich

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.

Hier finden Sie weitere Informationen zu Regions-IDs.

Dieser Leitfaden bietet eine Einführung in Cloud Run für Nutzer, 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. Daher gibt es viele Ähnlichkeiten zwischen diesen beiden Plattformen.

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_NAME-PROJECT_NUMBER.REGION.run.app
  • https://SERVICE_IDENTIFIER.run.app
Versions-/Überarbeitungs-URL https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://TAG---SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • 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
  • Autoscaling: 10 Minuten
  • Manuelle/einfache Skalierung: 24 Stunden
 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
Instanzklasse vCPU* Arbeitsspeicher
F/B1 .25 384 MB
F/B2 0,5 768 MB
F/B4 1 1,5 GB
F/B4_1G 1 3 GB
B8 2 3 GB
* vCPU-Entsprechungen sind ungefähre Angaben 		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 freigegebene 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 der 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

App Engine- und Cloud Run-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, wobei REVISION_SUFFIX entweder automatisch generiert oder mit dem Bereitstellungs-Flag --revision-suffix=REVISION_SUFFIX festgelegt 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 und https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app) bereitgestellt. Um eine bestimmte Überarbeitung in den Blick zu nehmen, müssen Sie ein Traffic-Tag konfigurieren. In der App Engine werden sowohl die Dienst- als auch die Versions-URLs automatisch freigegeben.

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:
instance_class: F1
..
..

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
  • Autoscaling: 10 Minuten
  • Manuelle/einfache Skalierung: 24 Stunden
 60 Minuten 5 Minuten
CPU-Auslastungsziel 60 % 50 % 60 %
Maximale Anzahl von Instanzen – 20 100
Mindestanzahl von Instanzen 0 2 0

Einstiegspunkt

Beim Bereitstellen aus der Quelle liest App Engine den Befehl „entrypoint“ aus dem entrypoint-Attribut in der app.yaml. Wenn kein Einstiegspunkt angegeben ist, wird ein laufzeitspezifischer Standard 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:

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 führt das Vorwärmen von Instanzen automatisch mit dem Befehl für den Container-Eintgangspunkt durch. Sie müssen also keine Vorwärmanfragen manuell aktivieren oder 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. Im Vergleich zur App Engine werden in Cloud Run nur wenige Umgebungsvariablen implementiert. Die vom Metadatenserver verfügbaren Daten sind jedoch weitgehend identisch.

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 Metadatenserverpfade

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
(alphanumerischer String)
/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