Cloud Run-Dienst, ‑Job oder ‑Worker-Pool bereitstellen

In diesem Dokument wird beschrieben, wie Sie Ihre Anwendungen bereitstellen, einschließlich Cloud Run-Dienste, Cloud Run-Jobs und Cloud Run-Worker-Pools. Cloud Run-Worker-Pools sind in der Vorschau verfügbar.

Mit Cloud Deploy können Sie Ihre containerbasierten Arbeitslasten in jedem Cloud Run-Dienst, -Job oder -Worker-Pool bereitstellen. Alle Cloud Deploy-Funktionen werden unterstützt, wenn Sie in Cloud Run-Zielen für Cloud Run-Dienste oder -Worker-Pools bereitstellen. Canary-Bereitstellungen werden jedoch für Cloud Run-Jobs nicht unterstützt.

In diesem Dokument werden die drei Hauptkonfigurationen beschrieben, die Sie ausführen müssen, um in Cloud Run bereitzustellen:

Beschränkungen

  • Sie können nur einen Cloud Run-Dienst, -Job oder -Worker-Pool pro Ziel bereitstellen.

  • Sie können keine Canary-Bereitstellung für einen Cloud Run-Job ausführen.

    Für Cloud Run-Dienste und -Worker-Pools ist jedoch eine Canary-Bereitstellung möglich.

  • Wenn Sie eine Cloud Run-Funktion mit Cloud Deploy bereitstellen möchten, müssen Sie Ihren CI-Workflow ändern, um die Funktion in einem Container zu erstellen und als Cloud Run-Dienst bereitzustellen.

  • Cloud Run-Worker-Pools sind in der Vorschau verfügbar.

Hinweis

Erstellen Sie Ihre Zielkonfiguration

Das Ziel kann in der YAML-Datei der Bereitstellungspipeline konfiguriert werden oder sich in einer separaten Datei befinden. Außerdem können Sie in derselben Datei mehrere Ziele konfigurieren.

Ziele müssen im selben Projekt und in derselben Region wie die Bereitstellungspipeline definiert werden. Die Dienste, Jobs oder Worker-Pools, in denen die Ziele bereitgestellt werden, können sich jedoch in verschiedenen Projekten und Regionen befinden, sofern das Dienstkonto Zugriff auf diese Projekte hat.

Erstellen Sie in der Zieldefinition einen run-Abschnitt, um den Ort anzugeben, an dem der Cloud Run-Dienst erstellt wird.

Die Syntax zum Angeben des Cloud Run-Dienstes, -Jobs oder -Worker-Pools in der Zieldefinition lautet so:

run:
 location: projects/[project_name]/locations/[region_name]

Diese Ressourcen-ID verwendet die folgenden Elemente:

  • project_name ist der Name des Google Cloud Projekts, in dem Ihr Cloud Run-Dienst, -Job oder -Worker-Pool erstellt wird.

    Sie müssen dies für jedes Ziel tun. Wir empfehlen, für jeden Cloud Run-Dienst, -Job oder -Worker-Pool ein anderes Projekt zu verwenden. Wenn Sie mehrere Dienste, Jobs oder Worker-Pools im selben Projekt verwenden möchten, müssen Sie Skaffold-Profile in Ihrer skaffold.yaml Konfigurationsdatei verwenden.

  • region_name ist die Region, in der der Dienst, Job oder Worker-Pool erstellt wird. Ihr Dienst, Job oder Worker-Pool kann sich in jeder Region befinden, die von Cloud Run unterstützt wird.

Das folgende Beispiel zeigt eine Zielkonfiguration, in der der zu erstellende Cloud Run-Dienst, -Job oder -Worker-Pool definiert wird:

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development service
      run:
       location: projects/my-app/locations/us-central1

Sie können dieses Ziel in einer Cloud Deploy-Bereitstellungspipelinedefinition oder separat definieren. In beiden Fällen müssen Sie das Ziel registrieren, bevor Sie den Release erstellen, um den Cloud Run-Dienst, den Job oder den Worker-Pool bereitzustellen.

Skaffold-Konfiguration erstellen

Das folgende Beispiel zeigt eine Beispiel skaffold.yaml Datei für eine Cloud Run-Bereitstellung:

apiVersion: skaffold/v4beta7
kind: Config
metadata: 
  name: cloud-run-application
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}

