Was ist Cloud Run?

Cloud Run ist eine vollständig verwaltete Anwendungsplattform, auf der Sie Ihren Code, Ihre Funktion oder Ihren Container auf der hoch skalierbaren Infrastruktur von Google ausführen können.

Sie können in Cloud Run geschriebenen Code bereitstellen, wenn Sie ein Container-Image daraus erstellen können. Das Erstellen von Container-Images ist optional. Wenn Sie Go, Node.js, Python, Java, .NET, Ruby oder ein unterstütztes Framework verwenden, können Sie die Option Quellbasiertes Deployment verwenden, die den Container für Sie erstellt. Beachten Sie dabei die Best Practices für die von Ihnen verwendete Sprache.

Google Cloud Run wurde für die Zusammenarbeit mit anderen Diensten in Google Cloud Google Cloudentwickelt, sodass Sie Anwendungen mit vollem Funktionsumfang erstellen können.

Kurz gesagt: Mit Cloud Run können Entwickler ihre Zeit in die Entwicklung von Code investieren und sehr wenig Zeit mit dem Bearbeiten, Konfigurieren und Skalieren ihres Cloud Run-Dienstes verbringen. Sie müssen keinen Cluster erstellen oder die Infrastruktur verwalten, um mit Cloud Run produktiv zu sein.

Dienste, Jobs, Worker-Pools und Instanzen: vier Möglichkeiten zum Ausführen von Code

In Cloud Run kann Ihr Code als Dienst, Job, Worker-Pool, oder Instanz. Alle diese Ressourcentypen führen Containerinstanzen in einer Sandbox in derselben Ausführungsumgebung aus und können in Google Cloud Dienste eingebunden werden.

Entscheiden Sie, welche Cloud Run-Option für Ihre Arbeitslast geeignet ist.
Entscheiden Sie, welche Cloud Run-Ressource für Ihre Arbeitslast geeignet ist.

Die folgende Tabelle bietet einen allgemeinen Überblick über die Optionen, die von den einzelnen Cloud Run-Ressourcentypen bereitgestellt werden.

Ressource Beschreibung
Dienst Reagiert auf HTTP-Anfragen, die an einen eindeutigen und stabilen Endpunkt gesendet werden, und verwendet zustandslose Containerinstanzen, die sowohl dynamisches Autoscaling als auch manuelle Skalierung unterstützen. Reagiert auch auf Ereignisse und Funktionen.
Job Führt parallelisierbare Aufgaben aus, die manuell oder nach einem Zeitplan ausgeführt werden und bis zum Abschluss laufen.
Worker-Pool Verarbeitet ständig aktive Hintergrundarbeitslasten wie Arbeitslasten aus Nachrichtenwarteschlangen (Kafka, Pub/Sub, RabbitMQ).
Instanz Führt Arbeitslasten mit langer Ausführungszeit aus, die eine Singleton-Laufzeitumgebung erfordern.

Cloud Run-Dienste

Ein Cloud Run-Dienst bietet die Infrastruktur, die zum Ausführen eines zuverlässigen HTTPS-Endpunkts erforderlich ist. Wenn Sie diesen Dienst verwenden möchten, muss Ihr Code einen TCP-Port überwachen und eingehende HTTP-Anfragen verarbeiten.

Das folgende Diagramm zeigt, wie ein Cloud Run-Dienst mehrere Containerinstanzen ausführt, um Webanfragen und Ereignisse von einem Client zu verarbeiten:

Ein Cloud Run-Dienst führt Container aus, um Webanfragen und -ereignisse zu verarbeiten

Ein Standarddienst umfasst die folgenden Funktionen:

