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 Arbeitslasten ohne Anfragen entwickelt wurde. Im Gegensatz zu Cloud Run-Diensten haben Worker-Pools nicht die folgenden Funktionen:

• Öffentlicher Endpunkt/öffentliche URL
• Anforderung zum Freigeben eines Ingress-Ports
• Anfragebasiertes Autoscaling

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

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Bereitstellen von Cloud Run-Worker-Pools benötigen:

• Cloud Run-Entwickler (roles/run.developer) im Cloud Run-Worker-Pool
• 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-Leser (roles/artifactregistry.reader) für das 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 oder Docker Hub gespeicherte Container-Images verwenden. Google empfiehlt die Verwendung von Artifact Registry. Docker Hub-Images werden bis zu einer Stunde im Cache gespeichert.

Sie können Container-Images aus anderen öffentlichen oder privaten Registries (z. B. JFrog Artifactory, Nexus oder 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-Images über ein Artifact Registry-Remote-Repository bereitzustellen.

Cloud Run unterstützt keine Container-Image-Ebenen, die größer als 9,9 GB sind, wenn die Bereitstellung über Docker Hub oder ein Artifact Registry-Remote-Repository mit einer externen Registry erfolgt.

Worker-Pools bereitstellen

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

• Neuen Worker-Pool bereitstellen
• Vorhandenen Worker-Pool aktualisieren
• Images aus anderen Google Cloud Projekten bereitstellen
• Mehrere Container (Sidecars) in einem Worker-Pool bereitstellen

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.

Wenn Sie einen Worker-Pool zum ersten Mal bereitstellen, wird die 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 und verwenden Sie die Google Cloud CLI oder Terraform.

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

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

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 behält diese Kopie des Container-Images so lange bei, wie sie von einer Revision verwendet wird.

Folgen Sie dieser Anleitung und verwenden Sie die Google Cloud CLI oder Terraform:

Images aus anderen Google Cloud Projekten bereitstellen

Wenn Sie Images aus anderen Google Cloud -Projekten bereitstellen möchten, müssen Sie oder Ihr Administrator dem Bereitstellerkonto und dem Cloud Run-Dienst-Agenten die erforderlichen IAM-Rollen zuweisen.

Informationen zu den erforderlichen Rollen für das Bereitstellerkonto 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, 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, z. B. GitHub Container Registry (ghcr.io).
• 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

In 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 Dateien auch über ein freigegebenes In-Memory-Volume freigeben.

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

Dienst mit Sidecar-Containern bereitstellen

Folgen Sie dieser Anleitung, um mit der Google Cloud CLI oder Terraform mehrere Container in einem Cloud Run-Worker-Pool bereitzustellen:

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

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

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 Systemdiagnosen versucht Cloud Run, alle Container zu starten, auch wenn die Container, von denen sie abhängen, noch nicht ausgeführt werden oder nicht gestartet werden konnten.

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:

• Worker-Pool-Logs ansehen
• Worker-Pool-Leistung überwachen
• Speicherlimits festlegen
• Umgebungsvariablen festlegen
• Worker-Pool verwalten
• Versionen von Worker-Pools verwalten