In dieser skaffold.yaml-Datei…

  • manifests.rawYaml enthält die Namen der Cloud Run-Dienstdefinitionen.

    In diesem Beispiel ist service.yaml die Datei, die einen Cloud Run-Dienst definiert, der von Skaffold bereitgestellt wird. Dieser Dateiname kann beliebig sein, aber üblicherweise wird service.yaml für einen Dienst, job.yaml für einen Job und workerpool.yaml für einen Worker-Pool verwendet.

  • Der Abschnitt deploy gibt an, wie das Manifest bereitgestellt werden soll, insbesondere das Projekt und der Standort. deploy ist erforderlich.

    Wir empfehlen, die leeren {} beizubehalten. Cloud Deploy füllt diese während des Renderings basierend auf dem Projekt und dem Standort aus der Zieldefinition aus.

    Für die lokale Entwicklung können Sie hier jedoch Werte angeben. Cloud Deploy verwendet jedoch immer das Projekt und den Standort aus der Zieldefinition, unabhängig davon, ob hier Werte angegeben werden.

Cloud Run-Dienstdefinitionen erstellen

Wenn Sie eine Cloud Run-Dienstdefinition erstellen möchten, können Sie sie entweder manuell erstellen oder aus einem vorhandenen Dienst kopieren. Beide Optionen werden in diesem Abschnitt beschrieben.

Option 1: Neue service.yaml-Datei für Cloud Run erstellen

Die Datei „service.yaml“ definiert Ihren Cloud Run-Dienst. Wenn Sie einen Release erstellen, verwendet Skaffold diese Definition, um Ihren Dienst bereitzustellen.

Hier ein vereinfachtes Beispiel:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: [SERVICE_NAME]
spec:
 template:
  spec:
   containers:
   - image: [IMAGE_PATH]

Wobei:

  • [SERVICE_NAME] ist ein Name für diesen Cloud Run-Dienst.

  • [IMAGE_PATH] verweist auf das oder die Container-Images, die Sie mit diesem Dienst bereitstellen.

Option 2: service.yaml-Datei aus einem vorhandenen Dienst mit der Google Cloud Console kopieren

Sie können einen Dienst mit der Google Cloud Console erstellen oder einen vorhandenen Dienst verwenden, und Ihre service.yaml von dort kopieren.

So rufen Sie die Datei service.yaml mit der Google Cloud CLI ab:

gcloud run services describe [service_name] --format=export

So rufen Sie die Datei service.yaml über die Google Cloud Console ab:

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Run-Dienste auf.

  2. Wählen Sie den vorhandenen Dienst aus, dessen Definition Sie verwenden möchten.

Alternativ können Sie einen neuen Dienst erstellen und ihn dann auswählen. Wenn Sie den Dienst auswählen, wird die Seite „Servicedetails“ angezeigt:

Seite „Dienstdetails“ in derGoogle Cloud -Konsole mit dem Tab „YAML“

  1. Wählen Sie den Tab YAML aus.

  2. Klicken Sie auf Bearbeiten und kopieren Sie dann den Inhalt der YAML-Datei in eine neue Datei mit dem Namen service.yaml in Ihrem Dateisystem, damit Skaffold sie verwenden kann, wenn Sie ein Release erstellen.

Cloud Run-Jobdefinitionen erstellen

Wenn Sie eine Cloud Run-Jobdefinition bereitstellen möchten, können Sie sie entweder manuell erstellen oder aus einem vorhandenen Job kopieren. Beide Optionen werden in diesem Abschnitt beschrieben.

Beachten Sie, dass Jobs nicht unbedingt ausgeführt werden, nachdem sie von Cloud Deploy bereitgestellt wurden. Das unterscheidet sich von Diensten, die nach der Bereitstellung Anwendungen ausführen. Wie ein Job aufgerufen wird, hängt vom Job selbst ab.

Option 1: Neue job.yaml-Datei für Cloud Run erstellen

Die Datei „job.yaml“ definiert Ihren Cloud Run-Job. Wenn Sie einen Release erstellen, verwendet Skaffold diese Definition, um den Job bereitzustellen.

Hier ein vereinfachtes Beispiel:

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
 name: [JOB_NAME]
spec:
  template:
  spec:
   containers:
   - image: [IMAGE_PATH]