Eindeutiger HTTPS-Endpunkt für jeden Dienst
Jeder Cloud Run-Dienst hat einen HTTPS-Endpunkt in einer eindeutigen Subdomain der Domain *.run.app. Sie können auch benutzerdefinierte Domains konfigurieren. Cloud Run verwaltet TLS für Sie und unterstützt WebSockets, HTTP/2 (End-to-End) und gRPC (End-to-End).
Schnelle anfragebasierte automatische Skalierung
Cloud Run skaliert schnell, um alle eingehenden Anfragen zu verarbeiten oder um eine erhöhte CPU-Auslastung außerhalb von Anfragen zu bewältigen, wenn die Abrechnungseinstellung auf instanzbasierte Abrechnung festgelegt ist. Ein Dienst kann schnell auf bis zu 1.000 Instanzen horizontal skaliert werden – oder sogar mehr, wenn Sie eine Kontingenterhöhung anfordern. Wenn die Nachfrage sinkt, entfernt Cloud Run inaktive Container. Wenn Sie Bedenken hinsichtlich der Kosten oder Überlastung nachgelagerter Systeme haben, können Sie die maximale Anzahl von Instanzen begrenzen.
Optionale manuelle Skalierung
Standardmäßig skaliert Cloud Run automatisch auf mehr Instanzen, um mehr Traffic zu verarbeiten. Sie können dieses Verhalten jedoch überschreiben, indem Sie die manuelle Skalierung verwenden, um das Skalierungsverhalten zu steuern.
Integrierte Trafficverwaltung

Um das Risiko bei der Bereitstellung einer neuen Überarbeitung zu verringern, unterstützt Cloud Run einen schrittweisen Rollout. Dazu gehört das Weiterleiten von eingehendem Traffic an die neueste Überarbeitung, das Ausführen eines Rollbacks zu einer vorherigen Überarbeitung und das gleichzeitige Aufteilen des Traffics auf mehrere Überarbeitungen.

Sie können beispielsweise mit dem Senden von 1% der Anfragen an eine neue Version beginnen und diesen Prozentsatz beim Monitoring von Telemetrie erhöhen.

Öffentliche und private Dienste

Ein Cloud Run-Dienst kann über das Internet erreichbar sein. Alternativ haben Sie folgende Möglichkeiten, den Zugriff einzuschränken:

Sie können cachefähige Assets von einem Edge-Standort in der Nähe der Clients bereitstellen, indem Sie einen Cloud Run-Dienst mit einem Content Delivery Network (CDN) wie Firebase Hosting und Cloud CDN nutzen.

Auf null und minimale Instanzen skalieren

Wenn die Abrechnung standardmäßig auf instanzbasierte Abrechnung festgelegt ist, fügt Cloud Run automatisch Instanzen hinzu und entfernt sie, um alle eingehenden Anfragen zu verarbeiten oder um eine erhöhte CPU-Auslastung außerhalb von Anfragen zu bewältigen.

Auf null skalieren

Wenn keine eingehenden Anfragen an Ihren Dienst vorhanden sind, wird auch die letzte verbleibende Instanz entfernt. Dieses Verhalten wird allgemein als Skalierung auf null bezeichnet.

Wenn eine neue Anfrage für einen Dienst ohne aktive Instanzen eingeht, erstellt Cloud Run eine neue Instanz. Dieser Vorgang kann die Antwortzeit für diese ersten Anfragen verlängern, je nachdem, wie schnell Ihr Container bereit ist, Traffic zu verarbeiten.

Skalierungsverhalten ändern

Sie können dieses Standardverhalten mit einer der folgenden Methoden ändern:

  • Mindestanzahl von Instanzen: Konfigurieren Sie Cloud Run so, dass eine Mindestanzahl von Instanzen aktiv bleibt, so dass Ihr Dienst nicht auf null skaliert wird.
  • Manuelle Skalierung: Mit der manuellen Skalierung haben Sie mehr Kontrolle über das Skalierungsverhalten Ihres Dienstes.

Nutzungsbasierte Abrechnung für Dienste

Die Skalierung auf null ist aus wirtschaftlichen Gründen attraktiv, da Ihnen die CPU und der Speicher, die einer Instanz zugewiesen werden, mit einer Genauigkeit von 100 ms in Rechnung gestellt werden. Wenn Sie keine Mindestinstanzen konfigurieren, werden Ihnen keine Kosten in Rechnung gestellt, wenn Ihr Dienst nicht verwendet wird. Es gibt eine großzügige kostenlose Stufe. Weitere Informationen finden Sie unter Preise.

