Worker-Pools in Cloud Run bereitstellen

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

Worker-Pools sind eine Cloud Run-Ressource, die speziell für die Ausführung kontinuierlicher Hintergrundarbeiten entwickelt wurde. Im Gegensatz zu Cloud Run-Diensten verfügen Worker-Pools nicht über einen Load-Balancing-Endpunkt/eine Load-Balancing-URL und unterstützen keine automatische Skalierung.

Eine Beispielanleitung für die Bereitstellung eines neuen Worker-Pools finden Sie unter Kurzanleitung für die Bereitstellung eines Beispiel-Worker-Pools.

Erforderliche Rollen

Um die Berechtigungen zu erhalten, die Sie zum Bereitstellen von Cloud Run-Workerpools benötigen, bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen:

  • Cloud Run Developer (roles/run.developer) im Cloud Run-Workerpool
  • Dienstkontonutzer (roles/iam.serviceAccountUser) für die Identität, die von Ihren Worker-Pools für die Interaktion mit anderen Google Cloud -Diensten verwendet wird
  • Artifact Registry Reader (roles/artifactregistry.reader) im Artifact Registry-Repository des bereitgestellten Container-Images

Eine Liste der IAM-Rollen und -Berechtigungen im Zusammenhang mit Cloud Run finden Sie unter IAM-Rollen für Cloud Run und IAM-Berechtigungen für Cloud Run. Wenn Ihr Cloud Run-Workerpool mitGoogle Cloud -APIs wie Cloud-Clientbibliotheken verknüpft ist, lesen Sie die Konfigurationsanleitung für Dienstidentitäten. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Bereitstellungsberechtigungen und Zugriff verwalten.

Unterstützte Container Registries und Images

Sie können direkt in Artifact Registry gespeicherte Container-Images oder öffentliche Images aus Docker Hub oder der GitHub Container Registry verwenden. Google empfiehlt die Verwendung von Artifact Registry. Öffentliche Images aus GitHub Container Registry und Docker Hub-Images werden bis zu einer Stunde lang im Cache gespeichert.

Sie können Container-Images aus anderen öffentlichen oder privaten Registries (z. B. JFrog Artifactory oder Nexus) oder private Images aus der GitHub Container Registry verwenden. Dazu richten Sie ein Remote-Repository von Artifact Registry ein.

Sie sollten Docker Hub nur für die Bereitstellung gängiger Container-Images wie Offizielle Docker-Images oder Docker gesponserte OSS-Images in Betracht ziehen. Für eine höhere Verfügbarkeit empfiehlt Google, diese Docker Hub- oder GitHub Container Registry-Images über ein Artifact Registry-Remote-Repository bereitzustellen.

Cloud Run unterstützt keine Container-Image-Layer, die größer als 9,9 GB sind, wenn von Docker Hub oder einem Artifact Registry Remote-Repository mit einer externen Registry bereitgestellt wird.

Worker-Pools bereitstellen

Sie haben folgende Möglichkeiten, Worker-Pools bereitzustellen:

Neuen Worker-Pool 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.

Beim erstmaligen Einsatz eines Worker-Pools wird dessen erste Revision 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 bedient anschließend immer diesen speziellen Digest.

Folgen Sie der Anleitung für die Google Cloud -Konsole, die Google Cloud CLI, Terraform oder die REST API:

Console

  1. Rufen Sie in der Google Cloud Console Cloud Run auf:

    Zu Cloud Run

  2. Wählen Sie im Menü Worker pools aus und klicken Sie auf Deploy container, um das Formular Create worker pool anzuzeigen.

    1. Geben Sie im Formular das Container-Image an.

    2. Geben Sie den Namen des Worker-Pools ein. Die Namen der Mitarbeiterpools dürfen maximal 49 Zeichen lang sein und müssen pro Region und Projekt eindeutig sein. Sie können nicht denselben Namen wie ein vorhandener Dienstname aus Ihrem Projekt verwenden. Ein Workerpool-Name kann später nicht mehr geändert werden und ist öffentlich sichtbar.

    3. Wählen Sie die Region aus, in der sich Ihr Worker befinden soll. Die Regionsauswahl gibt die Preisstufe an und hebt Regionen mit den niedrigsten CO2-Auswirkungen hervor.

    4. Geben Sie unter Skalierung die Anzahl der Instanzen für den Worker-Pool an.

  3. Klicken Sie auf Container, Netzwerk, Sicherheit, um weitere optionale Einstellungen auf den entsprechenden Tabs festzulegen:

  4. Wenn Sie die Konfiguration Ihres Worker-Pools abgeschlossen haben, klicken Sie auf Erstellen, um das Image in Cloud Run bereitzustellen. Warten Sie, bis das Deployment abgeschlossen ist.

