Was ist Cloud Run?

Cloud Run ist eine verwaltete Computing-Plattform, mit der Sie Container direkt auf der 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 hat Cloud Run für die Zusammenarbeit mit anderen Diensten auf 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 und Worker-Pools: drei Möglichkeiten zum Ausführen des Codes

Bei Cloud Run kann Ihr Code als Dienst, Job oder Worker-Pool ausgeführt werden. Alle diese Ressourcentypen werden in derselben Umgebung ausgeführt und können dieselben Integrationen in andere Dienste auf Google Cloudverwenden.

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, kurzlebige Instanzen, die auf der Grundlage verschiedener wichtiger Messwerte automatisch skaliert werden. Außerdem reagiert sie auf Ereignisse und Funktionen.
Job Verarbeitet nicht anfragebasierte parallelisierbare Aufgaben, die manuell oder nach einem Zeitplan ausgeführt werden und bis zum Abschluss laufen.
Worker-Pool Verarbeitet nicht anfragebasierte Arbeitslasten wie Pull-basierte Arbeitslasten, z. B. Kafka-Consumer, Pub/Sub-Pull-Warteschlangen oder RabbitMQ-Consumer.

Cloud Run-Dienste

Ein Cloud Run-Dienst bietet Ihnen die Infrastruktur, die zum Ausführen eines zuverlässigen HTTPS-Endpunkts erforderlich ist. Sie müssen dafür sorgen, dass Ihr Code einen TCP-Port überwacht und HTTP-Anfragen verarbeitet.

Das folgende Diagramm zeigt einen Cloud Run-Dienst, der mehrere Containerinstanzen ausführt, um Webanfragen und Ereignisse vom Client über einen HTTPS-Endpunkt 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 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 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 graduelle Rollouts. Dazu können Sie eingehenden Traffic an die neueste Überarbeitung weiterleiten, ein Rollback zu einer vorherigen Überarbeitung durchführen oder den Traffic gleichzeitig auf mehrere Überarbeitungen aufteilen.

Sie können beispielsweise mit dem Senden von 1% der Anfragen an eine neue Überarbeitung 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 Instanzen automatisch hinzu und entfernt sie, um alle eingehenden Anfragen zu verarbeiten oder um eine erhöhte CPU-Auslastung außerhalb von Anfragen zu bewältigen.

Wenn keine eingehenden Anfragen an Ihren Dienst eingehen, wird auch die letzte verbleibende Instanz entfernt. Dieses Verhalten wird allgemein als Skalierung auf null bezeichnet. Wenn dann bei einer eingehenden Anfrage keine aktiven Instanzen vorhanden sind, erstellt Cloud Run eine neue Instanz. Dies wirkt sich negativ auf die Antwortzeit für diese ersten Anfragen aus, je nachdem, wie schnell Ihr Container für die Verarbeitung von Anfragen bereit ist.

Sie haben folgende Möglichkeiten, dieses Verhalten zu ändern:

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 abfangen. 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. auf eine Nachricht in 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. durch ein 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, einen wiederkehrenden Job planen oder 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, bei dem viele identische, unabhängige Instanzen parallel gestartet werden. 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, der sequenziell ausgeführt wird, 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
In Cloud Run-Jobs mit oder ohne konfigurierte GPU können KI-Arbeitslasten wie Batchinferenz, Feinabstimmung von Modellen und Modelltraining gehostet werden.

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 kontinuierliche, nicht HTTP-basierte, pullbasierte Hintergrundverarbeitung zugeschnitten ist. Die folgenden wichtigen Merkmale definieren die Funktionsweise von Worker-Pools:

  • Worker-Pools werden nicht automatisch skaliert. Manuelles Skalieren der Anzahl der Instanzen, die Ihr Cloud Run-Worker-Pool zum Verarbeiten seiner Arbeitslast benötigt. Damit Ihre Arbeitslast gestartet wird 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 die Echtzeitnachfrage 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. Für einen Worker-Pool mit vier Instanzen können Sie beispielsweise 25% (eine Instanz) einer neuen Revision und 75% (drei Instanzen) einer stabilen Revision zuweisen.

  • Worker-Pools haben keinen Load-Balancing-Endpunkt oder keine Load-Balancing-URL.

  • In Cloud Run werden Ihnen nur die Ressourcen in Rechnung gestellt, die Sie tatsächlich nutzen.

Wann sollten Cloud Run-Worker-Pools verwendet werden?

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

  • Pull-basierte Arbeitslasten: Sie stellen eine Arbeitslast bereit, um Nachrichten aus einer Warteschlange zur Verarbeitung abzurufen. Beispiele sind KafkaConsumer, Pub/Sub-Pull und RabbitMQ.

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

    Pull-basierte Arbeitslasten in Cloud Run-Worker-Pools

    In einem Pub/Sub-Anwendungsfall ruft ein automatisch skaliertes Cloud Run-Abonnentenmodul Nachrichten aus einem Pub/Sub-Abo ab. In einem Kafka-Anwendungsfall ruft ein automatisch skaliertes Cloud Run-Nutzer 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.

Google Cloud -Integrationen

Cloud Run lässt sich in das umfassendere System von Google Cloudeinbinden, 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
Containerlogs werden automatisch in Cloud Logging aufgenommen. 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, Bitbucket oder Cloud Source Repositories 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 ü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. Dazu gehören die KI- und Machine Learning-APIs wie die Cloud Vision API, die Speech-to-Text API, die AutoML Natural Language API und die Cloud Translation API.
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 herstellen finden Sie eine Liste der vielen Google Cloud -Dienste, die gut mit Cloud Run funktionieren.

Code muss in einem Container-Image verpackt werden

Damit Ihr Dienst, Job oder Worker-Pool in Cloud Run bereitgestellt werden kann, müssen Sie ihn in einem Container-Image verpacken. Hier finden Sie eine kurze konzeptionelle Einführung, wenn Sie nicht mit Containern vertraut sind.

Container-Images erstellen

Wie das Diagramm zeigt, verwenden Sie den Quellcode, die Assets und die Bibliotheksabhängigkeiten, um das Container-Image zu erstellen. Dieses ist ein Paket mit allem, was Ihr Dienst zum Ausführen benötigt. Dies umfasst Build-Artefakte, Assets, Systempakete und (optional) eine Laufzeit. Dadurch wird eine Containeranwendung von Natur aus portierbar. Sie kann ü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 (JVM).

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

Wenn Sie es einfacher machen oder die Containerisierung Ihrer Anwendung 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