In Cloud Run bereitstellen

Auf dieser Seite wird beschrieben, wie Sie Container-Images für einen neuen Cloud Run-Dienst oder eine neue Überarbeitung eines vorhandenen Cloud Run-Dienstes bereitstellen.

Vorbereitung

Wenn Sie einer Domaineinschränkung zur Organisation nicht eingeschränkter Aufrufe für Ihr Projekt unterliegen, müssen Sie auf Ihren bereitgestellten Dienst zugreifen, wie unter Private Dienste testen beschrieben.

Für das Deployment erforderliche Berechtigungen

Sie benötigen EINES von Folgendem:

Inhaber
Bearbeiter
Sowohl die Rolle Cloud Run-Administrator als auch die Rolle Dienstkontonutzer,
Jede benutzerdefinierte Rolle, die diese bestimmte Liste von Berechtigungen enthält.

Unterstützte Container Registries und Images

Sie können in Artifact Registry, Container Registry (Eingestellt) oder Docker Hub gespeicherte Container-Images verwenden. Google empfiehlt die Verwendung von Artifact Registry.

Sie können nur die folgenden Arten von Container-Images verwenden:

Container-Images, die im selben Projekt gespeichert sind, in dem Sie den Job oder Dienst erstellen.
Container-Images aus anderen Google Cloud-Projekten (sofern die richtigen IAM-Berechtigungen festgelegt sind)
Öffentliche Container-Images von Artifact Registry, Container Registry oder Docker Hub

Sie sollten nur Docker Hub in Betracht ziehen, um beliebte Container-Images wie offizielle Docker-Images oder Docker Gesponserte OSS-Images bereitzustellen. Für eine höhere Verfügbarkeit empfiehlt Google, die Docker Hub-Images über ein Remote-Repository der Artifact Registry bereitzustellen.

Wenn Sie Container-Images in einem anderen Typ von Container Registry speichern, folgen Sie der Anleitung unter Images aus nicht unterstützten Registries bereitstellen.

Neuen Dienst bereitstellen

Sie können ein Container-Image mit einem Tag (z. B. us-docker.pkg.dev/my-project/container/my-image:latest) oder mit einem genauen Digest (z. B. us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...) angeben.

Wenn Sie einen Dienst zum ersten Mal bereitstellen, wird die erste Überarbeitung erstellt. Überarbeitungen können nach der Erstellung nicht mehr geändert werden. Wenn Sie den Dienst aus einem Container-Image-Tag bereitstellen, wird er in einen Digest aufgelöst. Die Überarbeitung stellt anschließend immer diesen speziellen Digest bereit.

Sie können einen Container über die Google Cloud Console, die gcloud-Befehlszeile oder eine YAML-Konfigurationsdatei bereitstellen.

Klicken Sie auf den Tab, um eine Anleitung zum gewünschten Tool zu erhalten.

Console

So stellen Sie ein Container-Image bereit:

Öffnen Sie Cloud Run.
Klicken Sie auf Dienst erstellen, um das Formular Dienst erstellen aufzurufen.
1. Wählen Sie im Formular die Bereitstellungsoption aus:
  1. Wenn Sie einen Container manuell bereitstellen möchten, wählen Sie Eine Überarbeitung aus dem vorhandenen Container-Image bereitstellen aus und geben Sie das Container-Image an.
  2. Wenn Sie die kontinuierliche Bereitstellung automatisieren möchten, wählen Sie Kontinuierlich neue Überarbeitungen aus einem Quell-Repository bereitstellen aus und folgen Sie der Anleitung für kontinuierliche Bereitstellungen.