gcloud

  1. 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.

  2. So stellen Sie ein Container-Image für einen Worker-Pool bereit:

    1. Führen Sie dazu diesen Befehl aus: 

      gcloud run worker-pools deploy WORKER_POOL --image IMAGE_URL

      Ersetzen Sie Folgendes:

      • WORKER_POOL: der Name des Worker-Pools, in dem Sie die Bereitstellung vornehmen möchten. Falls der Worker-Pool noch nicht existiert, erstellt dieser Befehl den Worker-Pool während der Bereitstellung. Sie können diesen Parameter auch weglassen, werden dann jedoch nach dem Namen des Worker-Pools gefragt. Die Namen der Workerpools dürfen maximal 49 Zeichen lang sein, müssen pro Region und Projekt einen eindeutigen Namen verwenden und dürfen nicht mit einem vorhandenen Dienstnamen aus Ihrem Projekt übereinstimmen.
      • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest. Wenn Sie das Flag --image nicht angeben, wird mit dem Bereitstellungsbefehl versucht, aus dem Quellcode bereitzustellen.

    2. Warten Sie, bis die Bereitstellung abgeschlossen ist. Nach erfolgreichem Abschluss wird in Cloud Run eine Erfolgsmeldung zusammen mit den Revisionsinformationen zum bereitgestellten Worker-Pool angezeigt.

      Um die Bereitstellung an einem anderen Ort als dem mit den Eigenschaften run/region gcloud festgelegten Ort durchzuführen, verwenden Sie:

      gcloud run worker-pools deploy WORKER_POOL --region REGION

YAML

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

  1. Erstellen Sie eine neue Datei vom Typ worker-pool.yaml mit folgendem Inhalt:

    apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
  name: WORKER_POOL
spec:
  template:
    spec:
      containers:
      - image: IMAGE

    Ersetzen Sie Folgendes:

    • WORKER_POOL: Der Name Ihres Cloud Run-Worker-Pools.
    • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest.

    Sie können auch weitere Konfigurationen angeben, z. B. Umgebungsvariablen oder Speicherlimits.

  2. Stellen Sie den neuen Worker-Pool mit dem folgenden Befehl bereit:

    gcloud run worker-pools replace worker-pool.yaml

    Der Befehl gcloud run worker-pools replace verwendet standardmäßig die Datei worker-pool.yaml, sofern sie vorhanden ist.

Terraform

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

resource "google_cloud_run_v2_worker_pool" "default" {
  name     = "WORKER_POOL"
  location = "REGION"

  template {
    containers {
      image = "IMAGE_URL"
    }
  }
}

Ersetzen Sie Folgendes:

  • WORKER_POOL: der Name des Worker-Pools.
  • REGION: die Google Cloud Region, z. B. europe-west1.
  • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest.

REST API

Senden Sie zum Bereitstellen eines neuen Worker-Pools eine POST-HTTP-Anfrage an den Endpunkt create der Cloud Run Admin API für Worker-Pools.

Verwenden Sie zum Beispiel curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X POST \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/workerPools?workerPoolId=WORKER_POOL

Ersetzen Sie Folgendes:

  • ACCESS_TOKEN: ein gültiges Zugriffstoken für ein Konto, das über die IAM-Berechtigungen zum Bereitstellen von Diensten verfügt. Wenn Sie beispielsweise in gcloud angemeldet sind, können Sie ein Zugriffstoken mit gcloud auth print-access-token abrufen. Innerhalb einer Cloud Run-Containerinstanz können Sie ein Zugriffstoken über den Metadatenserver der Containerinstanz abrufen.
  • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest.
  • REGION: die Google Cloud Region, z. B. europe-west1.
  • PROJECT_ID: die Google Cloud Projekt-ID.
    • WORKER_POOL: der Name des Worker-Pools.

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 ist. Sie sollten dabei jedoch auch den Standort der anderen Google Cloud-Produkte berücksichtigen, die der Cloud Run-Dienst verwendet. Die gemeinsame Nutzung von Google Cloud Produkten an mehreren Standorten kann sich auf die Latenz und die Kosten Ihres Dienstes auswirken.

Cloud Run ist in diesen Regionen verfügbar:

Unterliegt Preisstufe 1

