En este documento, se describe cómo ejecutar operaciones o programas arbitrarios antes o después de la implementación.
Puedes configurar Cloud Deploy y Skaffold para ejecutar acciones previas a la implementación o posteriores a la implementación, o ambas. Estos programas, que se ejecutan de esta manera, se denominan “hooks”. Los hooks previos a la implementación y posteriores a ella se ejecutan como trabajos previos y posteriores a la implementación en el lanzamiento.
Puedes configurar cada hook para que se ejecute en un entorno de ejecución de Cloud Deploy específico, pero si implementas en Google Kubernetes Engine, tienes la opción de configurarlo para que se ejecute en el clúster de GKE en el que implementas tu aplicación.
Se supone que los hooks de implementación son idempotentes. Si una acción determinada se ejecuta más de una vez, no hay ningún efecto adicional.
¿Cómo funcionan los hooks de implementación?
A continuación, se describen los pasos para configurar hooks de implementación y el proceso de Skaffold y Cloud Deploy para ejecutar esos hooks:
Configura el
skaffold.yaml
que se usa en una versión determinada para incluircustomActions
que identifique las imágenes de contenedor que se usarán para ejecutar los hooks y el comando o la secuencia de comandos específicos que se ejecutarán en cada contenedor.Los hooks se configuran en una o más etapas de la progresión de la canalización de entrega, cada una de las cuales hace referencia a una de las
customActions
que configuraste enskaffold.yaml
.Antes de que se ejecute el trabajo de implementación del lanzamiento, Skaffold ejecuta cualquier comando configurado en
skaffold.yaml
al que se haga referencia en una estrofapredeploy
en la progresión de la canalización.El hook
predeploy
siempre se ejecuta como el primer trabajo en la fase.Después de que se ejecuta el trabajo de implementación del lanzamiento, Cloud Deploy ejecuta todos los comandos configurados en
skaffold.yaml
al que se haga referencia en una estrofapostdeploy
en el progreso de la canalización.
Los hooks de implementación se ejecutan en el entorno de ejecución predeterminado de Cloud Deploy o en un entorno de ejecución alternativo especificado. Para implementaciones en GKE y GKE Enterprise, de manera opcional, puedes ejecutar los hooks en el mismo clúster en el que se implementa la aplicación.
Usa hooks de implementación con una implementación de versiones canary
Cuando configuras hooks de implementación para una implementación de versiones canary, debes conocer varias cosas:
En la etapa de canalización de entrega, la configuración del hook (
predeploy
ypostdeploy
) se encuentra enstrategy.canary.canaryDeployment
ostrategy.canary.customCanaryDeployment.phaseConfigs
, en lugar destrategy.standard
.Para una versión canary automatizada, los hooks
predeploy
se ejecutan antes de la implementación solo en la primera fase, y los hookspostdeploy
se ejecutan solo en la última fase (estable).
Configura acciones en Skaffold
En tu archivo skaffold.yaml
, la estrofa customActions
toma una o más estrofas customActions
, configuradas de la siguiente manera:
customActions
- name: ACTION_NAME
containers:
- name: CONTAINER_NAME
image: IMAGE
command: [COMMANDS_TO_RUN]
args: [LIST_OF_ARGS]
En esta estrofa de customerActions
:
ACTION_NAME
Es un nombre para esta acción. Este nombre puede ser el que desees, pero debe ser único dentro de este
skaffold.yaml
. Este es el nombre al que se hará referencia en las acciones previas y posteriores a la implementación definidas en la etapa de canalización de entrega.CONTAINER_NAME
Es un nombre para el contenedor específico. Este nombre puede ser el que desees, pero debe ser único dentro de este
skaffold.yaml
.IMAGE
Es el nombre de la imagen de contenedor en la que se ejecutará tu comando.
COMMANDS_TO_RUN
Es una lista de puntos de entrada para ejecutar en ese contenedor.
"/bin/sh"
es un comando típico para especificar aquí a fin de invocar un shell, y deberías incluir el comando para ejecutar en ese shell en los argumentos.LIST_OF_ARGS
Es una lista de argumentos para proporcionar al comando. Esta es una lista separada por comas, con cada argumento entre comillas. Si tu COMMAND_TO_RUN es
"/bin/sh"
, uno de los argumentos sería"-c"
y otro argumento sería el comando completo que deseas ejecutar en la shell que invocas.Por ejemplo:
command: ["/bin/sh"] args: ["-c", `echo "This command ran!"`]
Para obtener más información sobre las acciones personalizadas de Skaffold, consulta la documentación de Skaffold.
Configura la canalización para hacer referencia a las acciones
Para terminar de configurar los hooks de implementación, configura la canalización de entrega para hacer referencia a las acciones personalizadas que definiste en el archivo skaffold.yaml
. Las acciones previas y posteriores a la implementación se configuran en una o más etapas específicas en la progresión de la canalización.
A continuación, se muestra cómo configurar los hooks previos y posteriores a la implementación en una etapa de canalización cuando uses una estrategia de implementación standard
:
serialPipeline:
stages:
- targetId: hooks-staging
profiles: []
strategy:
standard:
predeploy:
actions: ["PREDEPLOY-ACTION"]
postdeploy:
actions: ["POSTDEPLOY-ACTION"]
En este archivo YAML:
PREDEPLOY_ACTION
Es el mismo que el ACTION_NAME que usaste en tu
skaffold.yaml
para definir la acción personalizada que deseas ejecutar antes de implementar.POSTDEPLOY_ACTION
Es el mismo que el ACTION_NAME que usaste en tu
skaffold.yaml
para definir la acción personalizada que deseas ejecutar después de la implementación.
Puedes especificar más de una acción para predeploy
y postdeploy
, separada por comas. Cuando se especifica más de una acción, se ejecutan en serie, en el orden en el que se especifican. El trabajo (previo a la implementación o posterior a la implementación) falla en la primera acción que falla, y las acciones restantes no se ejecutan.
De forma predeterminada, si estás ejecutando más de un contenedor, en paralelo, y un trabajo falla, ambos contenedores se detienen. Puedes configurar este comportamiento con la estrategia de falla de acciones personalizadas de Skaffold.
Ejecuta los hooks en el clúster de aplicaciones
De forma predeterminada, los hooks de implementación se ejecutan en el entorno de ejecución de Cloud Deploy. También puedes configurar Skaffold para que ejecute esas acciones personalizadas en el mismo clúster en el que se ejecuta tu aplicación. Cuando configuras acciones personalizadas en skaffold.yaml
y las habilitas en una etapa de canalización, la acción se ejecuta de forma automática en el clúster de ese destino.
Esta capacidad está disponible solo para implementaciones en GKE y GKE Enterprise, no para Cloud Run. Las implementaciones en Cloud Run solo pueden ejecutar hooks en el entorno de ejecución de Cloud Deploy.
Para ejecutar el hook en el clúster, incluye una estrofa executionMode.kubernetesCluster
en el archivo de configuración skaffold.yaml
, dentro de la estrofa customActions
de la acción personalizada específica:
customActions
- name: ACTION_NAME
containers:
- name: CONTAINER_NAME
image: IMAGE
command: [COMMANDS_TO_RUN]
args: [LIST_OF_ARGS]
executionMode:
kubernetesCluster: {}
La siguiente es una estrofa de customActions
de ejemplo que incluye executionMode
para invocar el contenedor de hook en el clúster de la aplicación:
customActions:
- name: predeploy-action
containers:
- name: predeploy-echo
image: ubuntu
command: ["/bin/sh"]
args: ["-c", 'echo "this is a predeploy action"' ]
executionMode:
kubernetesCluster: {}
La estrofa executionMode
es opcional y, si la omites, Skaffold ejecuta el contenedor de acciones personalizadas en el entorno de ejecución de Cloud Deploy.
Variables de entorno disponibles
Cloud Deploy proporciona y propaga las siguientes variables de entorno en el entorno de ejecución, que puedes usar para tus hooks:
ANTHOS_MEMBERSHIP
Para los objetivos de tipo
ANTHOS
, el nombre del recurso especificado por completo de la membresía de Anthos.CLOUD_RUN_LOCATION
Para los destinos de tipo
RUN
, es la región en la que se implementa el servicio de Cloud Run.CLOUD_RUN_PROJECT
Para destinos de tipo
RUN
, es el proyecto en el que se creó el servicio de Cloud Run.CLOUD_RUN_SERVICE
Para los destinos de tipo
RUN
, es el nombre del servicio de Cloud Run implementado.CLOUD_RUN_SERVICE_URLS
Para destinos de tipo
RUN
, la URL o las URLs (lista separada por comas) que los usuarios finales usarán para acceder a tu servicio. Puedes encontrarlos en los detalles del servicio de Cloud Run, en la consola de Google Cloud.CLOUD_RUN_REVISION
Para los objetivos de tipo
RUN
, es la revisión específica del servicio de Cloud Run.GKE_CLUSTER
Para los destinos de tipo
GKE
, el nombre del recurso especificado por completo del clúster de Google Kubernetes Engine, por ejemplo,projects/p/locations/us-central1/clusters/dev
.TARGET_TYPE
El tipo específico de entorno de ejecución del destino.
GKE
,ANTHOS
oRUN
. En el caso de las segmentaciones personalizadas, no se establecerá.CLOUD_DEPLOY_LOCATION
La región que contiene los recursos de Cloud Deploy.
CLOUD_DEPLOY_DELIVERY_PIPELINE
El ID de la canalización de entrega.
CLOUD_DEPLOY_TARGET
El ID del objetivo.
CLOUD_DEPLOY_PROJECT
El proyecto de Google Cloud que contiene los recursos de Cloud Deploy.
CLOUD_DEPLOY_RELEASE
El ID de la versión en la que se ejecutarán los hooks.
CLOUD_DEPLOY_ROLLOUT
El ID del lanzamiento que contiene los trabajos de los hooks.
CLOUD_DEPLOY_JOB_RUN
El ID de la ejecución del trabajo que representa la ejecución actual del trabajo.
CLOUD_DEPLOY_PHASE
La fase del lanzamiento que contiene el trabajo para los hooks.
¿Qué sigue?
Prueba la guía de inicio rápido: Ejecuta hooks antes y después de la implementación.
Obtén más información sobre Skaffold.