Wobei:

  • [JOB_NAME] ist ein Name für diesen Cloud Run-Job.

  • [IMAGE_PATH] verweist auf das Container-Image, das Sie für diesen Job bereitstellen.

Option 2: job.yaml aus einem vorhandenen Job mit der Google Cloud Console kopieren

Sie können einen Job mit der Google Cloud Console erstellen oder einen vorhandenen Job verwenden, und die Datei job.yaml von dort kopieren.

So rufen Sie die Datei job.yaml mit der Google Cloud CLI ab:

gcloud run jobs describe [job_name] --format=export

So rufen Sie die Datei job.yaml über die Google Cloud Console ab:

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Run-Jobs auf.

  2. Wählen Sie den vorhandenen Job aus, dessen Definition Sie verwenden möchten.

Alternativ können Sie einen neuen Job erstellen und ihn dann auswählen. Wenn Sie den Job auswählen, wird die Seite „Jobdetails“ angezeigt:

Seite mit Jobdetails
Google Cloud -Konsole mit dem Tab „YAML“

  1. Wählen Sie den Tab YAML aus.

  2. Klicken Sie auf Bearbeiten und kopieren Sie dann den Inhalt der YAML-Datei in eine neue Datei mit dem Namen job.yaml in Ihrem Dateisystem, damit Skaffold sie beim Erstellen eines Release verwenden kann.

Cloud Run-Worker-Pool-Definitionen erstellen (Vorschau)

Wenn Sie eine Cloud Run-Worker-Pool-Definition bereitstellen möchten, können Sie sie entweder manuell erstellen oder aus einem vorhandenen Worker-Pool kopieren. Beide Optionen werden in diesem Abschnitt beschrieben.

Option 1: Neue workerpool.yaml-Datei für Cloud Run erstellen

Die Datei „workerpool.yaml“ definiert Ihren Cloud Run-Worker-Pool. Wenn Sie einen Release erstellen, verwendet Skaffold diese Definition, um den Worker-Pool bereitzustellen.

Hier ein vereinfachtes Beispiel:

apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
 name: [WORKERPOOL_NAME]
 annotations:
  run.googleapis.com/launch-stage: BETA
spec:
  template:
   spec:
    containers:
    - image: [IMAGE_PATH]

Wobei:

  • [WORKERPOOL_NAME] ist ein Name für diesen Cloud Run-Worker-Pool.

  • [IMAGE_PATH] verweist auf das Container-Image, das Sie für diesen Worker-Pool bereitstellen.

Option 2: workerpool.yaml-Datei aus einem vorhandenen Worker-Pool mit der Google Cloud Console kopieren

Sie können einen Worker-Pool mit der Google Cloud Console erstellen oder einen vorhandenen Worker-Pool verwenden, und die Datei workerpool.yaml von dort kopieren.

So rufen Sie die Datei workerpool.yaml mit der Google Cloud CLI ab:

gcloud beta run worker-pools describe [workerpool_name] --format=export

So rufen Sie die Datei workerpool.yaml über die Google Cloud Console ab:

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Run-Worker-Pools auf.

  2. Wählen Sie den vorhandenen Worker-Pool aus, dessen Definition Sie verwenden möchten.

Alternativ können Sie einen neuen Worker-Pool erstellen und ihn dann auswählen. Wenn Sie den Worker-Pool auswählen, wird die Seite „Details des Worker-Pools“ angezeigt:

Seite mit Worker-Pool-Details
Google Cloud -Konsole mit dem Tab „YAML“

  1. Wählen Sie den Tab YAML aus.

  2. Kopieren Sie den Inhalt der YAML-Datei in eine neue Datei mit dem Namen workerpool.yaml, in Ihrem Dateisystem, damit Skaffold sie verwenden kann, wenn Sie ein Release erstellen.

Zusammenfassung

Nachdem Sie die Definition für Ihren Cloud Run-Dienst, -Job oder -Worker-Pool, die skaffold.yaml Konfiguration und die Cloud Deploy-Ziel definition erstellt und Ihr Ziel als Cloud Deploy-Ressource registriert haben, können Sie jetzt Ihre Bereitstellungspipeline aufrufen , um einen Release zu erstellen und ihn durch die in der Pipeline definierten Ziele zu leiten.

In der Kurzanleitung Anwendung mit Cloud Deploy in Cloud Run bereitstellen wird dies alles in der Praxis gezeigt.