Unterliegt Preisstufe 2

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

Neue Version eines vorhandenen Worker-Pools bereitstellen

Beachten Sie, dass beim Ändern von Konfigurationseinstellungen für einen Worker-Pool 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.

Das Container-Image wird von Cloud Run importiert, wenn es bereitgestellt wird. Cloud Run speichert diese Kopie des Container-Images so lange, wie es von einer Revision verwendet wird.

Folgen Sie diesen Anweisungen mithilfe von Google Cloud console, der Google Cloud CLI, Terraform oder der REST API:

Console

  1. Rufen Sie in der Google Cloud Console Cloud Run auf:

    Zu Cloud Run

  2. Wählen Sie im Menü Worker-Pools aus, wählen Sie den Worker-Pool aus, den Sie aktualisieren möchten, und klicken Sie dann auf Neue Überarbeitung bearbeiten und bereitstellen, um das Formular Worker-Pool-Überarbeitung bereitstellen aufzurufen.

    1. Geben Sie bei Bedarf die URL des neu bereitzustellenden Container-Images an.

    2. Konfigurieren Sie den Container nach Bedarf.

    3. Aktualisieren Sie gegebenenfalls die Anzahl der Instanzen für den Worker-Pool.

  3. Klicken Sie bei Bedarf auf Container, Netzwerk, Sicherheit, um weitere optionale Einstellungen auf den entsprechenden Tabs festzulegen:

  4. Wenn Sie die Aktualisierung Ihres Worker-Pools abgeschlossen haben, klicken Sie auf Deploy.

gcloud

  1. 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.

  2. So stellen Sie ein Container-Image bereit:

    1. Führen Sie diesen Befehl aus: 

      gcloud run worker-pools deploy WORKER_POOL --image IMAGE_URL

      Ersetzen Sie Folgendes:

      • WORKER_POOL: der Name des Worker-Pools, in dem Sie die Bereitstellung vornehmen möchten. Falls der Worker-Pool noch nicht existiert, erstellt dieser Befehl den Worker-Pool während der Bereitstellung. Sie können diesen Parameter auch weglassen, werden dann jedoch nach dem Namen des Worker-Pools gefragt. Die Namen der Workerpools dürfen maximal 49 Zeichen lang sein, müssen pro Region und Projekt einen eindeutigen Namen verwenden und dürfen nicht mit einem vorhandenen Dienstnamen aus Ihrem Projekt übereinstimmen.
      • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest. Wenn Sie das Flag --image nicht angeben, wird mit dem Bereitstellungsbefehl versucht, aus dem Quellcode bereitzustellen.

      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 in Cloud Run eine Erfolgsmeldung zusammen mit den Revisionsinformationen zum bereitgestellten Worker-Pool angezeigt.

YAML

  1. Laden Sie die YAML-Konfiguration für den Worker-Pool herunter:

    gcloud run worker-pools describe WORKER_POOL --format export > worker-pool.yaml

  2. Nehmen Sie eine Änderung an der Konfigurationsdatei vor.

  3. Aktualisieren Sie den Worker-Pool mit dem folgenden Befehl:

    gcloud run worker-pools replace worker-pool.yaml

    Der Befehl gcloud run worker-pools replace verwendet standardmäßig die Datei worker-pool.yaml, sofern sie vorhanden ist.

Terraform

Stellen Sie sicher, dass Sie Terraform wie im Beispiel Bereitstellen eines neuen Worker-Pools beschrieben eingerichtet haben.

  1. Nehmen Sie eine Änderung an der Konfigurationsdatei vor.

  2. Wenden Sie die Terraform-Konfiguration an:

    terraform apply

    Bestätigen Sie, dass Sie die beschriebenen Aktionen anwenden möchten, indem Sie yes eingeben.

REST API

Senden Sie zum Bereitstellen eines neuen Worker-Pools eine PATCH-HTTP-Anfrage an den Endpunkt für Worker-Pools der Cloud Run Admin API.

Um eine neue Revision aus der Vorlage zu erstellen, auch wenn das System keine Änderungen gegenüber der zuvor bereitgestellten Revision erkennt, setzen Sie den Abfrageparameter forceNewRevision auf true.

Verwenden Sie zum Beispiel curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X PATCH \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/workerPools/WORKER_POOL>?forceNewRevision=true

