Ejecuta hooks antes y después de la implementación

En este documento, se describe cómo ejecutar programas u operaciones arbitrarios antes o después de la implementación.

Puedes configurar Cloud Deploy para realizar acciones previas a la implementación o posteriores a ella, o ambas. Estos programas, que se ejecutan de esta manera, se denominan "hooks". Los hooks previos y posteriores a la implementación 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 especificado, pero, si realizas la implementación en Google Kubernetes Engine, también puedes configurarlo de forma opcional 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 tendrá ningún efecto adicional.

¿Cómo funcionan los hooks de implementación?

A continuación, se describe cómo se ejecutan los hooks de implementación en Cloud Deploy y cómo configurarlos:

  1. Configuras hooks en una o más etapas de la progresión de tu canalización de entrega.

  2. Antes de que se ejecute el trabajo de implementación del lanzamiento, Cloud Deploy ejecuta las tareas configuradas en una definición de predeploy en la progresión de la canalización.

    El gancho predeploy siempre se ejecuta como el primer trabajo de la fase.

  3. Después de que se ejecuta el trabajo de implementación de la versión, Cloud Deploy ejecuta las tareas configuradas en una definición de postdeploy en la progresión de la canalización.

Los hooks de implementación se ejecutan en el entorno de ejecución de Cloud Deploy.

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 tener en cuenta varios aspectos:

  • En la etapa de la canalización de entrega, la configuración del gancho (predeploy y postdeploy) se encuentra en strategy.canary.canaryDeployment o strategy.canary.customCanaryDeployment.phaseConfigs, en lugar de en strategy.standard.

  • En el caso de una versión canary automatizada, los hooks predeploy se ejecutan antes de la implementación solo en la primera fase, y los hooks postdeploy se ejecutan después de la implementación solo en la última fase (estable).

Configura tu canalización para ejecutar hooks

Configuras los hooks previos y posteriores a la implementación en una o más etapas específicas de la progresión de la canalización.

A continuación, se muestra cómo configurar hooks previos y posteriores a la implementación en una etapa de la canalización cuando se usa una estrategia de implementación de standard:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          tasks: [TASKS]
        postdeploy:
          tasks: [TASKS]

En este YAML, se especifica lo siguiente:

  • TASKS

    Es una lista de una o más tareas que deseas ejecutar como parte de tus hooks previos o posteriores a la implementación. Cuando especificas más de una tarea, se ejecutan de forma serial, en el orden en que se especifican. El trabajo (previo a la implementación o posterior a la implementación) falla en la primera tarea que falla, y no se ejecutan las tareas restantes.

Ejecuta los hooks en el clúster de la aplicación

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 hooks de implementación en el mismo clúster en el que se ejecuta tu aplicación.

Para ejecutar hooks en el clúster de la aplicación, debes configurarlos como customActions en tu skaffold.yaml y hacer referencia a ellos con actions en la sección predeploy o postdeploy de la configuración de la etapa de la canalización de entrega:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["my-predeploy-action"]
        postdeploy:
          actions: ["my-postdeploy-action"]

Esta capacidad solo está disponible para las implementaciones en GKE, no para Cloud Run. Las implementaciones en Cloud Run solo pueden ejecutar hooks en el entorno de ejecución de Cloud Deploy.

Para configurar tu hook para que se ejecute en el clúster, incluye una estrofa executionMode.kubernetesCluster en tu archivo de configuración skaffold.yaml, dentro de la estrofa customActions para cada acción que desees ejecutar en el clúster:

customActions:
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]
  executionMode:
    kubernetesCluster: {}

A continuación, se muestra un ejemplo de una sección customActions que incluye executionMode para invocar el contenedor de gancho 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 sección executionMode es opcional y, si la omites, Skaffold ejecuta el contenedor de acción personalizada en el entorno de ejecución de Cloud Deploy.

Variables de entorno disponibles

Cloud Deploy también proporciona y completa las siguientes variables de entorno en el entorno de ejecución. Puedes usar estas variables de entorno como parte de tu gancho de implementación, trabajo de verificación o destino personalizado de renderización o implementación.

  • ANTHOS_MEMBERSHIP

    Para los destinos de tipo ANTHOS, es el nombre del recurso completamente especificado 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 los 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 los destinos de tipo RUN, son 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 de tu servicio, en la consola deGoogle Cloud . Cloud Run genera las URLs después de que se implementan correctamente tus servicios de Cloud Run. Por lo tanto, esta variable de entorno solo está disponible en los hooks posteriores a la implementación y en los trabajos de verificación.

  • CLOUD_RUN_REVISION

    Para los destinos de tipo RUN, es la revisión específica del servicio de Cloud Run.

  • GKE_CLUSTER

    Para los destinos de tipo GKE, es el nombre del recurso completamente especificado del clúster de Google Kubernetes Engine, por ejemplo, projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    Es el tipo de tiempo de ejecución específico del destino. Puede ser GKE, ANTHOS o RUN. En el caso de los objetivos personalizados, no se establecerá este parámetro.

  • CLOUD_DEPLOY_LOCATION

    Es la región que contiene los recursos de Cloud Deploy.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Es el ID de la canalización de entrega.

  • CLOUD_DEPLOY_TARGET

    Es el ID del objetivo.

  • CLOUD_DEPLOY_PROJECT

    Número del proyecto Google Cloud que contiene los recursos de Cloud Deploy.

  • CLOUD_DEPLOY_PROJECT_ID

    ID del proyecto Google Cloud .

  • CLOUD_DEPLOY_RELEASE

    Es el ID de la versión en la que se ejecutarán los hooks.

  • CLOUD_DEPLOY_ROLLOUT

    Es el ID del lanzamiento que contiene los trabajos de los hooks.

  • CLOUD_DEPLOY_JOB_RUN

    Es el ID de la ejecución del trabajo que representa la ejecución actual del trabajo.

  • CLOUD_DEPLOY_PHASE

    Es la fase de la versión que contiene el trabajo para el gancho de implementación, el trabajo de verificación o la renderización o implementación personalizadas.

Implementa parámetros como variables de entorno

Además de las variables de entorno que se indican en esta sección, Cloud Deploy puede pasar a tus contenedores personalizados cualquier parámetro de implementación que hayas configurado.

Obtén más información.

¿Qué sigue?