Verhalten von Diensten über verschiedene Überarbeitungen hinweg

Wenn Sie einen Dienst noch einmal bereitstellen, basiert die neue Überarbeitung auf der neu bereitgestellten Datei service.yaml. Nichts von der vorherigen Überarbeitung wird beibehalten, es sei denn, es ist in der neu bereitgestellten YAML-Datei identisch. Wenn beispielsweise Konfigurationseinstellungen oder Labels in der vorherigen Überarbeitung vorhanden sind, die nicht in der neuen YAML-Datei enthalten sind, fehlen diese Einstellungen oder Labels in der neuen Überarbeitung.

Cloud Run-Jobs auslösen

Nachdem Sie einen Job bereitgestellt haben, können Sie ihn wie beschrieben in der Cloud Run-Dokumentationauslösen.

Cloud Run-Dienste, -Jobs und -Worker-Pools in mehreren Projekten bereitstellen

Wenn Sie Dienste, Jobs oder Worker-Pools bereitstellen müssen, die sich in verschiedenen Projekten befinden, benötigt Ihr Ausführungsdienstkonto die Berechtigung für den Zugriff auf die Projekte, in denen diese Dienste, Jobs oder Worker-Pools definiert sind.

Weitere Informationen finden Sie unter Cloud Deploy-Ausführungsdienstkonto und Rollen und Berechtigungen für Identity and Access Management.

Cloud Run-Funktionen bereitstellen

Cloud Run Functions erstellt Ihren Quellcode jedes Mal, wenn eine Funktion bereitgestellt wird. Aus diesem Grund kann jedes Ziellaufzeit in Ihrer Pipeline ein etwas anderes Artefakt erhalten. Das widerspricht den Best Practices in Cloud Deploy. Stattdessen empfehlen wir, direkt einen Cloud Run-Dienst zu verwenden. So können Sie ein einzelnes Artefakt erstellen und es in Ihren Umgebungen verwenden.

  1. Checken Sie die Datei service.yaml für Ihre Cloud Run-Funktion ein.

    Sie können sie mit dem folgenden Befehl abrufen:

    gcloud run services describe FUNCTION_NAME \
    --format=export \
    --region=REGION \
    --project=PROJECT
    
  2. Entfernen Sie die folgenden Annotationen, falls vorhanden:

    • run.googleapis.com/build-base-image
    • run.googleapis.com/build-name
    • run.googleapis.com/build-source-location
    • run.googleapis.com/build-enable-automatic-updates
  3. Ersetzen Sie den Wert in spec.spec.containers.image durch IMAGE_TAG.

  4. Erstellen Sie Ihre Bereitstellungspipeline und Ziele, mit dem Cloud Run-Dienst als Ziel.

  5. Trennen Sie den Build-Schritt vom Bereitstellungsschritt in Ihrem CI-Prozess. Ersetzen Sie die Google Cloud CLI zum Bereitstellen Ihrer Funktion durch die folgenden Schritte:

    1. Erstellen Sie die Funktion mit Cloud Build in einem Container:

      gcloud builds submit --pack image=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME \
      --project=PROJECT \
      --region=REGION
      
    2. Erstellen Sie einen Release mit Cloud Deploy:

      gcloud deploy releases create RELEASE_NAME \
      --project=DEPLOY_PROJECT \
      --region=REGION \
      --delivery-pipeline=DELIVERY_PIPELINE \
      --images=IMAGE_TAG=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME
      

      In diesem Befehl…

      • RELEASE_NAME ist ein Name für diesen Release. Der Name muss unter allen Releases für diese Bereitstellungspipeline eindeutig sein.

      • DEPLOY_PROJECT ist die Projekt-ID des Projekts, in dem Sie die Bereitstellungspipeline erstellt haben.

      • DELIVERY_PIPELINE ist der Name der Bereitstellungspipeline, die die Bereitstellung dieses Release in der Abfolge der Ziele verwaltet. Dieser Name muss mit dem name Feld in der Pipelinedefinition übereinstimmen.

      • REGION ist der Name der Region, in der Sie den Release erstellen, z. B. us-central1. Das ist ein Pflichtfeld.

      • IMAGE_NAME ist der Name, den Sie dem Image im vorherigen Schritt gegeben haben, als Sie die Funktion erstellt haben.

Nächste Schritte