Ersetzen Sie Folgendes:

  • ACCESS_TOKEN: ein gültiges Zugriffstoken für ein Konto, das über die IAM-Berechtigungen zum Bereitstellen von Diensten verfügt. Wenn Sie beispielsweise in gcloud angemeldet sind, können Sie ein Zugriffstoken mit gcloud auth print-access-token abrufen. Innerhalb einer Cloud Run-Containerinstanz können Sie ein Zugriffstoken über den Metadatenserver der Containerinstanz abrufen.
  • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest.
  • REGION: die Google Cloud Region, z. B. europe-west1.
  • PROJECT_ID: die Google Cloud Projekt-ID.
  • WORKER_POOL: der Name des Worker-Pools, in dem Sie die Bereitstellung vornehmen.

Konfiguration mit Probelauf validieren

Sie können Ihre Worker-Pool-Konfiguration überprüfen, ohne sie bereitzustellen oder Änderungen dauerhaft zu speichern, indem Sie das Flag --dry-run verwenden.

Wenn Sie das Flag --dry-run angeben, führt der Befehl die folgenden Aktionen aus:

  • Validiert die Konfiguration.
  • Umgeht den Build-Prozess, wenn Sie aus der Quelle bereitstellen.
  • Gibt eine Erfolgsmeldung für die Validierung aus.

So validieren Sie die Bereitstellung eines Worker-Pools:

gcloud beta run worker-pools deploy WORKER_POOL \
    --image IMAGE_URL \
    --dry-run

Ersetzen Sie Folgendes:

  • WORKER_POOL: der Name des Worker-Pools, in dem Sie die Bereitstellung vornehmen.
  • IMAGE_URL: ein 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 das Format LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.

Images aus anderen Google Cloud Projekten bereitstellen

Um Images aus anderen Google Cloud Projekten bereitzustellen, müssen Sie oder Ihr Administrator dem Bereitstellungskonto und dem Cloud Run-Dienstagenten die erforderlichen IAM-Rollen zuweisen.

Informationen zu den erforderlichen Rollen für das Deployer-Konto finden Sie unter Erforderliche Rollen.

So weisen Sie dem Cloud Run-Dienst-Agent die erforderlichen Rollen zu:

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

    Zur IAM-Seite

  2. Wählen Sie Von Google bereitgestellte Rollenzuweisungen einschließen aus.

  3. Kopieren Sie die E-Mail des Cloud Run-Dienst-Agents. Sie hat das Suffix @serverless-robot-prod.iam.gserviceaccount.com.

  4. Öffnen Sie das Projekt mit der gewünschten Container Registry.

    Zur IAM-Seite

  5. Klicken Sie auf Hinzufügen, um ein neues Hauptkonto hinzuzufügen.

  6. Fügen Sie in das Feld Neue Hauptkonten die zuvor kopierte E-Mail-Adresse des Dienstkontos ein.

  7. 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.

  8. Stellen Sie das Container-Image für das Projekt bereit, das den Cloud Run-Worker-Pool enthält.

Images aus anderen Registries bereitstellen

Um öffentliche oder private Container-Images bereitzustellen, die nicht in Artifact Registry oder Docker Hub gespeichert sind oder keine öffentlichen Images in GitHub Container Registry sind, richten Sie ein Artifact Registry-Remote-Repository ein.

Die Remote-Repositories von Artifact Registry ermöglichen Ihnen Folgendes:

  • Stellen Sie ein beliebiges öffentliches Container-Image bereit.
  • Container-Images aus privaten Repositories bereitstellen, für die eine Authentifizierung erforderlich ist, z. B. JFrog Artifactory oder Nexus

Wenn die Verwendung eines Remote-Repositorys in Artifact Registry nicht möglich ist, können Sie Container-Images vorübergehend in Artifact Registry herunter- und hochladen, indem Sie sie mit docker push in Cloud Run bereitstellen. Cloud Run importiert das Container-Image während der Bereitstellung. Danach können Sie das Image aus Artifact Registry löschen.

Mehrere Container (Sidecars) in einem Worker-Pool bereitstellen

Bei einer Cloud Run-Bereitstellung mit Sidecars gibt es einen Haupt-Worker-Pool-Container und einen oder mehrere Sidecar-Container. Die Sidecars können über einen Localhost-Port miteinander und mit dem Worker-Pool-Container kommunizieren. Der Localhost-Port variiert je nach den verwendeten Containern.

Sie können bis zu 10 Container pro Instanz bereitstellen, einschließlich des Worker-Pool-Containers. Alle Container innerhalb einer Instanz teilen sich denselben Netzwerk-Namespace und können außerdem Dateien über ein gemeinsam genutztes In-Memory-Volume austauschen.