Sie können zwei Abrechnungseinstellungen aktivieren:

Anfragebasiert
Wenn eine Instanz keine Anfragen verarbeitet, werden Ihnen keine Kosten in Rechnung gestellt. Sie zahlen eine Gebühr pro Anfrage.
Instanzbasiert
Die Kosten werden Ihnen für die gesamte Lebensdauer einer Instanz in Rechnung gestellt. Es fallen keine Gebühren pro Anfrage an.

Es gibt eine großzügige kostenlose Stufe. Weitere Informationen finden Sie unter Preise. Unter Abrechnungseinstellungen finden Sie Informationen zum Aktivieren anfrage- oder instanzbasierter Abrechnung für Ihren Dienst.

Ein entfernbares Container-Dateisystem

Instanzen in Cloud Run können entfernt werden. Jeder Container hat ein speicherinternes, beschreibbares Dateisystem-Overlay, das nicht beibehalten wird, wenn der Container heruntergefahren wird. Cloud Run entscheidet, wann die Übermittlung von Anfragen an eine Instanz beendet und diese heruntergefahren wird, z. B. beim Herunterskalieren.

Um eine Warnung zu erhalten, wenn Cloud Run eine Instanz herunterfährt, kann Ihre Anwendung das SIGTERM-Signal prüfen. Dadurch kann Ihr Code lokale Puffer leeren und lokale Daten in einem externen Datenspeicher speichern.

Zur dauerhaften Speicherung von Dateien können Sie Cloud Storage einbinden oder ein Netzwerkdateisystem (NFS) bereitstellen.

Wann werden Cloud Run-Dienste verwendet?

Cloud Run-Dienste eignen sich hervorragend für Code, der Anfragen, Ereignisse oder Funktionen verarbeitet. Beispiel-Anwendungsfälle umfassen Folgendes:

Websites und Webanwendungen
Erstellen Sie Ihre Webanwendung mit Ihrem bevorzugten Stack, greifen Sie auf Ihre SQL-Datenbank zu und rendern Sie dynamische HTML-Seiten.
APIs und Mikrodienste
Sie können eine REST API, eine GraphQL API oder private Mikrodienste erstellen, die über HTTP oder gRPC kommunizieren.
Streamingdatenverarbeitung
Cloud Run-Dienste können Nachrichten von Pub/Sub-Push-Abos und Ereignisse von Eventarc empfangen.
Asynchrone Arbeitslasten
Cloud Run Functions können auf asynchrone Ereignisse reagieren, z. B. eine Nachricht zu einem Pub/Sub-Thema, eine Änderung in einem Cloud Storage-Bucket oder ein Firebase-Ereignis.
KI-Inferenz
Cloud Run-Dienste mit oder ohne konfigurierte GPU können KI-Arbeitslasten wie Inferenzmodelle und Modelltraining hosten.

Cloud Run-Jobs

Wenn Ihr Code funktioniert und dann beendet wird, z. B. mit einem Skript, können Sie Ihren Cloud Run-Job verwenden, um Ihren Code auszuführen. Sie können einen Job über die Befehlszeile mit der Google Cloud CLI ausführen, indem Sie einen wiederkehrenden Job planen, oder indem Sie ihn als Teil eines Workflows ausführen.

Array-Jobs lassen sich schneller ausführen

Ein Job kann eine einzelne Instanz starten, um Ihren Code auszuführen. Dies ist eine gängige Methode zum Ausführen eines Skripts oder Tools.

Sie können jedoch auch einen Array-Job verwenden, um viele identische, unabhängige Instanzen parallel zu starten. Array-Jobs können schneller verarbeitet werden, die in mehrere unabhängige Aufgaben aufgeteilt werden können.

