Ejecutar 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 que ejecuten acciones previas o posteriores al despliegue, o ambas. Estos programas, que se ejecutan de esta forma, se denominan "hooks". Los hooks de predespliegue y postdespliegue se ejecutan como trabajos de predespliegue y postdespliegue en el lanzamiento.

Puedes configurar cada hook para que se ejecute en un entorno de ejecución de Cloud Deploy específico, pero, si vas a desplegar en Google Kubernetes Engine, puedes configurarlo para que se ejecute en el clúster de GKE en el que vas a desplegar tu aplicación.

Se presupone que los hooks de implementación son idempotentes. Si una acción determinada se ejecuta más de una vez, no tiene ningún efecto adicional.

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

A continuación, se describen los pasos para configurar los enlaces de implementación y el proceso de Skaffold y Cloud Deploy para ejecutar esos enlaces:

  1. Configura el skaffold.yaml que se usa en una versión determinada para incluir customActions que identifiquen la imagen o las imágenes de contenedor que se usarán para ejecutar los ganchos, así como el comando o la secuencia de comandos específicos que se ejecutarán en cada contenedor.

  2. Puedes configurar ganchos en una o varias fases de la progresión de tu canalización de entrega. Cada una de ellas hace referencia a uno de los customActions que has configurado en skaffold.yaml.

  3. Antes de que se ejecute el trabajo de implementación del lanzamiento, Skaffold ejecuta los comandos configurados en skaffold.yaml a los que se hace referencia en una estrofa predeploy de la progresión de la canalización.

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

  4. Una vez que se haya ejecutado el trabajo de despliegue del lanzamiento, Cloud Deploy ejecutará los comandos configurados en skaffold.yaml a los que se haga referencia en una estrofa postdeploy de la progresión de la canalización.

Los ganchos de implementación se ejecutan en el entorno de ejecución predeterminado de Cloud Deploy o en un entorno de ejecución alternativo especificado. En el caso de los despliegues en GKE y GKE Enterprise, puedes ejecutar los hooks en el mismo clúster en el que se está desplegando la aplicación.

Usar hooks de implementación con una implementación canary

Cuando configuras ganchos de implementación para una implementación canaria, hay varios aspectos que debes tener en cuenta:

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

  • En el caso de un lanzamiento canary automatizado, 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).

Configurar acciones en Skaffold

En el archivo skaffold.yaml, la stanza customActions toma una o varias stanzas 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 el nombre de esta acción. Puedes elegir el nombre que quieras, pero debe ser único en 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 fase de la canalización de entrega.

  • CONTAINER_NAME

    Es el nombre del contenedor específico. Puede elegir el nombre que quiera, pero debe ser único en este skaffold.yaml.

  • IMAGE

    Es el nombre de la imagen de contenedor en la que se ejecutará el comando.

  • COMMANDS_TO_RUN

    Es una lista de puntos de entrada que se ejecutan en ese contenedor. "/bin/sh" es un comando típico que se puede especificar aquí para invocar un shell. En los argumentos, se incluiría el comando que se va a ejecutar en ese shell.

  • 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 sería "-c" y otro argumento sería el comando completo que quieres ejecutar en el shell que estás invocando.

    Veamos un 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.

Configurar el flujo de procesamiento para que haga referencia a las acciones

Para terminar de configurar tus enlaces de implementación, debes configurar la canalización de entrega para que haga referencia a las acciones personalizadas que has definido en el archivo skaffold.yaml. Las acciones previas y posteriores a la implementación se configuran en una o varias fases específicas de la progresión de la canalización.

A continuación se explica cómo configurar los hooks previos y posteriores a la implementación en una fase de una canalización cuando se usa 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 lo mismo que el ACTION_NAME que has usado en tu skaffold.yaml para definir la acción personalizada que quieres ejecutar antes de la implementación.

  • POSTDEPLOY_ACTION

    Es el mismo ACTION_NAME que has usado en tu skaffold.yaml para definir la acción personalizada que quieres ejecutar después de la implementación.

Puedes especificar más de una acción para predeploy y postdeploy, separadas por comas. Si se especifica más de una acción, se ejecutan en serie, en el orden en el que se especifican. El trabajo (pre-deploy o post-deploy) falla en la primera acción que falla y las acciones restantes no se ejecutan.

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

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

Esta función solo está disponible para los despliegues en GKE y GKE Enterprise, no en Cloud Run. Los despliegues 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: {}

A continuación se muestra un ejemplo de stanza customActions que incluye executionMode para invocar el contenedor de hooks 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. Si la omite, Skaffold ejecuta el contenedor de acciones personalizadas en el entorno de ejecución de Cloud Deploy.

Variables de entorno disponibles

Cloud Deploy proporciona y rellena las siguientes variables de entorno en el entorno de ejecución, que puedes usar en tus ganchos:

  • ANTHOS_MEMBERSHIP

    En el caso de los elementos de destino de tipo ANTHOS, el nombre de recurso totalmente especificado del miembro de Anthos.

  • CLOUD_RUN_LOCATION

    En el caso de los destinos de tipo RUN, la región en la que se ha desplegado el servicio de Cloud Run.

  • CLOUD_RUN_PROJECT

    En el caso de los destinos de tipo RUN, el proyecto en el que se creó el servicio de Cloud Run.

  • CLOUD_RUN_SERVICE

    En el caso de los destinos de tipo RUN, el nombre del servicio de Cloud Run desplegado.

  • CLOUD_RUN_SERVICE_URLS

    En el caso de los destinos de tipo RUN, la URL o las URLs (lista separada por comas) que usarán los usuarios finales para acceder a tu servicio. Puedes encontrarlos en los detalles del servicio de Cloud Run de tu servicio, en laGoogle Cloud consola.

  • CLOUD_RUN_REVISION

    En el caso de los destinos de tipo RUN, se trata de la revisión específica del servicio de Cloud Run.

  • GKE_CLUSTER

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

  • TARGET_TYPE

    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 definirá.

  • CLOUD_DEPLOY_LOCATION

    Región que contiene los recursos de Cloud Deploy.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    ID de la canalización de entrega.

  • CLOUD_DEPLOY_TARGET

    Es el ID del elemento de destino.

  • CLOUD_DEPLOY_PROJECT

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

  • CLOUD_DEPLOY_PROJECT_ID

    El Google Cloud ID del proyecto.

  • CLOUD_DEPLOY_RELEASE

    ID de la versión en la que se ejecutarán los ganchos.

  • CLOUD_DEPLOY_ROLLOUT

    El ID del lanzamiento que contiene los trabajos de los ganchos.

  • 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 de los hooks.

Desplegar parámetros como variables de entorno

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

Más información

Siguientes pasos