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 für die Ausführung konfigurieren Aktionen, um Aktionen vor der Bereitstellung auszuführen, oder nach der Bereitstellung oder beides. Diese auf diese Weise ausgeführten Programme werden „Hooks“. Vorab- und Nachbereitstellungs-Hooks werden als Vor- und Nachbereitstellung ausgeführt jobs auf die Einführung.

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 in Ihrer Bereitstellungspipeline Progression, die jeweils auf eine der von Ihnen konfigurierten customActions verweist in skaffold.yaml

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

Bereitstellungs-Hooks mit einem Canary-Deployment 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 vor der Bereitstellung in nur in der ersten Phase und postdeploy-Hooks werden nach der Bereitstellung in nur die letzte Phase (stabil) an.

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

    Der Name dieser 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, und Sie würden den Befehl die in dieser Shell in den Argumenten ausgeführt werden soll.

  • 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 Ihr COMMAND_TO_RUN "/bin/sh" ist, dann wäre eines der Argumente "-c" und ein anderes wäre der gesamte Befehl, den Sie in der Shell ausführen möchten, aufrufen.

    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

So schließen Sie die Konfiguration Ihrer Bereitstellungs-Hooks ab: konfigurieren Sie die Bereitstellungspipeline so, dass sie auf die von Ihnen definierten benutzerdefinierten Aktionen verweist. in Ihrer skaffold.yaml-Datei. 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 gilt Folgendes:

  • 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 nach der Bereitstellung ausgeführt werden soll.

Sie können mehrere Aktionen für predeploy und postdeploy getrennt angeben. durch Kommas getrennt. Sind mehrere Aktionen angegeben, werden sie nacheinander im 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

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

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.

Fügen Sie einen executionMode.kubernetesCluster ein, um den Hook im Cluster auszuführen Stanza in der Konfigurationsdatei skaffold.yaml im customActions Stanza für die spezifische benutzerdefinierte Aktion:

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

Verfügbare Umgebungsvariablen

Cloud Deploy stellt die folgende Umgebung bereit und fügt sie ein Variablen in der Ausführungsumgebung die Sie für Ihre Hooks verwenden können:

  • 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. Diese finden Sie in der Details zum Cloud Run-Dienst für Ihren Dienst im Google Cloud Console

  • CLOUD_RUN_REVISION

    Für Ziele vom Typ RUN die spezifische Version von Cloud Run .

  • GKE_CLUSTER

    Für Ziele vom Typ GKE wird der vollständig angegebene Ressourcenname der Google Kubernetes Engine-Cluster, 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, 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 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