Das folgende Diagramm zeigt, dass ein Job mit sieben Aufgaben sequenziell länger dauert als derselbe Job, wenn vier Instanzen unabhängige Aufgaben parallel verarbeiten können:

Array-Jobs führen schneller parallele Jobs aus

Wenn Sie beispielsweise 1.000 Bilder aus Cloud Storage zuschneiden und ihre Größe ändern, ist deren aufeinanderfolgende Verarbeitung langsamer als die gleichzeitige Verarbeitung bei vielen Instanzen, die Cloud Run mithilfe des automatischen Skalierens verwaltet.

Wann werden Cloud Run-Jobs verwendet?

Cloud Run-Jobs eignen sich gut zum Ausführen von Code, der Arbeit (einen Job) ausführt und nach Abschluss der Arbeit beendet wird. Hier einige Beispiele:

Skript oder Tool
Führen Sie ein Skript aus, um Datenbankmigrationen oder andere operative Aufgaben auszuführen.
Array-Job
In einem Cloud Storage-Bucket alle Dateien parallelisieren.
Geplanter job
In regelmäßigen Abständen Rechnungen erstellen und senden oder die Ergebnisse einer Datenbankabfrage als XML speichern und die Datei alle paar Stunden hochladen.
KI-Arbeitslasten
Cloud Run-Jobs mit oder ohne konfigurierte GPU können KI-Arbeitslasten wie Batchinferenz, Feinabstimmung von Modellen und Modelltraining hosten.

Cloud Run-Worker-Pools

Worker-Pools sind für Arbeitslasten konzipiert, die nicht auf die Verarbeitung von HTTP-Anfragen angewiesen sind. Sie bieten einen flexiblen und skalierbaren Pool von Rechenressourcen, der auf die kontinuierliche, nicht HTTP-basierte, pullbasierte Hintergrundverarbeitung zugeschnitten ist. Die folgenden Hauptmerkmale definieren die Funktionsweise von Worker-Pools:

  • Worker-Pools werden nicht automatisch skaliert. Skalieren Sie die Anzahl der Instanzen, die Ihr Cloud Run-Worker-Pool zum Verarbeiten seiner Arbeitslast benötigt, manuell. Damit Ihre Arbeitslast gestartet werden kann und aktiv bleibt, muss sie mindestens eine Instanz haben. Wenn Sie die Mindestanzahl von Instanzen auf 0 festlegen, wird die Worker-Instanz nicht gestartet, auch wenn die Bereitstellung erfolgreich ist.

  • Wenn Sie Instanzen dynamisch an den Echtzeitbedarf anpassen möchten, erstellen Sie einen eigenen Autoscaler. Ein Beispiel finden Sie unter Kafka-Consumer Arbeitslasten automatisch skalieren.

  • Worker-Pools verwalten Rollouts, indem sie Instanzen zwischen Überarbeitungen aufteilen, anstatt Traffic aufzuteilen. Bei einem Worker-Pool mit vier Instanzen können Sie beispielsweise 25% (eine Instanz) einer neuen Version und 75% (drei Instanzen) einer stabilen Version zuweisen.

  • Worker-Pools unterstützen ausgehenden und eingehenden Direct VPC-Traffic und haben keinen Load-Balanced-Endpunkt oder keine Load-Balanced-URL. Weitere Informationen zur Unterstützung des Metadatenservers (MDS) und zum Abrufen der privaten IP-Adressen Ihrer Worker-Pool Instanz finden Sie unter dem Containerlaufzeitvertrag.

  • In Cloud Run werden Ihnen nur die Kosten für die Dauer der Ausführung Ihrer Worker-Pool-Instanzen in Rechnung gestellt.

Wann werden Cloud Run-Worker-Pools verwendet?

