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:
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.Sie konfigurieren Hooks in einer oder mehreren Phasen in Ihrer Bereitstellungspipeline Progression, die jeweils auf eine der von Ihnen konfigurierten
customActions
verweist inskaffold.yaml
Vor der Ausführung des Bereitstellungsjobs führt Skaffold alle konfigurierten Befehle aus in
skaffold.yaml
, auf die in einerpredeploy
-Stanza in der Pipeline verwiesen wird Fortschritt.Der Hook
predeploy
wird immer als erster Job in der Phase ausgeführt.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 einempostdeploy
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
undpostdeploy
) ist kleiner alsstrategy.canary.canaryDeployment
oderstrategy.canary.customCanaryDeployment.phaseConfigs
statt unterstrategy.standard
Bei einem automatisierten Canary-Test werden
predeploy
-Hooks vor der Bereitstellung in nur in der ersten Phase undpostdeploy
-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 ConsoleCLOUD_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
oderRUN
. 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.