Hooks vor und nach der Bereitstellung ausführen

In diesem Dokument wird beschrieben, wie Sie beliebige Programme oder Vorgänge vor oder nach der Bereitstellung ausführen.

Sie können Cloud Deploy so konfigurieren, dass Aktionen vor der Bereitstellung, nach der Bereitstellung oder beides ausgeführt werden. So ausgeführte Programme werden als „Hooks“ bezeichnet. Pre-Deploy- und Post-Deploy-Hooks werden als Pre-Deploy- und Post-Deploy-Jobs für den Roll-out ausgeführt.

Sie können jeden Hook so konfigurieren, dass er in einer bestimmten Ausführungsumgebung von Cloud Deploy ausgeführt wird. Wenn Sie jedoch in Google Kubernetes Engine bereitstellen, können Sie ihn optional so konfigurieren, dass er im GKE-Cluster ausgeführt wird, in dem Sie Ihre Anwendung bereitstellen.

Es wird davon ausgegangen, dass Bereitstellungshooks idempotent sind. Wenn eine bestimmte Aktion mehrmals ausgeführt wird, hat das keine zusätzlichen Auswirkungen.

Wie funktionieren Bereitstellungshooks?

Im Folgenden wird beschrieben, wie Bereitstellungshooks in Cloud Deploy ausgeführt werden und wie Sie sie einrichten:

Sie konfigurieren Hooks in einer oder mehreren Phasen Ihrer Lieferpipeline.
Bevor der Bereitstellungsjob des Rollouts ausgeführt wird, führt Cloud Deploy alle Aufgaben aus, die in einer predeploy-Definition im Pipelineverlauf konfiguriert sind.

Der predeploy-Hook wird immer als erster Job in der Phase ausgeführt.
Nachdem der Bereitstellungsjob des Rollouts ausgeführt wurde, führt Cloud Deploy alle Aufgaben aus, die in einer postdeploy-Definition im Pipelineverlauf konfiguriert sind.

Hinweis :Wenn für die Phase ein verify-Job konfiguriert ist, wird die Überprüfung vor dem postdeploy-Job ausgeführt.

Deploy-Hooks werden in der Ausführungsumgebung von Cloud Deploy ausgeführt.

Bereitstellungshooks mit einer Canary-Bereitstellung verwenden

Wenn Sie Bereitstellungshooks für eine Canary-Bereitstellung konfigurieren, sollten Sie Folgendes beachten:

In der Phase der Bereitstellungspipeline befindet sich die Konfiguration des Hooks (predeploy und postdeploy) unter strategy.canary.canaryDeployment oder strategy.canary.customCanaryDeployment.phaseConfigs und nicht unter strategy.standard.
Bei einem automatisierten Canary-Release werden predeploy-Hooks nur vor dem Deployment in der ersten Phase und postdeploy-Hooks nur nach dem Deployment in der letzten Phase (stabil) ausgeführt.

Pipeline für die Ausführung von Hooks konfigurieren

Sie konfigurieren Pre- und Post-Deploy-Hooks in einer oder mehreren bestimmten Phasen der Pipelineprogression.

So konfigurieren Sie Pre- und Post-Deploy-Hooks in einer Pipelinephase, wenn Sie eine standard-Bereitstellungsstrategie verwenden:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          tasks: [TASKS]
        postdeploy:
          tasks: [TASKS]

In diesem YAML-Code gilt:

TASKS

Eine Liste mit einem oder mehreren Tasks, die als Teil Ihrer Pre-Deploy- oder Post-Deploy-Hooks ausgeführt werden sollen. Wenn Sie mehrere Aufgaben angeben, werden sie seriell in der Reihenfolge ausgeführt, in der sie angegeben sind. Der Job (vor oder nach der Bereitstellung) schlägt bei der ersten Aufgabe fehl, die fehlschlägt, und die verbleibenden Aufgaben werden nicht ausgeführt.

Hooks im Anwendungscluster ausführen

Standardmäßig werden Bereitstellungshooks in der Ausführungsumgebung von Cloud Deploy ausgeführt. Sie können Skaffold auch so konfigurieren, dass Deploy-Hooks auf demselben Cluster ausgeführt werden, auf dem Ihre Anwendung ausgeführt wird.

Wenn Sie Hooks im Anwendungscluster ausführen möchten, müssen Sie sie in Ihrer skaffold.yaml als customActions konfigurieren und in der predeploy- oder postdeploy-Anweisung in der Konfiguration der Bereitstellungspipeline-Phase mit actions referenzieren:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["my-predeploy-action"]
        postdeploy:
          actions: ["my-postdeploy-action"]

verwenden.