2. Geben Sie den erforderlichen Dienstnamen ein. Dienstnamen dürfen maximal 49 Zeichen lang sein und pro Region und Projekt nur einmal vorkommen. Ein Dienstname kann später nicht mehr geändert werden und ist öffentlich sichtbar.
3. Wählen Sie die Region aus, in der sich Ihr Dienst befinden soll. Die Regionsauswahl gibt die Preisstufe, die Verfügbarkeit von Domainzuordnungen an und hebt Regionen mit den niedrigsten CO2-Auswirkungen hervor.
4. Legen Sie CPU-Zuweisung und -Preise nach Bedarf fest.
5. Geben Sie unter Autoscaling die minimale und die maximale Anzahl an Instanzen an.
6. Legen Sie die Ingress-Einstellungen wie gewünscht im Formular fest.
7. Konfigurieren Sie unter Authentifizierung Folgendes:
  - Wenn Sie eine öffentliche API oder Website erstellen, wählen Sie Nicht authentifizierte Aufrufe zulassen aus. Durch Anklicken des Kästchens wird der Sonderkennzeichnung allUser die Rolle "IAM-Invoker" zugewiesen. Sie können die Einstellung mit IAM bearbeiten, nachdem Sie den Dienst erstellt haben.
  - Wenn Sie einen durch Authentifizierung geschützten sicheren Dienst wünschen, wählen Sie Authentifizierung erforderlich aus.
Klicken Sie auf Container, Volumes, Netzwerk, Sicherheit, um weitere optionale Einstellungen in den entsprechenden Tabs festzulegen:
Wenn Sie die Konfiguration Ihres Dienstes abgeschlossen haben, klicken Sie auf Erstellen, um das Image in Cloud Run bereitzustellen. Warten Sie, bis das Deployment abgeschlossen ist.
Klicken Sie auf den angezeigten URL-Link, um den nur einmal vorkommenden und stabilen Endpunkt des bereitgestellten Dienstes zu öffnen.

Befehlszeile

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
So stellen Sie ein Container-Image bereit:
1. Führen Sie dazu diesen Befehl aus:
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  - Ersetzen Sie SERVICE durch den Namen des Dienstes, für den Sie die Bereitstellung vornehmen möchten. Dienstnamen dürfen maximal 49 Zeichen lang sein und pro Region und Projekt nur einmal vorkommen. Wenn der Dienst noch nicht vorhanden ist, erstellt dieser Befehl den Dienst während der Bereitstellung. Sie können diesen Parameter auch weglassen, werden dann jedoch nach dem Dienstnamen gefragt.
  - Ersetzen Sie IMAGE_URL durch einen Verweis auf das Container-Image, z. B. us-docker.pkg.dev/cloudrun/container/hello:latest. Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat die Form REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG. Wenn Sie das Flag --image nicht angeben, wird mit dem Bereitstellungsbefehl versucht, aus dem Quellcode bereitzustellen.
  Wenn Sie eine öffentliche API oder Website erstellen, können Sie mit dem Flag --allow-unauthenticated nicht authentifizierte Aufrufe zulassen. Dadurch wird allUsers die IAM-Rolle Cloud Run Invoker zugewiesen. Sie können auch --no-allow-unauthenticated angeben, um nicht authentifizierte Aufrufe zu verbieten. Wenn Sie keines dieser Flags angeben, werden Sie aufgefordert, zu bestätigen, ob nicht authentifizierte Aufrufe zugelassen werden sollen, wenn der Befehl deploy ausgeführt wird.
2. Warten Sie, bis die Bereitstellung abgeschlossen ist. Nach erfolgreichem Abschluss wird eine Bestätigung zusammen mit der URL des bereitgestellten Dienstes angezeigt.
Wenn Sie an einem anderen Standort bereitstellen möchten, als Sie in den gcloud-Attributen run/region angegeben haben, verwenden Sie Folgendes:
- ```
gcloud run deploy SERVICE --region REGION
```

YAML

Sie können Ihre Dienstspezifikation in einer YAML-Datei speichern und dann mit der gcloud CLI bereitstellen.