Sie können festlegen, dass für alle Bereitstellungen eine bestimmte Sidecar-Datei verwendet werden muss, indem Sie benutzerdefinierte Organisationsrichtlinien erstellen.

Worker-Pool mit Sidecar-Containern bereitstellen

Folgen Sie dieser Anleitung und verwenden Sie die Google Cloud CLI, YAML oder Terraform, um mehrere Container in einem Cloud Run-Worker-Pool bereitzustellen:

gcloud

  1. 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.

  2. Führen Sie den folgenden Befehl aus, um mehrere Container in einem Worker-Pool bereitzustellen:

    gcloud run worker-pools deploy WORKER_POOL \
 --container WORKER_POOL_CONTAINER_NAME \
 --image='WORKER_POOL_IMAGE' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'

    Ersetzen Sie Folgendes:

    • WORKER_POOL: der Name des Worker-Pools, in dem Sie die Bereitstellung vornehmen. Wenn Sie diesen Parameter weglassen, werden Sie nach dem Namen des Worker-Pools gefragt.
    • WORKER_POOL_CONTAINER_NAME: Ein Name für den Worker-Pool-Container.
    • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest.
    • SIDECAR_CONTAINER_NAME: ein Name für den Sidecar-Container, z. B. sidecar.
    • SIDECAR_IMAGE: Ein 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 run worker-pools deploy WORKER_POOL \
  --container CONTAINER_1_NAME \
  --image='WORKER_POOL_IMAGE' \
  --set-env-vars=KEY=VALUE \
  --container SIDECAR_CONTAINER_NAME \
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N

  3. Warten Sie, bis die Bereitstellung abgeschlossen ist. Nach erfolgreichem Abschluss wird in Cloud Run eine Erfolgsmeldung angezeigt.

YAML

  1. Wenn Sie einen neuen Worker-Pool erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Worker-Pool aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:

    gcloud run worker-pools describe WORKER_POOL --format export > worker-pool.yaml

  2. Das folgende Beispiel enthält die YAML-Konfiguration:

    apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
  name: WORKER_POOL
spec:
  template:
    spec:
      containers:
      - name: CONTAINER_NAME
        image: IMAGE_URL
      containers:
      - name: SIDECAR_CONTAINER_NAME
        image: SIDECAR_IMAGE_URL

    Ersetzen Sie Folgendes:

    • WORKER_POOL: Der Name Ihres Cloud Run-Worker-Pools.
    • CONTAINER_NAME: ein Name für den Worker-Pool-Container.
    • IMAGE_URL: eine Referenz auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest
    • SIDECAR_CONTAINER_NAME: Ein Name für den Sidecar-Container, z. B. sidecar.
    • SIDECAR_CONTAINER_IMAGE: ein Verweis auf das Sidecar-Container-Image.

  3. Erstellen oder aktualisieren Sie den Worker-Pool mit dem folgenden Befehl:

    gcloud run worker-pools replace worker-pool.yaml

    Der Befehl gcloud run worker-pools replace verwendet standardmäßig die Datei worker-pool.yaml, sofern sie vorhanden ist.

Terraform

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

resource "google_cloud_run_v2_worker_pool" "default" {
  name     = "WORKER_POOL"
  location = "REGION"

  template {
    containers {
      name = "CONTAINER_NAME"
      image = "IMAGE_URL"
    }
    containers {
      name = "SIDECAR_CONTAINER_NAME"
      image = "SIDECAR_IMAGE_URL"
    }
  }
}

Ersetzen Sie Folgendes:

  • WORKER_POOL: der Name des Worker-Pools.
  • REGION: die Google Cloud Region, z. B. europe-west1.
  • CONTAINER_NAME: Der Name des Containers.
  • IMAGE_URL: Ein Verweis auf das Container-Image, das den Worker-Pool enthält, z. B. us-docker.pkg.dev/cloudrun/container/worker-pool:latest.
  • SIDECAR_CONTAINER_NAME: Der Name des Sidecar-Containers.
  • SIDECAR_IMAGE_URL: ein Verweis auf das Sidecar-Container-Image.

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, bevor der nächste Container gestartet wird. Ohne Healthchecks versucht Cloud Run, alle Container zu starten, selbst wenn die Container, von denen sie abhängen, noch nicht laufen oder der Start fehlgeschlagen ist.

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 Worker-Pool bereitgestellt haben, können Sie Folgendes tun: