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 für Aktionen vor und nach der Bereitstellung oder beides ausgeführt werden. Diese Programme, die so ausgeführt werden, werden als „Hooks“ bezeichnet. Die Hooks "Predeploy" und "Postdeploy" werden während des Roll-outs als Pre-Deploy- und Post-Deploy-Jobs ausgeführt.

Sie können jeden Hook so konfigurieren, dass er in einer angegebenen Ausführungsumgebung von Cloud Deploy ausgeführt wird. Wenn Sie das Hook aber in der Google Kubernetes Engine bereitstellen, können Sie es optional so konfigurieren, dass es auf dem GKE-Cluster ausgeführt wird, in dem Sie Ihre Anwendung bereitstellen.

Bereitstellungs-Hooks werden als idempotent betrachtet. Wenn eine bestimmte Aktion mehr als einmal ausgeführt wird, hat das keine zusätzlichen Auswirkungen.

Wie funktionieren Bereitstellungs-Hooks?

Im Folgenden werden die Schritte zum Konfigurieren von Bereitstellungs-Hooks sowie der Skafold- und Cloud Deploy-Prozess zum Ausführen dieser Hooks beschrieben:

  1. Sie konfigurieren die für einen bestimmten Release verwendete skaffold.yaml so, dass sie customActions enthält, die das Container-Image oder die Container-Images für die Ausführung der Hooks identifizieren, sowie den spezifischen Befehl oder das Skript, das für jeden Container ausgeführt werden soll.

  2. Sie konfigurieren Hooks in einer oder mehreren Phasen des Fortschritts 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-Stanza im Pipelinefortschritt verwiesen wird.

    Der Hook predeploy 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-Stanza in der Pipelineabfolge verwiesen wird.

Bereitstellungs-Hooks werden in der standardmäßigen Cloud Deploy-Ausführungsumgebung oder in einer angegebenen alternativen Ausführungsumgebung ausgeführt. Für Bereitstellungen in GKE und GKE Enterprise können Sie optional die Hooks im selben Cluster ausführen, in dem die Anwendung bereitgestellt wird.

Bereitstellungs-Hooks mit einem Canary-Deployment verwenden

Beim Konfigurieren von Bereitstellungs-Hooks für ein Canary-Deployment sind einige Dinge zu 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 einer automatisierten Canary-Version werden predeploy-Hooks nur vor der Bereitstellung in der ersten Phase und postdeploy-Hooks nach der Bereitstellung in der letzten Phase (stabil) ausgeführt.

Aktionen in Skaffold konfigurieren

In der Datei skaffold.yaml enthält die Stanza customActions eine oder mehrere customActions-Stanzas, die so konfiguriert sind:

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

In dieser customerActions-Stanza:

  • ACTION_NAME

    Ist ein Name für diese Aktion. Sie können einen beliebigen Namen festlegen, er muss aber innerhalb von skaffold.yaml eindeutig sein. Dies ist der Name, auf den in den Aktionen vor und nach der Bereitstellung verwiesen wird, die in der Phase der Bereitstellungspipeline definiert wurden.

  • CONTAINER_NAME

    ist ein Name für den jeweiligen Container. Dieser Name kann frei gewählt werden, darf aber innerhalb von skaffold.yaml nur einmal vorkommen.

  • IMAGE

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

  • COMMANDS_TO_RUN

    Ist eine Liste von Einstiegspunkten, die in diesem Container ausgeführt werden sollen. "/bin/sh" ist ein typischer Befehl, der hier zum Aufrufen einer Shell angegeben wird. Den Befehl zur Ausführung in dieser Shell würden Sie in die Argumente aufnehmen.

  • LIST_OF_ARGS

    Ist eine Liste von Argumenten, die für den Befehl bereitgestellt werden sollen. Dies ist eine durch Kommas getrennte Liste, in der jedes Argument in Anführungszeichen steht. Wenn Ihr COMMAND_TO_RUN "/bin/sh" ist, ist eines der Argumente hier "-c" und ein weiteres Argument den gesamten 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 der Bereitstellungs-Hooks konfigurieren Sie die Bereitstellungspipeline so, dass sie auf die benutzerdefinierten Aktionen verweist, die Sie in der Datei skaffold.yaml definiert haben. Aktionen vor und nach der Bereitstellung werden in einer oder mehreren bestimmten Phasen der Pipelinefortschritt konfiguriert.

Im Folgenden wird beschrieben, wie Sie Hooks vor und nach der Bereitstellung in einer Pipelinephase konfigurieren, 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 gilt:

  • PREDEPLOY_ACTION

    Ist mit dem ACTION_NAME identisch, den Sie in skaffold.yaml verwendet haben, um die benutzerdefinierte Aktion zu definieren, die vor der Bereitstellung ausgeführt werden soll.

  • POSTDEPLOY_ACTION

    Ist mit dem ACTION_NAME identisch, den Sie in skaffold.yaml verwendet haben, um die benutzerdefinierte Aktion zu definieren, die nach der Bereitstellung ausgeführt werden soll.

Sie können mehrere Aktionen für predeploy und postdeploy angeben, die durch Kommas getrennt sind. Wenn mehr als eine Aktion angegeben ist, werden sie nacheinander in der angegebenen Reihenfolge ausgeführt. Der Job (Pre-Deploy oder Postdeploy) schlägt bei der ersten fehlgeschlagenen Aktion fehl. Die restlichen Aktionen werden nicht ausgeführt.

Wenn Sie mehrere Container parallel ausführen und ein Job fehlschlägt, werden standardmäßig beide Container angehalten. Sie können dieses Verhalten mit der Fail-Strategie für benutzerdefinierte Skafold-Aktionen konfigurieren.

Hooks im Anwendungscluster ausführen

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

Diese Funktion ist nur für Bereitstellungen in GKE und GKE Enterprise verfügbar, nicht für Cloud Run. Bereitstellungen in Cloud Run können Hooks nur in der Cloud Deploy-Ausführungsumgebung ausführen.

Fügen Sie zum Ausführen des Hooks im Cluster eine executionMode.kubernetesCluster-Stanza in die skaffold.yaml-Konfigurationsdatei in die customActions-Stanza für die spezifische benutzerdefinierte Aktion ein:

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

Das folgende Beispiel zeigt eine customActions-Stanza, die 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: {}

Die Stanza executionMode ist optional. Wenn Sie sie weglassen, führt Skaffold den Container für benutzerdefinierte Aktionen in der Cloud Deploy-Ausführungsumgebung aus.

Verfügbare Umgebungsvariablen

Cloud Deploy stellt in der Ausführungsumgebung die folgenden Umgebungsvariablen bereit, die Sie für die Hooks verwenden können:

  • ANTHOS_MEMBERSHIP

    Bei Zielen 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), die Endnutzer für den Zugriff auf Ihren Dienst verwenden. Sie finden diese in der Google Cloud Console in den Details des Cloud Run-Dienstes 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 Zielen wird dies 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

    Das Google Cloud-Projekt, das die Cloud Deploy-Ressourcen enthält.

  • CLOUD_DEPLOY_RELEASE

    Die ID des Release, in dem 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.

Nächste Schritte