Erstellen Sie eine neue Datei vom Typ service.yaml mit folgendem Inhalt:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: IMAGE
```
Ersetzen
- SERVICE durch den Namen Ihres Cloud Run-Dienstes. Dienstnamen dürfen maximal 49 Zeichen lang sein und pro Region und Projekt nur einmal vorkommen.
- IMAGE durch die URL Ihres Container-Images
Sie können auch weitere Konfigurationen angeben, z. B. Umgebungsvariablen oder Speicherlimits.
Stellen Sie den neuen Dienst mit dem folgenden Befehl bereit:
```
gcloud run services replace service.yaml
```
Optional: Veröffentlichen Sie Ihren Dienst, wenn Sie den nicht authentifizierten Zugriff auf den Dienst zulassen möchten.

Cloud Code

Lesen Sie für die Bereitstellung mit Cloud Code die Anleitungen zu IntelliJ und Visual Studio Code.

Terraform

Wenn Sie Terraform verwenden, können Sie den Dienst in einer Terraform-Konfiguration definieren. Dabei verwenden Sie die Ressource google_cloud_run_v2_service des Google Cloud Platform-Anbieters.

Erstellen Sie eine neue main.tf-Datei mit folgendem Inhalt:
```
provider "google" {
  project = "PROJECT-ID"
}

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  client   = "terraform"

  template {
    containers {
      image = "IMAGE"
    }
  }
}

