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 Gemeinsamkeiten 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
Version/Ü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 Ja
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 für die Abrechnung. Verwenden Sie die instanzbasierte Abrechnung, 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
Sidecar-Container Nein Ja. Sidecars werden neben dem Hauptcontainer ausgeführt und verarbeiten Webanfragen.
Systemdiagnosen Automatisch. App Engine führt Bereitschafts- und Aktivitätsprüfungen für Ihre Instanzen durch. Konfigurierbar: Sie definieren Start-up- und Aktivitätsprüfungen explizit in der Konfiguration Ihrer Cloud Run-Ressource und geben Details wie den Prüfungstyp (TCP, HTTP und gRPC), den Pfad, den Port, die anfängliche Verzögerung, den Zeitraum, das Zeitlimit, den Erfolgsschwellenwert und den Fehlerschwellenwert an.

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
GPUs Nein Ja. Sie können eine GPU pro Cloud Run-Instanz konfigurieren.
Volume-Bereitstellungen Nein Ja. Sie können einen Cloud Storage-Bucket direkt im Dateisystem des Containers bereitstellen.

Preismodell
Gebühr pro Anfrage Nein Nein, wenn Sie die instanzbasierte Abrechnung verwenden.
Ja, wenn Sie die anfragebasierte Abrechnung verwenden.
Mindestanzahl inaktiver Instanzen Gleiche Kosten wie bei aktiven Instanzen Niedrigere Kosten für Mindestanzahl inaktiver Instanzen (siehe abrechenbare Containerinstanzzeit)
Rabatte für zugesicherte Nutzung (CUD) Nein Ja
Instanzbasierte Abrechnung (Instanz mit Kosten pro Stunde) F4/B4-Instanz: 0,20 $
  • vCPU: 0,0526 $
  • Arbeitsspeicher: 0,0071 $
    		•
    • vCPU: 0,0648 $
    • Arbeitsspeicher: 0,0072 $

    Sicherheit
    Einstellungen für eingehenden Traffic Ja Ja Ja
    Rolle „Aufrufer“ Nein Ja
    IAP Ja Ja Ja
    Firewalls Ja Ja Mit Google Cloud Armor konfigurieren
    Secret Manager Ja, mit Cloud-Clientbibliotheken. Ja. Sie können jedes Secret als Volume bereitstellen oder ein Secret mithilfe von Umgebungsvariablen übergeben.

    Verbindung
    Benutzerdefinierte Domains Ja Ja Ja
    VPC-Konnektivität (einschließlich freigegebene VPC) Ja – Ja
    Einstellungen für ausgehenden VPC-Traffic Ja – Ja
    Multiregionales Load-Balancing Nein Ja
    Server-Streaming 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

    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 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 App Engine werden sowohl die Dienst- als auch die Versions-URLs 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 aktualisieren, ohne den Quellcode mit gcloud run services update 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 app.yaml-Dateien in der folgenden Tabelle 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 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

    Wenn Sie aus der Quelle bereitstellen, liest App Engine den Entrypoint-Befehl aus dem Attribut entrypoint in der 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.

    In der Buildpacks-Dokumentation finden Sie sprachspezifische Konfigurationsanforderungen.

    Systemdiagnosen

    In App Engine sind Systemdiagnosen weitgehend automatisch und werden von der Plattform verwaltet. App Engine führt sowohl Aktivitäts- als auch Bereitschaftsprüfungen durch, um festzustellen, ob eine Instanz betriebsbereit ist und Traffic verarbeiten kann. Wenn bei einer Instanz wiederholt Fehler bei den automatischen Prüfungen auftreten, beendet App Engine die Instanz und ersetzt sie durch eine neue Instanz, um die Kontinuität des Dienstes zu gewährleisten.

    Cloud Run bietet eine genauere Steuerung mit konfigurierbaren Start- und Aktivitätsprüfungen. Mit diesen Tests können Sie eine fehlerfreie Instanz definieren, was für komplexe Microservices entscheidend ist.

    In Cloud Run können Sie die folgenden Prüfungen konfigurieren:

    • Startprüfung, um zu definieren, wann ein Container gestartet wurde und bereit ist, Traffic zu verarbeiten. Wenn Sie eine Startprüfung konfigurieren, werden Aktivitätsprüfungen deaktiviert, bis der Start erfolgreich ist. So wird sichergestellt, dass die Aktivitätsprüfungen den Start Ihrer Anwendung nicht beeinträchtigen.

    • Aktivitätsprüfung, um festzustellen, wann ein Container neu gestartet werden muss. Aktivitätsprüfungen können beispielsweise eine Systemsperre erkennen, wenn eine Anwendung ausgeführt wird, aber keine Fortschritte machen kann. Durch einen Neustart eines Containers in einem solchen Zustand wird dafür gesorgt, dass Ihre Anwendung trotz Fehlern verfügbar ist.

    Weitere Informationen finden Sie unter Systemdiagnosen für Container für Dienste konfigurieren.

    Skalierung

    Cloud Run und die App Engine-Standardumgebung haben eine ähnliche Skalierungsinfrastruktur, aber Cloud Run ist für eine schnellere Skalierung und die Möglichkeit zur Skalierung auf null optimiert. Das führt zu weniger konfigurierbaren Einstellungen. Durch diese Optimierung werden die konfigurierbaren Einstellungen auf Folgendes beschränkt:

    Bei Cloud Run-Instanzen ist die Ziel-CPU-Auslastung nicht konfigurierbar und beträgt 60%. Weitere Informationen finden Sie unter Autoscaling von Instanzen in Cloud Run-Diensten.

    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.

    Skalierungssteuerungen von App Engine zu Cloud Run migrieren

    In diesem Abschnitt wird beschrieben, wie Sie Ihre vorhandene App Engine-Skalierungskonfiguration Cloud Run zuordnen.

    Mindestanzahl von Instanzen (Warm-up)

    Halten Sie eine Mindestanzahl von Instanzen einsatzbereit, um den Baseline-Traffic zu verarbeiten und Kaltstarts zu vermeiden.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung min_instances: N
    Flexible App Engine-Umgebung automatic_scaling:
      min_num_instances: N
    Cloud Run Service-Level: scaling.min_instance_count: N
    Revisions-Level: template.scaling.min_instance_count: N

    Migrationsstrategie: Legen Sie die Mindestanzahl von Instanzen für das Warm-up auf Dienstebene fest. Wenn Sie Traffic an eine bestimmte Überarbeitung weiterleiten, wird die Standardeinstellung auf Dienstebene durch die Einstellung auf Überarbeitungsebene überschrieben. Mit dieser Einstellung können Sie eine neue Revision mit einer anderen Mindestanzahl von Instanzen testen, bevor Sie sie in die Produktion übertragen.

    Maximale Anzahl von Instanzen

    Legen Sie ein festes Limit für die Gesamtzahl der Instanzen fest, um die Kosten zu kontrollieren und nachgelagerte Abhängigkeiten zu schützen.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung max_instances: N
    Flexible App Engine-Umgebung automatic_scaling:
      max_num_instances: N
    Cloud Run Service-Level: scaling.max_instance_count: N
    Revisions-Level: template.scaling.max_instance_count: N

    Migrationsstrategie: Legen Sie ein globales Limit auf Dienstebene fest. In Cloud Run werden die Einstellungen auf Dienstebene und auf Überarbeitungsebene erzwungen, wobei die niedrigere Einstellung gilt. Weitere Informationen finden Sie unter Maximale Anzahl von Instanzen für Dienste festlegen.

    Gleichzeitigkeit

    Definieren Sie die Anfragekapazität einer einzelnen Instanz.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung max_concurrent_requests: N
    Flexible App Engine-Umgebung automatic_scaling:
      target_concurrent_requests: N
    Cloud Run template.maxInstanceRequestConcurrency: N

    Migrationsstrategie: Sie haben zwei Migrationsstrategien zur Auswahl:

    • Beginnen Sie mit der Standardkapazität von 80 für Cloud Run-Instanzen und führen Sie Lasttests durch, um das stabile Nebenläufigkeitslimit für Ihre Anwendung in Cloud Run zu ermitteln. Das Anpassen dieses Werts ist eine effektive Methode, um Leistung und Kosten in Cloud Run zu optimieren. Passen Sie den Wert anhand Ihrer Testergebnisse nach unten an. Weitere Informationen finden Sie unter Maximale Anzahl gleichzeitiger Anfragen pro Instanz festlegen.

    • Verwenden Sie den vorhandenen Konfigurationswert in der App Engine-Standardumgebung. Standardmäßig sind das 10 gleichzeitige Anfragen pro Instanz. Dies ist eine sichere Option, da es sich um eine bekannte, funktionierende Konfiguration für Ihre Anwendung handelt. Dies kann jedoch zu einer erheblichen Unterauslastung Ihrer Cloud Run-Instanzen und möglicherweise zu höheren Kosten führen, da der Autoscaler mehr Instanzen erstellt, als zur Verarbeitung der Last erforderlich sind.

    CPU-Auslastung

    Skalieren, wenn die CPU-Auslastung einen bestimmten Grenzwert überschreitet.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung target_cpu_utilization: 0.X
    Flexible App Engine-Umgebung automatic_scaling:
      cpu_utilization:
      target_utilization: N
    Cloud Run Kein direktes Äquivalent (festgelegt auf ca. 60%)

    Migrationsstrategie: Dieser Wert kann nicht konfiguriert werden. Der Autoscaler von Cloud Run sorgt für eine CPU-Auslastung von etwa 60% auf aktiven Instanzen. Im Gegensatz zu App Engine weist Cloud Run nur während der Anfrageverarbeitung CPU zu und drosselt sie ansonsten auf null. In der App Engine-Standardumgebung sorgt App Engine unabhängig vom konfigurierten Skalierungstyp dafür, dass für Ihre Instanz kontinuierlich CPU verfügbar ist.

    Wenn Ihre Anwendung zwischen Anfragen Hintergrundaufgaben ausführt, z. B. Hintergrundthreads bei der einfachen oder manuellen Skalierung verwendet, konfigurieren Sie die instanzbasierte Abrechnung in Cloud Run, um das Anhalten Ihrer Hintergrundverarbeitungsaufgaben zu vermeiden.

    Anfragedurchsatz

    Skalieren Sie basierend auf dem Anfragedurchsatz, wenn Ihre Anwendung das Limit für Nebenläufigkeit erreicht.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung target_throughput_utilization: 0.X
    Flexible App Engine-Umgebung Nicht verfügbar
    Cloud Run Einstellung template.maxInstanceRequestConcurrency anpassen

    Migrationsstrategie: Der Cloud Run-Autoscaler versucht, die Anzahl der gleichzeitigen Anfragen pro Instanz bei 60% des maxInstanceRequestConcurrency-Werts zu halten. Wenn Sie diesen Wert festlegen, definieren Sie implizit den Ziel-Durchsatz, der ein Scale-up-Ereignis auslöst.

    Latenz

    Definieren Sie ein Zeitfenster für die Wartezeit von Nutzern, das die Skalierung auslöst. App Engine reagiert teilweise auf das Einreihen von Anfragen in die Warteschlange.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung min_pending_latency und max_pending_latency
    Flexible App Engine-Umgebung Nicht verfügbar
    Cloud Run Keine direkte Entsprechung

    Migrationsstrategie: Cloud Run wird automatisch skaliert, bevor Anfragen in die Warteschlange gestellt werden und die Latenz ansteigt. Wenn Latenzspitzen auftreten, sollten Sie den Wert für template.maxInstanceRequestConcurrency anpassen, um eine schnellere horizontale Skalierung zu ermöglichen.

    Inaktive Instanzen

    Intention:In App Engine steuern die Einstellungen für inaktive Instanzen einen Pool von vorab aufgewärmten, inaktiven Instanzen, die Trafficspitzen abfangen und Kosten kontrollieren.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung min_idle_instances: N
    oder
    max_idle_instances: N
    Flexible App Engine-Umgebung Nicht verfügbar
    Cloud Run Keine direkte Entsprechung

    Migrationsstrategie: Sie können in Cloud Run keine separate Mindest- oder Höchstanzahl von Leerlaufinstanzen konfigurieren. Um Instanzen einsatzbereit zu halten und Kaltstarts in Cloud Run zu vermeiden, verwenden Sie die Einstellung scaling.min_instance_count. Dadurch wird dafür gesorgt, dass immer eine bestimmte Mindestanzahl von Containern ausgeführt wird. Weitere Informationen finden Sie unter Instanz-Autoscaling in Cloud Run-Diensten.

    Zeitüberschreitung für inaktive Instanzen

    In App Engine sind inaktive Instanzen etwa 15 Minuten nach der letzten Anfrage aktiv. Cloud Run steuert dieses Verhalten über die Abrechnungseinstellung.

    Um ein ähnliches Abrechnungsverhalten wie bei App Engine zu erzielen, bei dem die CPU außerhalb der Verarbeitung von Anfragen zugewiesen wird, verwenden Sie in Cloud Run die instanzbasierte Abrechnung.

    Alternativ können Sie die anfragebasierte Abrechnung verwenden, damit die CPU nur während der Anfrageverarbeitung zugewiesen wird. Bei dieser Einstellung bleibt die Instanz nach der letzten Anfrage bis zu 15 Minuten lang aktiv, die CPU wird jedoch während dieser Inaktivitätszeit gedrosselt.

    Einfache Skalierung

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung basic_scaling: max_instances: N
    Flexible App Engine-Umgebung Nicht verfügbar
    Cloud Run Standardmäßig wird die automatische Skalierung verwendet.
    scaling.min_instance_count: 0
    scaling.max_instance_count: N

    Wenn Sie die Einstellung basic_scaling in der App Engine-Standardumgebung konfigurieren, werden Instanzen erstellt, wenn Anfragen eingehen, und nach einer gewissen Zeit der Inaktivität wird auf null skaliert. Sie können dieses Verhalten in Cloud Run mit automatischem Skalieren replizieren, indem Sie min-instances auf 0 festlegen.

    Manuelle Skalierung

    Führen Sie eine feste Anzahl von Instanzen aus und deaktivieren Sie Autoscaling.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung manual_scaling: instances: N
    Flexible App Engine-Umgebung manual_scaling: instances: N
    Cloud Run scalingMode: MANUAL
      manualInstanceCount: N

    Migrationsstrategie: In Cloud Run gibt es eine direkte Zuordnung für die manuelle Skalierung. Legen Sie den Skalierungsmodus auf Dienstebene in Cloud Run auf MANUAL fest und geben Sie die genaue Anzahl der auszuführenden Instanzen mit manualInstanceCount an. Das hat denselben Effekt wie das vollständige Deaktivieren der automatischen Skalierung. Weitere Informationen finden Sie unter Manuelle Skalierung in Cloud Run.

    Wartezeit

    Konfigurieren Sie eine Wartezeit nach einem Hochskalierungsereignis, bevor ein weiteres Ereignis eintritt.

    Konfigurationsumgebung Einstellungen
    App Engine-Standardumgebung Nicht verfügbar
    Flexible App Engine-Umgebung automatic_scaling:
      cool_down_period_sec: N
    Cloud Run Keine direkte Entsprechung

    Migrationsstrategie: Nicht erforderlich. Cloud Run skaliert automatisch basierend auf Bedarf und Nutzung und ist so konzipiert, dass es effizient reagiert, ohne dass ein manueller Zeitraum für das Herunterfahren konfiguriert werden muss.

    Aufwärmanfragen

    Cloud Run wärmt Instanzen automatisch mit dem Befehl für den Containereinstiegspunkt auf. Sie müssen also keine Warm-up-Anfragen 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 unter Hauptkonto-IDs.

    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 unter Hauptkonto-IDs.

    Umgebungsvariablen und Metadaten

    Sowohl 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. In Cloud Run werden im Vergleich zu App Engine nur wenige Umgebungsvariablen implementiert, die vom Metadatenserver verfügbaren Daten sind jedoch größtenteils identisch.

    Standardumgebungsvariablen

    App Engine-Name {[cloud_run_name]} 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 – Die Google Cloud Projekt-ID, die Ihrer 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 Die ID der Instanz, auf der Ihr Dienst 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
    (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