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 y Skaffold para ejecutar acciones previas a la implementación o posteriores a ella, o ambas. Estos programas, que se ejecutan de esta manera, se denominan "enlaces". 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 describen los pasos para configurar hooks de implementación y el proceso de Skaffold y Cloud Deploy para ejecutar esos hooks:

  1. Configuras el skaffold.yaml que se usa para una versión determinada de modo que incluya customActions que identifiquen la imagen o 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.

  2. Configuras hooks en una o más etapas de la progresión de tu canalización de entrega, cada una de las cuales hace referencia a uno de los customActions que configuraste en skaffold.yaml.

  3. Antes de que se ejecute el trabajo de implementación del lanzamiento, Skaffold ejecuta cualquier comando configurado en skaffold.yaml al que se hace referencia en una sección predeploy de la progresión de la canalización.

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

  4. Después de que se ejecuta el trabajo de implementación de la versión, Cloud Deploy ejecuta cualquier comando configurado en skaffold.yaml al que se hace referencia en una sección postdeploy 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 las implementaciones en GKE, 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 tener en cuenta varios aspectos:

  • En la etapa de 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 acciones en Skaffold

En tu archivo skaffold.yaml, la sección customActions toma una o más secciones 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, se indica lo siguiente:

  • ACTION_NAME

    Es un nombre para esta acción. Este nombre puede ser cualquiera que desees, pero debe ser único dentro de este skaffold.yaml. Este es el nombre al que se hará referencia desde las acciones previas y posteriores a la implementación definidas en la etapa de la canalización de entrega.

  • CONTAINER_NAME

    Es un nombre para el contenedor específico. Puedes elegir el nombre que quieras, 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 que se debe especificar aquí para invocar un shell, y debes incluir el comando para ejecutar en ese shell en los argumentos.

  • LIST_OF_ARGS

    Es una lista de argumentos que se proporcionan al comando. Es una lista separada por comas, con cada argumento entre comillas. Si tu COMMAND_TO_RUN es "/bin/sh", uno de los argumentos aquí sería "-c", y otro argumento sería todo el comando 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 que haga referencia a las acciones

Para terminar de configurar tus hooks de implementación, configura la canalización de entrega para que haga referencia a las acciones personalizadas que definiste en tu archivo skaffold.yaml. Las acciones previas y posteriores a la implementación se configuran 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:
          actions: ["PREDEPLOY-ACTION"]
        postdeploy:
          actions: ["POSTDEPLOY-ACTION"]

En este YAML, se especifica lo siguiente:

  • 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 la implementación.

  • POSTDEPLOY_ACTION

    Es el mismo 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, separadas por comas. Cuando se especifica más de una acción, se ejecutan de forma serial, en el orden en que se especifican. El trabajo (previo o posterior a la implementación) falla en la primera acción que falla, y no se ejecutan las acciones restantes.

De forma predeterminada, si ejecutas más de un contenedor en paralelo y falla un trabajo, se detienen ambos contenedores. Puedes configurar este comportamiento con la estrategia de falla de la acción personalizada de Skaffold.

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 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 la canalización, la acción se ejecuta automáticamente en el clúster del destino.

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 ejecutar tu gancho en el clúster, incluye una estrofa executionMode.kubernetesCluster en tu archivo de configuración skaffold.yaml, dentro de la estrofa customActions para 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: {}

El siguiente es un ejemplo de una sección customActions 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 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 proporciona y completa las siguientes variables de entorno en el entorno de ejecución, que puedes usar para tus hooks:

  • ANTHOS_MEMBERSHIP

    Para los destinos de tipo ANTHOS, es el nombre del recurso completamente especificado de la membresía de los clústeres conectados de GKE.

  • 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_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 valor.

  • 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

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

  • CLOUD_DEPLOY_PHASE

    La fase de la versión que contiene el trabajo para los hooks.

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?