resource "google_cloud_run_v2_service_iam_member" "noauth" {
  location = google_cloud_run_v2_service.default.location
  name     = google_cloud_run_v2_service.default.name
  role     = "roles/run.invoker"
  member   = "allUsers"
}
```
Ersetzen
- PROJECT-ID durch die Google Cloud-Projekt-ID
- REGION durch die Google Cloud-Region
- SERVICE durch den Namen Ihres Cloud Run-Dienstes. Dienstnamen dürfen maximal 49 Zeichen lang sein und pro Region und Projekt nur einmal vorkommen.
- IMAGE_URL durch einen Verweis auf das Container-Image, z. B. us-docker.pkg.dev/cloudrun/container/hello:latest. Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat die Form REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
Diese Konfiguration ermöglicht öffentlichen Zugriff (entspricht --allow-unauthenticated). Wenn Sie den Dienst privat machen möchten, entfernen Sie die google_cloud_run_v2_service_iam_member-Stanza.
Initialisieren Sie Terraform:
```
terraform init
```
Wenden Sie die Terraform-Konfiguration an:
```
terraform apply
```
Bestätigen Sie, dass Sie die beschriebenen Aktionen anwenden möchten, indem Sie yes eingeben.

Clientbibliotheken

So erstellen Sie einen neuen Dienst aus Code:

Cloud Run-Standorte

Cloud Run ist regional. Die Infrastruktur, in der die Cloud Run-Dienste ausgeführt werden, befindet sich demnach in einer bestimmten Region. Aufgrund der Verwaltung durch Google sind die Anwendungen in allen Zonen innerhalb dieser Region redundant verfügbar.

Bei der Auswahl der Region, in der Ihre Cloud Run-Dienste ausgeführt werden, ist vorrangig, dass die Anforderungen hinsichtlich Latenz, Verfügbarkeit oder Langlebigkeit erfüllt werden. Sie können im Allgemeinen die Region auswählen, die Ihren Nutzern am nächsten liegt, aber Sie sollten den Standort der anderen Google Cloud-Produkte berücksichtigen, die von Ihrem Cloud Run-Dienst verwendet werden. Die gemeinsame Nutzung von Google Cloud-Produkten an mehreren Standorten kann sich auf die Latenz und die Kosten des Dienstes auswirken.

Cloud Run ist in diesen Regionen verfügbar:

Unterliegt Preisstufe 1

asia-east1 (Taiwan)
asia-northeast1 (Tokio)
asia-northeast2 (Osaka)
europe-north1 (Finnland) Niedriger CO₂-Wert
europe-southwest1 (Madrid)
europe-west1 (Belgien) Niedriger CO₂-Ausstoß
europe-west4 (Niederlande)
europe-west8 (Mailand)
europe-west9 (Paris) Niedriger CO₂-Ausstoß
me-west1 (Tel Aviv)
us-central1 (Iowa) Niedriger CO₂-Ausstoß
us-east1 (South Carolina)
us-east4 (Northern Virginia)
us-east5 (Columbus)
us-south1 (Dallas)
us-west1 (Oregon) Niedriger CO₂-Ausstoß

Unterliegt Preisstufe 2

asia-east2 (Hongkong)
asia-northeast3 (Seoul, Südkorea)
asia-southeast1 (Singapur)
asia-southeast2 (Jakarta)
asia-south1 (Mumbai, Indien)
asia-south2 (Delhi, Indien)
australia-southeast1 (Sydney)
australia-southeast2 (Melbourne)
europe-central2 (Warschau, Polen)
europe-west10 (Berlin)
europe-west12 (Turin)
europe-west2 (London, Vereinigtes Königreich) Niedriger CO₂-Ausstoß
europe-west3 (Frankfurt, Deutschland) Niedriger CO₂-Wert
europe-west6 (Zürich, Schweiz) Niedriger CO₂-Ausstoß
me-central1 (Doha)
me-central2 (Dammam)
northamerica-northeast1 (Montreal) Niedriger CO₂-Ausstoß
northamerica-northeast2 (Toronto) Niedriger CO₂-Ausstoß
southamerica-east1 (Sao Paulo, Brasilien) Niedriger CO₂-Ausstoß
southamerica-west1 (Santiago, Chile) Niedriger CO₂-Ausstoß
us-west2 (Los Angeles)
us-west3 (Salt Lake City)
us-west4 (Las Vegas)

Wenn Sie bereits einen Cloud Run-Dienst erstellt haben, können Sie dessen Region im Cloud Run-Dashboard der Google Cloud Console aufrufen.

Beim Bereitstellen muss der Dienst-Agent von Cloud Run auf den bereitgestellten Container zugreifen können, was standardmäßig der Fall ist.

Jeder Dienst hat eine eindeutige und permanente URL, die sich im Laufe der Zeit nicht ändert, wenn Sie neue Überarbeitungen bereitstellen.

Neue Überarbeitung eines vorhandenen Dienstes bereitstellen

Sie können eine neue Überarbeitung über die Google Cloud Console, die gcloud-Befehlszeile oder eine YAML-Konfigurationsdatei bereitstellen.

Beachten Sie, dass beim Ändern von Konfigurationseinstellungen eine neue Überarbeitung erstellt wird, auch wenn das Container-Image nicht geändert wird. Überarbeitungen können nach der Erstellung nicht mehr geändert werden.

Klicken Sie auf den Tab, um eine Anleitung zum gewünschten Tool zu erhalten.

Console

So stellen Sie eine neue Überarbeitung eines vorhandenen Dienstes bereit:

Öffnen Sie Cloud Run.
Klicken Sie in der Übersicht auf den zu aktualisierenden Dienst, um dessen Details anzuzeigen.
Klicken Sie auf Neue Überarbeitung bearbeiten und bereitstellen, um das Formular für die Bereitstellung der Überarbeitung aufzurufen.
1. Geben Sie bei Bedarf die URL des neu bereitzustellenden Container-Images an.
2. Konfigurieren Sie den Container nach Bedarf.
3. Legen Sie CPU-Zuweisung und -Preise nach Bedarf fest.
4. Geben Sie unter „Kapazität” Speicherlimits und CPU-Limits an.
5. Geben Sie nach Bedarf Zeitlimit für Anfragen und Gleichzeitigkeit an.
6. Geben Sie nach Bedarf die Ausführungsumgebung an.
7. Geben Sie unter Autoscaling die minimale und die maximale Anzahl an Instanzen an.
8. Verwenden Sie nach Bedarf die anderen Tabs, um Folgendes zu konfigurieren:
Wählen Sie Diese Version sofort bereitstellen aus, um den gesamten Traffic an die neue Version zu senden. Wenn Sie eine neue Version nach und nach einführen möchten, entfernen Sie das Häkchen aus diesem Kästchen. Dies führt zu einer Bereitstellung, bei der kein Traffic an die neue Version gesendet wird. Folgen Sie der Anleitung für schrittweise Rollouts nach der Bereitstellung.
Klicken Sie auf Bereitstellen und warten Sie, bis die Bereitstellung abgeschlossen ist.

Befehlszeile

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
So stellen Sie ein Container-Image bereit:
1. Führen Sie diesen Befehl aus:
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  - Ersetzen Sie SERVICE durch den Namen des für die Bereitstellung verwendeten Dienstes. Sie können diesen Parameter auch weglassen, werden dann jedoch nach dem Dienstnamen gefragt.
  - Ersetzen Sie IMAGE_URL durch einen Verweis auf das Container-Image, z. B. us-docker.pkg.dev/cloudrun/container/hello:latest. Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat die Form REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  Das Überarbeitungssuffix wird neuen Überarbeitungen automatisch zugewiesen. Wenn Sie Ihr eigenes Überarbeitungssuffix angeben möchten, verwenden Sie den gcloud CLI-Parameter --revision-suffix.
2. Warten Sie, bis die Bereitstellung abgeschlossen ist. Nach erfolgreichem Abschluss wird eine Bestätigung zusammen mit der URL des bereitgestellten Dienstes angezeigt.

YAML

Wenn Sie die Konfiguration eines vorhandenen Dienstes herunterladen oder aufrufen müssen, speichern Sie die Ergebnisse mit dem folgenden Befehl in einer YAML-Datei:

gcloud run services describe SERVICE --format export > service.yaml

Ändern Sie in einer YAML-Dienstkonfigurationsdatei alle untergeordneten spec.template-Attribute wie gewünscht, um die Überarbeitungseinstellungen zu aktualisieren, und stellen Sie dann die neue Überarbeitung bereit:

gcloud run services replace service.yaml

Cloud Code

Weitere Informationen zum Bereitstellen einer neuen Version eines vorhandenen Dienstes mit Cloud Code finden Sie in den Anleitungen zu IntelliJ und Visual Studio Code.

Terraform

Achten Sie darauf, dass Sie Terraform wie im Beispiel Neuen Dienst bereitstellen eingerichtet haben.

Nehmen Sie eine Änderung an der Konfigurationsdatei vor.
Wenden Sie die Terraform-Konfiguration an:
```
terraform apply
```
Bestätigen Sie, dass Sie die beschriebenen Aktionen anwenden möchten, indem Sie yes eingeben.
Hinweis: Sofern keine Konfigurationsänderung erforderlich ist, wird keine neue Überarbeitung erstellt.

Cloud Run-Standorte

Cloud Run ist in diesen Regionen verfügbar:

Unterliegt Preisstufe 1

asia-east1 (Taiwan)
asia-northeast1 (Tokio)
asia-northeast2 (Osaka)
europe-north1 (Finnland) Niedriger CO₂-Wert
europe-southwest1 (Madrid)
europe-west1 (Belgien) Niedriger CO₂-Ausstoß
europe-west4 (Niederlande)
europe-west8 (Mailand)
europe-west9 (Paris) Niedriger CO₂-Ausstoß
me-west1 (Tel Aviv)
us-central1 (Iowa) Niedriger CO₂-Ausstoß
us-east1 (South Carolina)
us-east4 (Northern Virginia)
us-east5 (Columbus)
us-south1 (Dallas)
us-west1 (Oregon) Niedriger CO₂-Ausstoß

Unterliegt Preisstufe 2

asia-east2 (Hongkong)
asia-northeast3 (Seoul, Südkorea)
asia-southeast1 (Singapur)
asia-southeast2 (Jakarta)
asia-south1 (Mumbai, Indien)
asia-south2 (Delhi, Indien)
australia-southeast1 (Sydney)
australia-southeast2 (Melbourne)
europe-central2 (Warschau, Polen)
europe-west10 (Berlin)
europe-west12 (Turin)
europe-west2 (London, Vereinigtes Königreich) Niedriger CO₂-Ausstoß
europe-west3 (Frankfurt, Deutschland) Niedriger CO₂-Wert
europe-west6 (Zürich, Schweiz) Niedriger CO₂-Ausstoß
me-central1 (Doha)
me-central2 (Dammam)
northamerica-northeast1 (Montreal) Niedriger CO₂-Ausstoß
northamerica-northeast2 (Toronto) Niedriger CO₂-Ausstoß
southamerica-east1 (Sao Paulo, Brasilien) Niedriger CO₂-Ausstoß
southamerica-west1 (Santiago, Chile) Niedriger CO₂-Ausstoß
us-west2 (Los Angeles)
us-west3 (Salt Lake City)
us-west4 (Las Vegas)

Wenn Sie bereits einen Cloud Run-Dienst erstellt haben, können Sie dessen Region im Cloud Run-Dashboard der Google Cloud Console aufrufen.

Images aus anderen Google Cloud-Projekten bereitstellen

Sie können Container-Images aus anderen Google Cloud-Projekten bereitstellen, wenn Sie die richtigen IAM-Berechtigungen festlegen:

Öffnen Sie in der Google Cloud Console das Projekt für Ihren Cloud Run-Dienst.

Zur IAM-Seite
Wählen Sie Von Google bereitgestellte Rollenzuweisungen einschließen aus.
Kopieren Sie die E-Mail des Cloud Run-Dienst-Agents. Sie hat das Suffix @serverless-robot-prod.iam.gserviceaccount.com
Öffnen Sie das Projekt mit der gewünschten Container Registry.

Zur IAM-Seite
Klicken Sie auf Hinzufügen, um ein neues Hauptkonto hinzuzufügen.
Fügen Sie in das Feld Neue Hauptkonten die zuvor kopierte E-Mail-Adresse des Dienstkontos ein.
Wählen Sie im Drop-down-Menü Rolle auswählen die Rolle Storage -> Storage-Objekt-Betrachter aus, wenn Sie Container Registry verwenden. Wenn Sie Artifact Registry verwenden, wählen Sie die Rolle Artifact Registry -> Artifact Registry-Leser aus.
Stellen Sie das Container-Image für das Projekt bereit, das den Cloud Run-Dienst enthält.

Hinweis: Beschränken Sie den Zugriff auf den Cloud Storage-Bucket oder das Artifact Registry-Repository mit den Container-Images, um eine höhere Sicherheit zu erhalten.

Images aus nicht unterstützten Registries bereitstellen

Wenn Sie Container-Images in einer nicht unterstützten öffentlichen oder privaten Container Registry speichern, können Sie diese vorübergehend mit docker push in Artifact Registry übertragen, um sie in Cloud Run bereitzustellen. Das Container-Image wird von Cloud Run importiert, wenn es bereitgestellt wird. Nach der Bereitstellung können Sie das Image also aus Artifact Registry löschen.

Mehrere Container für einen Dienst bereitstellen (Sidecars)

In einer Cloud Run-Bereitstellung mit Sidecars gibt es einen eingehenden Container, der alle eingehenden HTTPS-Anfragen an dem von Ihnen angegebenen Container-PORT verarbeitet, und einen oder mehrere Sidecar-Container. Die Sidecars können nicht die eingehenden HTTP-Anfragen am Ingress-Container-Port überwachen, aber sie können über einen localhost-Port miteinander und mit dem Ingress-Container kommunizieren. Der verwendete localhost-Port variiert je nach den verwendeten Containern.

Im folgenden Diagramm kommuniziert der Ingress-Container mit localhost:5000 bei der Sidecar-Datei.

Cloud Run-Multicontainer

Sie können bis zu 10 Container pro Instanz bereitstellen, einschließlich des Ingress-Containers. Alle Container innerhalb einer Instanz teilen sich denselben Netzwerk-Namespace und können Dateien auch über freigegebene In-Memory-Volumes freigeben, wie im Diagramm dargestellt.

Sie können mehrere Container entweder in der ersten oder zweiten Generation der Ausführungsumgebung bereitstellen.

Anwendungsfälle

Zu den Anwendungsfällen für Sidecars in einem Cloud Run-Dienst gehören:

Monitoring, Logging und Tracing von Anwendungen
Nginx, Envoy oder Apache2 als Proxy vor Ihrem Anwendungscontainer verwenden
Authentifizierungs- und Autorisierungsfilter hinzufügen (z. B. Open Policy Agent)
Ausgehende Verbindungsproxys ausführen, z. B. den Alloy DB Auth-Proxy

Dienst mit Sidecar-Containern bereitstellen

Sie können mehrere Sidecars für einen Cloud Run-Dienst mithilfe der Google Cloud Console, der Google Cloud CLI oder YAML bereitstellen.

Console

Öffnen Sie Cloud Run.
- Wenn Sie einen vorhandenen Dienst bereitstellen möchten, suchen Sie ihn in der Dienstliste, klicken Sie darauf, um ihn zu öffnen, und klicken Sie dann auf NEUE ÜBERARBEITUNG BEARBEITEN UND ERSTELLEN, um das Formular für die Bereitstellung der Überarbeitung aufzurufen.
- Klicken Sie auf Dienst erstellen, um einen neuen Dienst bereitzustellen.
Bei einem neuen Dienst,
1. geben Sie den Dienstnamen und die URL zum Ingress-Container-Image an, das Sie bereitstellen möchten.
2. Klicken Sie auf Container, Volumes, Netzwerk, Sicherheit.
Konfigurieren Sie auf der Karte Container bearbeiten den Container für eingehenden Traffic nach Bedarf.
Klicken Sie auf Container hinzufügen und konfigurieren Sie einen Sidecar-Container, den Sie zusammen mit dem Container für eingehenden Traffic hinzufügen möchten. Wenn der Sidecar von einem anderen Container im Dienst abhängt, geben Sie dies im Drop-down-Menü Containerstartreihenfolge an. Wiederholen Sie diesen Schritt für jeden Sidecar-Container, den Sie bereitstellen.
Wählen Sie Diese Version sofort bereitstellen aus, um den gesamten Traffic an die neue Version zu senden. Entfernen Sie für einen graduellen Rollout das Häkchen. Dies führt zu einer Bereitstellung, bei der kein Traffic an die neue Version gesendet wird. Folgen Sie der Anleitung für schrittweise Rollouts nach der Bereitstellung.
Klicken Sie für einen neuen Dienst auf Erstellen oder für einen vorhandenen Dienst auf Bereitstellen. Warten Sie dann, bis die Bereitstellung abgeschlossen ist.

Befehlszeile

Die container-Parameter in der Google Cloud CLI befinden sich in der Vorschau.

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
Führen Sie den folgenden Befehl aus, um mehrere Container in einem Dienst bereitzustellen:
```
gcloud beta run deploy SERVICE \
 --container INGRESS_CONTAINER_NAME
 --image='INGRESS_IMAGE' \
 --port='CONTAINER_PORT' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'
