Hooks vor und nach der Bereitstellung ausführen

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

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 einem bestimmten Cloud Deploy ausgeführt wird Ausführungsumgebung, aber wenn Sie in Google Kubernetes Engine bereitstellen, können Sie ihn optional so konfigurieren, dass er auf der GKE-Cluster, in dem Sie Ihre Anwendung bereitstellen.

Es wird angenommen, dass Bereitstellungs-Hooks idempotent sind. Wenn eine bestimmte Aktion mehr als hat dies keine zusätzlichen Auswirkungen.

Wie funktionieren Bereitstellungs-Hooks?

Im Folgenden werden die Schritte zum Konfigurieren von Bereitstellungs-Hooks und den Skaffold- und Cloud Deploy-Prozess zum Ausführen dieser Hooks:

  1. Du konfigurierst die für einen bestimmten Release verwendete skaffold.yaml so, dass sie Folgendes umfasst: customActions, die das Container-Image oder die Container-Images identifizieren, die zum Ausführen des Hooks und dem spezifischen Befehl oder Skript, 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. Vor der Ausführung des Bereitstellungsjobs führt Skaffold alle konfigurierten Befehle aus in skaffold.yaml, auf die in einer predeploy-Stanza in der Pipeline verwiesen wird Fortschritt.

    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 folgende Aktionen aus: Befehle, die in skaffold.yaml konfiguriert sind und auf die in einem postdeploy verwiesen wird Stanza in der Pipelinefortschritt.

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

Bereitstellungshooks mit einer Canary-Bereitstellung verwenden

Wenn Sie Bereitstellungs-Hooks für ein Canary-Deployment konfigurieren, gibt es mehrere Wichtige Hinweise:

  • In der Bereitstellungspipeline-Phase wird die Konfiguration des Hooks vorgenommen. (predeploy und postdeploy) ist kleiner als strategy.canary.canaryDeployment oder strategy.canary.customCanaryDeployment.phaseConfigs statt 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-Stanza mindestens eine customActions Stanzas, konfiguriert wie folgt:

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

In dieser customerActions Stanza:

  • ACTION_NAME

    Ein Name für diese Aktion. Sie können einen beliebigen Namen eingeben, eindeutig innerhalb dieses skaffold.yaml. Dies ist der Name, auf den verwiesen wird vor und nach der Bereitstellung in der Phase der Bereitstellungspipeline definiert.

  • CONTAINER_NAME

    Der Name des jeweiligen Containers. Sie können einen beliebigen Namen eingeben, muss innerhalb dieses skaffold.yaml eindeutig sein.

  • IMAGE

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

  • COMMANDS_TO_RUN

    Ist eine Liste der Einstiegspunkte, die für diesen 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

    Ist eine Liste der Argumente, die an den Befehl übergeben werden sollen. Dies ist ein durch Kommas getrenntes und jedes Argument in Anführungszeichen setzen. 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 konfigurieren, um auf die Aktionen zu verweisen

Zum Abschluss der Konfiguration Ihrer 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 Konfiguration konfiguriert. oder spezifischere Phasen in der Pipeline, progression.

So konfigurieren Sie Hooks vor und nach der Bereitstellung in einer Pipeline: Phase bei Verwendung einer standard-Bereitstellungsstrategie:

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

In dieser YAML-Datei:

  • PREDEPLOY_ACTION

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

  • POSTDEPLOY_ACTION

    Ist mit der ACTION_NAME identisch, die Sie in Ihrem skaffold.yaml zum Definieren der benutzerdefinierten Aktion, die Sie nach der Bereitstellung ausführen möchten.

Sie können mehrere Aktionen für predeploy und postdeploy getrennt angeben. durch Kommas getrennt. Sind mehrere Aktionen angegeben, werden sie nacheinander ausgeführt, in der sie angegeben werden. Der Job (Vorbereitstellung oder Nachbereitstellung) schlägt beim ersten fehl die fehlgeschlagen ist, und die verbleibenden Aktionen werden nicht ausgeführt.

Wenn Sie mehrere Container parallel und einen Job ausführen, schlägt er fehl, werden beide Container beendet. Sie können dieses Verhalten über die Skaffold-Fehlstrategie für benutzerdefinierte Aktionen:

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 für Deployments in GKE und Nur GKE Enterprise, nicht für Cloud Run. Bereitstellungen in Cloud Run kann nur Hooks in Cloud Deploy ausführen der Ausführungsumgebung.

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: {}

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 executionMode-Stanza ist optional. Wenn Sie sie weglassen, führt Skaffold den Container für benutzerdefinierte Aktionen in der Cloud Deploy-Ausführungsumgebung

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 der vollständig angegebene Ressourcenname der Anthos- Mitgliedschaft.

  • CLOUD_RUN_LOCATION

    Bei Zielen vom Typ RUN ist die Region, in der sich der Cloud Run-Dienst befindet. bereitgestellt wird.

  • CLOUD_RUN_PROJECT

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

  • CLOUD_RUN_SERVICE

    Für Ziele vom Typ RUN: der Name des Cloud Run-Dienstes bereitgestellt.

  • CLOUD_RUN_SERVICE_URLS

    Bei Zielen vom Typ RUN die URL oder URLs (durch Kommas getrennte Liste), die enden die Nutzer verwenden, um auf Ihren Dienst zuzugreifen. Sie finden sie in der Google Cloud Console 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

    Bei Zielen 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. GKE, ANTHOS oder RUN. Bei benutzerdefinierten Zielen 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 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 der aktuellen Ausführung der Job.

  • 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 Cloud Deploy kann beliebige Werte an Ihre benutzerdefinierten Container übergeben Parameter bereitstellen, die Sie festgelegt haben.

Weitere Informationen

Nächste Schritte