Diese Funktion ist nur für Bereitstellungen in GKE verfügbar, nicht für Cloud Run. Bei Bereitstellungen in Cloud Run können Hooks nur in der Cloud Deploy-Ausführungsumgebung ausgeführt werden.

Wenn Sie Ihren Hook so konfigurieren möchten, dass er im Cluster ausgeführt wird, fügen Sie in Ihrer skaffold.yaml-Konfigurationsdatei einen executionMode.kubernetesCluster-Abschnitt in den customActions-Abschnitt für jede Aktion ein, die Sie im Cluster ausführen möchten:

customActions:
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]
  executionMode:
    kubernetesCluster: {}

Hier sehen Sie ein Beispiel für einen customActions-Abschnitt, der executionMode enthält, um den Hook-Container im Anwendungscluster aufzurufen:

customActions:
- name: predeploy-action
  containers:
  - name: predeploy-echo
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", 'echo "this is a predeploy action"' ]
  executionMode:
    kubernetesCluster: {}

Der executionMode-Abschnitt ist optional. Wenn Sie ihn weglassen, führt Skaffold den benutzerdefinierten Aktionscontainer in der Cloud Deploy-Ausführungsumgebung aus.

Verfügbare Umgebungsvariablen

Cloud Deploy stellt außerdem die folgenden Umgebungsvariablen in der Ausführungsumgebung bereit und füllt sie aus. Sie können diese Umgebungsvariablen als Teil Ihres Bereitstellungshooks, Bestätigungsjobs oder benutzerdefinierten Zielrenders oder ‑bereitstellung verwenden.

ANTHOS_MEMBERSHIP

Für Ziele vom Typ ANTHOS der vollständig angegebene Ressourcenname der Anthos-Mitgliedschaft.
CLOUD_RUN_LOCATION

Für Ziele vom Typ RUN die Region, in der der Cloud Run-Dienst bereitgestellt wird.
CLOUD_RUN_PROJECT

Für Ziele vom Typ RUN das Projekt, in dem der Cloud Run-Dienst erstellt wurde.
CLOUD_RUN_SERVICE

Für Ziele vom Typ RUN der Name des bereitgestellten Cloud Run-Dienstes.
CLOUD_RUN_SERVICE_URLS

Für Ziele vom Typ RUN die URL oder URLs (durch Kommas getrennte Liste), über die Endnutzer auf Ihren Dienst zugreifen. Sie finden diese in den Cloud Run-Dienstdetails für Ihren Dienst in derGoogle Cloud -Konsole. Die URLs werden von Cloud Run generiert, nachdem Ihr Cloud Run-Dienst oder Ihre Cloud Run-Dienste erfolgreich bereitgestellt wurden. Daher ist diese Umgebungsvariable nur in Post-Deploy-Hooks und Bestätigungsjobs verfügbar.
CLOUD_RUN_REVISION

Für Ziele des Typs RUN die spezifische Revision des Cloud Run-Dienstes.
GKE_CLUSTER

Für Ziele vom Typ GKE ist dies der vollständig angegebene Ressourcenname des Google Kubernetes Engine-Clusters, z. B. projects/p/locations/us-central1/clusters/dev.
TARGET_TYPE

Der spezifische Laufzeittyp des Ziels. Entweder GKE, ANTHOS oder RUN. Bei benutzerdefinierten Zielvorhaben wird dieser Wert nicht festgelegt.
CLOUD_DEPLOY_LOCATION

Die Region, die die Cloud Deploy-Ressourcen enthält.
CLOUD_DEPLOY_DELIVERY_PIPELINE

Die ID der Bereitstellungspipeline.
CLOUD_DEPLOY_TARGET

Die ID des Ziels.
CLOUD_DEPLOY_PROJECT

Die Google Cloud Projektnummer für das Projekt, das die Cloud Deploy-Ressourcen enthält.
CLOUD_DEPLOY_PROJECT_ID

Die Google Cloud Projekt-ID für das Projekt.
CLOUD_DEPLOY_RELEASE

Die ID des Releases, in dem die Hooks ausgeführt werden.
CLOUD_DEPLOY_ROLLOUT

Die ID des Roll-outs, der die Jobs für die Hooks enthält.
CLOUD_DEPLOY_JOB_RUN

Die ID des Joblaufs, der die aktuelle Ausführung des Jobs darstellt.
CLOUD_DEPLOY_PHASE

Die Phase im Rollout, die den Job für den Bereitstellungshook, den Bestätigungsjob oder das benutzerdefinierte Rendern oder Bereitstellen enthält.

Parameter als Umgebungsvariablen bereitstellen

Zusätzlich zu den in diesem Abschnitt aufgeführten Umgebungsvariablen kann Cloud Deploy alle von Ihnen festgelegten Bereitstellungsparameter an Ihre benutzerdefinierten Container übergeben.

Weitere Informationen