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 und Skaffold so konfigurieren, dass Aktionen ausgeführt werden, um Aktionen vor oder nach der Bereitstellung oder beides auszuführen. 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 mehr als einmal ausgeführt wird, hat das keine zusätzlichen Auswirkungen.

Wie funktionieren Bereitstellungshooks?

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

  1. Sie konfigurieren das skaffold.yaml für eine bestimmte Version so, dass es customActions enthält, die das oder die Container-Images zum Ausführen der Hooks und den spezifischen Befehl oder das spezifische Script zum Ausführen auf jedem Container identifizieren.

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

  3. Bevor der Bereitstellungsjob des Rollouts ausgeführt wird, führt Skaffold alle in skaffold.yaml konfigurierten Befehle aus, auf die in einem predeploy-Abschnitt im Pipelineverlauf verwiesen wird.

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

  4. Nachdem der Bereitstellungsjob des Rollouts ausgeführt wurde, führt Cloud Deploy alle in skaffold.yaml konfigurierten Befehle aus, auf die in einem postdeploy-Abschnitt in der Pipeline-Progression verwiesen wird.

Bereitstellungshooks werden in der Standardausführungsumgebung von Cloud Deploy oder in einer angegebenen alternativen Ausführungsumgebung ausgeführt. Bei Deployments in GKE können Sie die Hooks optional im selben 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 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.

Aktionen in Skaffold konfigurieren

Im Abschnitt customActions Ihrer Datei skaffold.yaml sind ein oder mehrere customActions-Abschnitte enthalten, 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-Abschnitt:

  • ACTION_NAME

    Ist ein Name für diese Aktion. Dieser Name kann beliebig sein, muss aber innerhalb dieses skaffold.yaml eindeutig sein. Dies ist der Name, auf den in den Pre-Deploy- und Post-Deploy-Aktionen der Lieferpipelinephase verwiesen wird.

  • CONTAINER_NAME

    Ist ein Name für den jeweiligen Container. Dieser Name kann beliebig sein, muss aber innerhalb dieses skaffold.yaml eindeutig sein.

  • IMAGE

    Ist der Name des Container-Images, in dem Ihr 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 sollen. Dies ist eine durch Kommas getrennte Liste, in der jedes Argument in Anführungszeichen steht. Wenn Ihr COMMAND_TO_RUN "/bin/sh" ist, wäre eines der Argumente hier "-c" und ein weiteres Argument wäre der gesamte Befehl, den Sie in der Shell ausführen möchten, die Sie aufrufen.

    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 auf die Aktionen verwiesen wird

Um die Konfiguration Ihrer Bereitstellungshooks abzuschließen, konfigurieren Sie die Bereitstellungspipeline so, dass sie auf die benutzerdefinierten Aktionen verweist, die Sie in Ihrer skaffold.yaml-Datei definiert haben. Aktionen vor und nach der Bereitstellung werden in einer oder mehreren bestimmten Phasen in der Pipeline konfiguriert.

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:
          actions: ["PREDEPLOY-ACTION"]
        postdeploy:
          actions: ["POSTDEPLOY-ACTION"]

In diesem YAML-Code:

  • PREDEPLOY_ACTION

    Entspricht der ACTION_NAME, die Sie in Ihrem 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 durch Kommas getrennte Aktionen angeben. Wenn mehrere Aktionen angegeben werden, werden sie seriell in der angegebenen Reihenfolge ausgeführt. Der Job (vor oder nach der Bereitstellung) schlägt bei der ersten Aktion fehl, die fehlschlägt. Die verbleibenden Aktionen werden nicht ausgeführt.

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

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 diese benutzerdefinierten Aktionen auf demselben Cluster ausgeführt werden, auf 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 des jeweiligen Ziels ausgeführt.

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 im Cluster ausführen möchten, fügen Sie in der Konfigurationsdatei skaffold.yaml einen executionMode.kubernetesCluster-Abschnitt in den customActions-Abschnitt 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: {}

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 die folgenden Umgebungsvariablen in der Ausführungsumgebung bereit und füllt sie aus. Sie können sie für Ihre Hooks verwenden:

  • ANTHOS_MEMBERSHIP

    Für Ziele vom Typ ANTHOS ist dies der vollständig angegebene Ressourcenname der Mitgliedschaft des angehängten GKE-Clusters.

  • 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.

  • 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 Joblauf, der die aktuelle Ausführung des Jobs darstellt.

  • CLOUD_DEPLOY_PHASE

    Die Phase der Einführung, 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