```
- Ersetzen Sie SERVICE durch den Namen des für die Bereitstellung verwendeten Dienstes. Sie können diesen Parameter auch weglassen, werden dann jedoch nach dem Dienstnamen gefragt.
- Ersetzen Sie INGRESS_CONTAINER_NAME durch einen Namen für den Container, der Anfragen empfängt, z. B. app.
- Ersetzen Sie INGRESS_IMAGE durch einen Verweis auf das Container-Image, das Anfragen erhalten soll, z. B. us-docker.pkg.dev/cloudrun/container/hello:latest.
- Ersetzen Sie SIDECAR_CONTAINER_NAME durch einen Namen für den Sidecar-Container, z. B. sidecar.
- Ersetzen Sie SIDECAR_IMAGE durch einen Verweis auf das Sidecar-Container-Image.
Wenn Sie jeden Container im Bereitstellungsbefehl konfigurieren möchten, geben Sie die Konfiguration jedes Containers nach den Parametern container an. Beispiel:
```
gcloud beta run deploy SERVICE \
  --container CONTAINER_1_NAME
  --image='INGRESS_IMAGE' \
  --set-env-vars=KEY=VALUE \
  --port='CONTAINER_PORT' \
  --container SIDECAR_CONTAINER_NAME
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N
```
Wichtig: Wenn Sie den Parameter --container verwenden, müssen Sie alle Flags außerhalb des Containers vor den Flags auf Containerebene angeben, andernfalls schlägt der Bereitstellungsbefehl mit einer Fehlermeldung zu diesem Effekt fehl. Im Befehl „gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G“ muss beispielsweise das Flag --execution-environment vor dem Flag --container übergeben werden.
Warten Sie, bis die Bereitstellung abgeschlossen ist. Nach erfolgreichem Abschluss wird eine Bestätigung zusammen mit der URL des bereitgestellten Dienstes angezeigt.

YAML

Diese Anleitung enthält eine einfache YAML-Datei für Ihren Cloud Run-Dienst mit Sidecars. Erstellen Sie eine Datei mit dem Namen service.yaml und fügen Sie Folgendes hinzu:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE_NAME
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE

Ersetzen

SERVICE durch den Namen Ihres Cloud Run-Dienstes. Dienstnamen dürfen maximal 49 Zeichen lang sein.
CONTAINER_PORT durch den Port, den der Container für eingehenden Traffic auf eingehende Anfragen überwacht. Sie müssen einen Port angeben. Im Gegensatz zu einem Dienst mit einem einzelnen Container gibt es für einen Dienst mit Sidecars keinen Standardport für den Ingress-Container.
INGRESS_IMAGE durch einen Verweis auf das Container-Image, das Anfragen erhalten soll, z. B. us-docker.pkg.dev/cloudrun/container/hello:latest.
SIDECAR_IMAGE durch einen Verweis auf das Sidecar-Container-Image. Sie können mehrere Sidecars angeben, indem Sie dem Array containers in der YAML-Datei weitere Elemente hinzufügen.

Nachdem Sie die YAML-Datei aktualisiert haben, um die Ingress- und Sidecar-Container aufzunehmen, stellen Sie in Cloud Run den folgenden Befehl bereit:

gcloud run services replace service.yaml

Wichtige Features, die für Bereitstellungen mit Sidecars zur Verfügung stehen

Sie können die Reihenfolge für den Containerstart in einer Bereitstellung mit mehreren Containern festlegen, wenn Sie Abhängigkeiten haben, die es erfordern, dass einige Container vor den anderen Containern in der Bereitstellung gestartet werden.

Wenn Sie Container haben, die von anderen Containern abhängen, müssen Sie in Ihrer Bereitstellung Systemdiagnosen verwenden. Wenn Sie Systemdiagnosen verwenden, folgt Cloud Run der Startreihenfolge des Containers und prüft die Integrität jedes Containers. So kann sichergestellt werden, dass jeder Container erfolgreich ausgeführt wird, bevor Cloud Run den nächsten Container in der Reihenfolge startet. Wenn Sie keine Systemdiagnosen verwenden, werden fehlerfreie Container gestartet, auch wenn die Container, von denen sie abhängen, nicht ausgeführt werden.

Mehrere Container innerhalb einer einzelnen Instanz können auf ein freigegebenes In-Memory-Volume zugreifen, das für jeden Container über die von Ihnen erstellten Bereitstellungspunkte zugänglich ist.

Nächste Schritte

Nachdem Sie einen neuen Dienst bereitgestellt haben, können Sie Folgendes tun:

Mithilfe von Cloud Build-Triggern können Sie die Builds und Bereitstellungen Ihrer Cloud Run-Dienste automatisieren.

Kontinuierliche Bereitstellung einrichten

Sie können auch Cloud Deploy verwenden, um eine CD-Pipeline (Continuous Delivery) zum Bereitstellen von Cloud Run-Diensten in mehreren Umgebungen einzurichten.

Anwendung mit Cloud Deploy in Cloud Run bereitstellen