Worker-Pools erfordern keine öffentlichen HTTP-Endpunkte. Dadurch wird Ihr Netzwerk sicherer und Ihr Anwendungscode einfacher. Außerdem müssen Sie keine Ports für Systemdiagnosen verwalten. Die folgenden Anwendungsfälle gelten für Worker-Pools:

  • Pullbasierte Arbeitslasten: Stellen Sie eine Arbeitslast bereit, um Nachrichten aus einer Warteschlange zur Verarbeitung abzurufen. Beispiele: Kafka Consumer, Pub/Sub-Pull, und RabbitMQ.

    Das folgende Diagramm zeigt Anwendungsfälle für die Bereitstellung von Worker-Pools für pullbasierte Arbeitslasten:

    Pullbasierte Arbeitslasten in Cloud Run-Worker-Pools

    In einem Pub/Sub-Anwendungsfall ruft ein automatisch skalierter Cloud Run-Abonnent Nachrichten aus einem Pub/Sub-Abo ab. In einem Kafka-Anwendungsfall ruft ein automatisch skalierter Cloud Run-Consumer Nachrichten aus einem Kafka-Thema ab.

  • Allgemeine Arbeitslasten, die keine Anfragen sind: Führen Sie eine containerbasierte Arbeitslast aus, die nicht für die Verarbeitung eingehender Anfragen vorgesehen ist.

Cloud Run-Instanzen

Eine Cloud Run-Instanz ist für Arbeitslasten konzipiert, die eine stabile, kontinuierliche und individuell adressierbare Singleton-Laufzeit erfordern, anstatt einer anfragebasierten horizontalen Skalierung.

Im Gegensatz zu einem Dienst, der mehrere Containerinstanzen haben und für Autoscaling oder manuelle Skalierung konfiguriert werden kann, ist eine Cloud Run-Instanz nur eine Instanz.

Cloud Run-Dienst und Cloud Run-Instanz vergleichen
Cloud Run-Dienst und Cloud Run-Instanz vergleichen

Eine Cloud Run-Instanz hat die folgenden Merkmale:

  • Individuell verwaltbar: Sie können jede Instanz einzeln erstellen, aktualisieren und löschen, die Instanz starten und beenden und die Ausführungen überwachen.
  • Individuell adressierbar: Jeder Instanz wird eine eindeutige URL zugewiesen.
  • Lange Lebensdauer: Die Instanz kann stunden- oder tagelang ununterbrochen ausgeführt werden oder sogar länger, wenn sie so konfiguriert ist, dass sie nach regelmäßigen Infrastrukturupdates (alle 1 bis 2 Wochen) automatisch neu gestartet wird.
  • Schnelle Erstellung: Die Instanz wird in etwa 20 Sekunden oder weniger bereitgestellt und ausgeführt.

Wann werden Cloud Run-Instanzen verwendet?

Cloud Run-Instanzen sind für persistente Singleton-Computing-Arbeitslasten konzipiert, die für die Ausführung von Agenten-Arbeitslasten und nicht KI-basierten Workflows entwickelt wurden. Beispiel-Anwendungsfälle umfassen Folgendes:

KI-Agenten und KI-Workflow-Engines mit langer Lebensdauer
Erstellen Sie Hintergrundagenten mit langer Ausführungszeit, die mehrstufige Ausführungspläne ausführen, asynchrone Coding-Assistenten ausführen oder zustandsorientierte Workflows verwalten, die eine Umgebung mit einer einzelnen Instanz erfordern.
Serverloses Computing mit langer Lebensdauer
Stellen Sie einfache, ständig aktive Server bereit, ähnlich einem Virtual Private Server (VPS), die kontinuierlich ausgeführt werden. Dies ist ideal, wenn Sie Arbeitslasten benötigen, die kein Autoscaling erfordern oder Web-Scale-Traffic verarbeiten, und Sie geringere Kosten und eine längere Lebensdauer von Singletons gegenüber Hochverfügbarkeit priorisieren möchten.
Entwicklungsumgebungen und Debugging-Schleifen
Stellen Sie dedizierte Umgebungen bereit, um Containerprozesse remote zu debuggen, Codeänderungen zu synchronisieren und Fehler zu beheben, ohne dass der Container automatisch beendet wird.

Google Cloud Integrationen

