Hooks vor und nach der Bereitstellung ausführen

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

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

Sie können jeden Hook so konfigurieren, dass er in einer bestimmten Cloud Deploy-Ausführungsumgebung ausgeführt wird. Wenn Sie die Bereitstellung in der Google Kubernetes Engine vornehmen, 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 Bereitstellungs-Hooks idempotent sind. Wenn eine Aktion mehrmals ausgeführt wird, hat das keine zusätzlichen Auswirkungen.

Wie funktionieren Deployment Hooks?

Im Folgenden werden die Schritte zum Konfigurieren von Bereitstellungshooks und der Ablauf zum Ausführen dieser Hooks mit Skaffold und Cloud Deploy beschrieben:

  1. Sie konfigurieren die für eine bestimmte Version verwendete skaffold.yaml so, dass sie customActions enthält, die das oder die Container-Images identifizieren, die zum Ausführen der Hooks verwendet werden sollen, sowie den Befehl oder das Script, das in jedem Container ausgeführt werden soll.

  2. Sie konfigurieren Hooks in einer oder mehreren Phasen Ihrer Bereitstellungspipeline, die jeweils auf eine der customActions verweisen, die Sie in skaffold.yaml konfiguriert haben.

  3. Bevor der Bereitstellungsjob des Roll-outs ausgeführt wird, führt Skaffold alle in skaffold.yaml konfigurierten Befehle aus, auf die in einer predeploy-Strophe im Pipeline-Fortschritt verwiesen wird.

    Der predeploy-Hook wird immer als erster Job in der Phase ausgeführt.

  4. Nachdem der Bereitstellungsjob des Roll-outs ausgeführt wurde, führt Cloud Deploy alle in skaffold.yaml konfigurierten Befehle aus, auf die in einer postdeploy-Strophe in der Pipeline-Fortschrittsanzeige verwiesen wird.

Bereitstellungshooks werden in der Standard-Cloud Deploy-Ausführungsumgebung oder in einer angegebenen alternativen Ausführungsumgebung ausgeführt. Bei Bereitstellungen in GKE und GKE Enterprise können Sie die Hooks optional in demselben Cluster ausführen, in dem die Anwendung bereitgestellt wird.

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, nicht unter strategy.standard.

  • Bei einem automatisierten Canary-Test 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.

Aktionen in Skaffold konfigurieren

In Ihrer skaffold.yaml-Datei nimmt die customActions-Strophe eine oder mehrere customActions-Strophen auf, die so konfiguriert sind:

customActions:
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]

In diesem customerActions-Vers:

  • ACTION_NAME

    Ein Name für diese Aktion. Dieser Name kann beliebig sein, muss aber innerhalb dieses skaffold.yaml eindeutig sein. Auf diesen Namen wird in den in der Phase der Bereitstellungspipeline definierten Pre- und Post-Deploy-Aktionen verwiesen.

  • CONTAINER_NAME

    Ein Name für den jeweiligen Container. Dieser Name kann beliebig gewählt werden, muss aber innerhalb dieser skaffold.yaml eindeutig sein.

  • IMAGE

    Der Name des Container-Images, in dem der Befehl ausgeführt wird.

  • COMMANDS_TO_RUN

    Eine Liste der Einstiegspunkte, die in diesem Container ausgeführt werden sollen. "/bin/sh" ist ein typischer Befehl, der hier angegeben wird, um eine Shell aufzurufen. Der Befehl, der in dieser Shell ausgeführt werden soll, wird in den Argumenten angegeben.

  • LIST_OF_ARGS

    Eine Liste von Argumenten, die dem Befehl übergeben werden. Dies ist eine durch Kommas getrennte Liste, wobei jedes Argument in Anführungszeichen gesetzt ist. Wenn COMMAND_TO_RUN "/bin/sh" ist, wäre eines der Argumente hier "-c" und ein anderes Argument wäre der vollständige Befehl, den Sie in der aufgerufenen Shell ausführen möchten.

    Beispiel:

    command: ["/bin/sh"]
args: ["-c", `echo "This command ran!"`]

Weitere Informationen zu benutzerdefinierten Skaffold-Aktionen finden Sie in der Skaffold-Dokumentation.

Pipeline so konfigurieren, dass sie auf die Aktionen verweist

