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

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

Puedes configurar Cloud Deploy y Skaffold para que se ejecuten actions para realizar acciones previas a la implementación o acciones posteriores a la implementación, o ambas. A estos programas, que se ejecutan de esta manera, se los llama "hooks". Los hooks previos a la implementación y posteriores a ella se ejecutan como un proceso previo y posterior a la implementación trabajos en el lanzamiento.

Puedes configurar cada hook para que se ejecute en un Cloud Deploy específico. entorno de ejecución, pero si que implementas en Google Kubernetes Engine, tienes la opción de configurarlo para que se ejecute clúster de GKE en el que implementas la 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 los hooks de implementación y el proceso de Skaffold y Cloud Deploy para ejecutarlos:

  1. Configuras el skaffold.yaml que se usa para una versión determinada para incluir customActions que identifican la imagen o las imágenes del 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 los comandos configurados en skaffold.yaml a las que se hace referencia en una estrofa predeploy de la canalización progresión.

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

  4. Después de que se ejecute el trabajo de implementación del lanzamiento, Cloud Deploy ejecutará Comandos configurados en skaffold.yaml a los que se hace referencia en un postdeploy en la progresión de la canalización.

Los hooks de implementación se ejecutan en la ejecución predeterminada de Cloud Deploy entorno de ejecución o en un entorno de ejecución alternativo especificado. Para implementaciones a GKE y GKE Enterprise, puedes ejecutar los hooks en el mismo clúster dónde 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, hay varios cosas que debes saber:

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

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

Configura acciones en Skaffold

En tu archivo skaffold.yaml, la estrofa customActions toma uno o más. customActions de estrofas, 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 únicos en este skaffold.yaml. Este es el nombre al que se hará referencia de las acciones previas y posteriores a la implementación definida en la etapa de canalización de entrega.

  • CONTAINER_NAME

    Es un nombre para el contenedor específico. Este nombre puede ser el que quieras, pero debe ser único dentro de este skaffold.yaml.

  • IMAGE

    Es el nombre de la imagen del 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 valor normal para especificar aquí, para invocar un shell, y deberías incluir el comando para que se ejecute en ese shell en los argumentos.

  • LIST_OF_ARGS

    Es una lista de argumentos para proporcionar al comando. Los valores están separados por comas list, con cada argumento entre comillas. Si tu COMMAND_TO_RUN es "/bin/sh", uno de los argumentos aquí sería "-c" y otro sería el comando completo que deseas ejecutar en la shell que invocas.

    A continuación, se presenta un ejemplo:

    command: ["/bin/sh"]
args: ["-c", `echo "This command ran!"`]

Para obtener más información sobre las acciones personalizadas de Skaffold, consulta el Documentación de Skaffold.

Configura la canalización para hacer referencia a las acciones

Para terminar de configurar tus hooks de implementación, debes configurar 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 un o etapas más específicas en la canalización progreso.

A continuación, se muestra cómo configurar hooks previos y posteriores a la implementación en 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 YAML, se incluye lo siguiente:

  • PREDEPLOY_ACTION

    Sea 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

    Sea 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, separadas con comas. Cuando se especifica más de una acción, estas se ejecutan en serie, en en el que se especifican. La tarea (preaprovisionamiento o posaprovisionamiento) 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 un trabajo falla, ambos contenedores se detienen. Puedes configurar este comportamiento con el Estrategia de falla personalizada 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 Cloud Deploy entorno de ejecución. También puedes y configurar Skaffold para que ejecute esas acciones personalizadas en el mismo clúster en el que cuando ejecutes la aplicación. Cuando Configurar acciones personalizadas en skaffold.yaml y habilitarlos en una etapa de canalización, la acción se ejecuta automáticamente en el clúster de ese destino.

Esta capacidad está disponible para implementaciones en GKE y Solo para GKE Enterprise, no para Cloud Run. Deployments en Cloud Run solo puede ejecutar hooks en Cloud Deploy entorno de ejecución.

Para ejecutar tu hook en el clúster, incluye un executionMode.kubernetesCluster. en tu archivo de configuración skaffold.yaml, dentro de customActions Estrofa 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: {}

La siguiente es una estrofa 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 la contenedor de acciones personalizadas en el entorno de ejecución de Cloud Deploy.

Variables de entorno disponibles

Cloud Deploy proporciona y propaga el siguiente entorno variables en el entorno de ejecución, que puedes usar para tus hooks:

  • ANTHOS_MEMBERSHIP

    Para los destinos de tipo ANTHOS, el nombre de recurso completamente especificado de la membresía de Anthos.

  • CLOUD_RUN_LOCATION

    Para los destinos de tipo RUN, la región en la que se encuentra el servicio de Cloud Run implementar en la nube.

  • CLOUD_RUN_PROJECT

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

  • CLOUD_RUN_SERVICE

    Para los destinos de tipo RUN, el nombre del servicio de Cloud Run cuando se implementa un plan.

  • CLOUD_RUN_SERVICE_URLS

    Para destinos de tipo RUN, la URL o las URL (lista separada por comas) que finalizan que usarán los usuarios para acceder a tu servicio. Puedes encontrar estos datos en los detalles del servicio de Cloud Run de tu servicio, en la consola de Google Cloud.

  • CLOUD_RUN_REVISION

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

  • GKE_CLUSTER

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

  • TARGET_TYPE

    El tipo de entorno de ejecución específico del destino. GKE, ANTHOS o RUN. No se establecerá esta opción para los destinos personalizados.

  • CLOUD_DEPLOY_LOCATION

    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

    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 el trabajo.

  • CLOUD_DEPLOY_PHASE

    La fase del lanzamiento que contiene el trabajo de los hooks.

Implementa parámetros como variables de entorno

Además de las variables de entorno enumeradas en esta sección, Cloud Deploy puede pasar a tus contenedores personalizados cualquier implementar los parámetros que estableciste.

Más información

¿Qué sigue?