Cloud Run lässt sich in das umfassendere System von Google Cloud einbinden Google Cloud, sodass Sie Anwendungen mit komplettem Funktionsumfang erstellen können.

Wichtige Integrationen sind:

Datenspeicher
Cloud Run kann in Cloud SQL (verwaltetes MySQL, PostgreSQL und SQL Server), Memorystore (verwalteter Redis und Memcached), Firestore, Spanner und Cloud Storage eingebunden werden und weitere. Eine vollständige Liste finden Sie unter Datenspeicherung.
Logging und Fehlerberichte
Cloud Logging nimmt automatisch Containerlogs auf. Wenn die Logs Ausnahmen enthalten, werden diese von Error Reporting zusammengefasst und Sie werden benachrichtigt. Die folgenden Sprachen werden unterstützt: Go, Java, Node.js, PHP, Python, Ruby und .NET.
Dienstidentität
Jede Cloud Run-Überarbeitung ist mit einem Dienstkonto verknüpft. Die Google Cloud Clientbibliotheken verwenden dieses Dienstkonto transparent für die Authentifizierung bei Google Cloud APIs.
Continuous Delivery
Wenn Sie Ihren Quellcode in GitHub speichern, können Sie Cloud Run so konfigurieren, dass neue Commits automatisch bereitgestellt werden.
Privates Netzwerk
Cloud Run-Instanzen können Ressourcen im Virtual Private Cloud-Netzwerk (VPC) über den Connector für serverlosen VPC-Zugriff erreichen. So kann Ihr Dienst eine Verbindung zu virtuellen Compute Engine-Maschinen oder -Produkten basierend auf Compute Engine wie Google Kubernetes Engine oder Memorystore herstellen.
Google Cloud APIs
Der Code Ihres Dienstes wird transparent mit Google Cloud APIs authentifiziert. Beispiele hierfür sind die KI und Machine Learning APIs wie die Cloud Vision API, Speech-to-Text API, AutoML Natural Language API, Cloud Translation API und mehr.
Hintergrundaufgaben
Sie können Code für die spätere oder sofortige Ausführung nach einer Webanfrage planen. Cloud Run funktioniert gut mit Cloud Tasks zusammen, um eine skalierbare und zuverlässige asynchrone Ausführung zu ermöglichen.

Unter Verbindung zu Google Cloud Diensten finden Sie eine Liste der vielen Google Cloud Dienste, die gut mit Cloud Run funktionieren.

Code wird in einem Container-Image ausgeführt

Sie müssen sich nicht mit Containern auskennen, um Ihren Code in Cloud Run bereitzustellen. Ihr Code wird jedoch immer in Containerinstanzen in einer Sandbox ausgeführt.

Hier finden Sie eine kurze konzeptionelle Einführung, wenn Sie nicht mit Containern vertraut sind.

Container-Images erstellen

Wie das Diagramm zeigt, erstellen Sie mit Quellcode, Assets und Bibliotheksabhängigkeiten ein Container-Image. Dieses Image ist ein Paket, das alles enthält, was Ihr Dienst zum Ausführen benötigt, einschließlich Build-Artefakten, Assets, Systempaketen und optional einer Laufzeit. Containeranwendungen sind von Natur aus portierbar und können überall ausgeführt werden, wo ein Container ausgeführt werden kann. Beispiele für Build-Artefakte sind kompilierte Binärdateien oder Skriptdateien. Beispiele für Laufzeiten sind die JavaScript-Laufzeit Node.js oder eine virtuelle Java-Maschine.

Fortgeschrittene Fachleute schätzen die Tatsache, dass Cloud Run keine zusätzlichen Belastung für die Ausführung von Code verursacht. Sie können jede Binärdatei in Cloud Run ausführen.

Wenn Sie es einfacher machen oder die Containerisierung von Anwendungen an Google delegieren möchten, kann Cloud Run in die Open-Source- Build-Pakete von Google Cloud eingebunden werden, um eine quellenbasierte Bereitstellung bereitzustellen.

Nächste Schritte