Zum Abschluss der Konfiguration Ihrer Bereitstellungshooks konfigurieren Sie die Bereitstellungspipeline so, dass sie auf die benutzerdefinierten Aktionen verweist, die Sie in der Datei skaffold.yaml definiert haben. Vor- und Nach-Bereitstellungsaktionen werden in einer oder mehreren bestimmten Phasen der Pipeline-Abfolge konfiguriert.

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

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["PREDEPLOY-ACTION"]
        postdeploy:
          actions: ["POSTDEPLOY-ACTION"]

In dieser YAML-Datei:

  • PREDEPLOY_ACTION

    Entspricht der ACTION_NAME, die Sie in Ihrer skaffold.yaml verwendet haben, um die benutzerdefinierte Aktion zu definieren, die vor der Bereitstellung ausgeführt werden soll.

  • POSTDEPLOY_ACTION

    Entspricht dem ACTION_NAME, das Sie in Ihrem skaffold.yaml verwendet haben, um die benutzerdefinierte Aktion zu definieren, die nach der Bereitstellung ausgeführt werden soll.

Sie können für predeploy und postdeploy mehrere Aktionen angeben, die durch Kommas getrennt werden. Wenn mehrere Aktionen angegeben werden, werden sie nacheinander in der angegebenen Reihenfolge ausgeführt. Der Job (vor der Bereitstellung oder nach der Bereitstellung) schlägt bei der ersten fehlgeschlagenen Aktion fehl und die verbleibenden Aktionen werden nicht ausgeführt.

Wenn Sie mehrere Container gleichzeitig ausführen und ein Job fehlschlägt, werden standardmäßig beide Container angehalten. Sie können dieses Verhalten mithilfe der Skaffold-Fehlerstrategie für benutzerdefinierte Aktionen konfigurieren.

Hooks im Anwendungscluster ausführen

Bereitstellungshooks werden standardmäßig in der Ausführungsumgebung von Cloud Deploy ausgeführt. Sie können Skaffold auch so konfigurieren, dass diese benutzerdefinierten Aktionen in demselben Cluster ausgeführt werden, in dem Ihre Anwendung ausgeführt wird. Wenn Sie benutzerdefinierte Aktionen in skaffold.yaml konfigurieren und in einer Pipelinephase aktivieren, wird die Aktion automatisch im Cluster dieses Ziels ausgeführt.

Diese Funktion ist nur für Bereitstellungen in GKE und GKE Enterprise 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 den Hook auf dem Cluster ausführen möchten, fügen Sie in der Konfigurationsdatei skaffold.yaml eine executionMode.kubernetesCluster-Strophe in die customActions-Strophe für die jeweilige benutzerdefinierte Aktion ein:

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

Im folgenden Beispiel wird eine customActions-Strophe mit executionMode zum Aufrufen des Hooks im Anwendungscluster verwendet:

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

Die executionMode-Strophe ist optional. Wenn Sie sie weglassen, führt Skaffold den benutzerdefinierten Aktionscontainer in der Cloud Deploy-Ausführungsumgebung aus.

Verfügbare Umgebungsvariablen

Cloud Deploy stellt die folgenden Umgebungsvariablen in der Ausführungsumgebung bereit und füllt sie aus. Sie können sie für Ihre Hooks verwenden:

  • ANTHOS_MEMBERSHIP

    Bei Zielen vom Typ ANTHOS ist dies 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

    Bei Zielen vom Typ RUN das Projekt, in dem der Cloud Run-Dienst erstellt wurde.

  • CLOUD_RUN_SERVICE

    Bei Zielen vom Typ RUN ist das 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 sie in derGoogle Cloud -Konsole in den Cloud Run-Dienstdetails für Ihren Dienst.

  • CLOUD_RUN_REVISION

    Für Ziele vom Typ RUN die spezifische Version des Cloud Run-Dienstes.

  • GKE_CLUSTER

    Für Ziele vom Typ GKE 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, in der sich die Cloud Deploy-Ressourcen befinden.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Die ID der Lieferpipeline.

  • CLOUD_DEPLOY_TARGET

    Die ID des Ziels.

  • CLOUD_DEPLOY_PROJECT

    Die Google Cloud Projektnummer des Projekts, das die Cloud Deploy-Ressourcen enthält.

  • CLOUD_DEPLOY_PROJECT_ID

    Die Google Cloud Projekt-ID des Projekts.

  • CLOUD_DEPLOY_RELEASE

    Die ID der Version, in der die Hooks ausgeführt werden.

  • CLOUD_DEPLOY_ROLLOUT

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

  • CLOUD_DEPLOY_JOB_RUN

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

  • CLOUD_DEPLOY_PHASE

    Die Phase im Roll-out, die den Job für die Hooks 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

Nächste Schritte