Exécuter des hooks avant et après le déploiement

Ce document explique comment exécuter des programmes ou des opérations arbitraires avant et/ou après le déploiement.

Vous pouvez configurer Cloud Deploy et Skaffold pour qu'ils exécutent des actions qui effectueront des actions pré-déploiement, post-déploiement, ou les deux. Ces programmes, exécutés de cette manière, sont appelés "hooks". Les hooks de prédéploiement et de postdéploiement s'exécutent en tant que jobs de prédéploiement et de postdéploiement lors du déploiement.

Vous pouvez configurer chaque hook pour qu'il s'exécute dans un environnement d'exécution Cloud Deploy spécifié, mais si vous effectuez un déploiement sur Google Kubernetes Engine, vous pouvez le configurer pour qu'il s'exécute sur le cluster GKE sur lequel vous déployez votre application.

Les hooks de déploiement sont supposés être idempotents. Si une action donnée est exécutée plusieurs fois, aucun effet supplémentaire n'est généré.

Comment fonctionnent les hooks de déploiement ?

La procédure suivante décrit comment configurer des hooks de déploiement, ainsi que le processus Skaffold et Cloud Deploy pour exécuter ces hooks:

  1. Vous configurez le skaffold.yaml utilisé pour une version donnée afin d'inclure des customActions qui identifient l'image ou les images de conteneur à utiliser pour exécuter les hooks, ainsi que la commande ou le script spécifiques à exécuter sur chaque conteneur.

  2. Vous configurez des hooks dans une ou plusieurs étapes de la progression de votre pipeline de diffusion, chacun faisant référence à l'un des customActions que vous avez configurés dans skaffold.yaml.

  3. Avant l'exécution de la tâche de déploiement du déploiement, Skaffold exécute toutes les commandes configurées dans skaffold.yaml qui sont référencées dans une strophe predeploy dans la progression du pipeline.

    Le hook predeploy s'exécute toujours en tant que première tâche de la phase.

  4. Une fois la tâche de déploiement du déploiement exécutée, Cloud Deploy exécute toutes les commandes configurées dans skaffold.yaml qui sont référencées dans une strophe postdeploy dans la progression du pipeline.

Les hooks de déploiement sont exécutés dans l'environnement d'exécution Cloud Deploy par défaut ou dans un autre environnement d'exécution spécifié. Pour les déploiements sur GKE et GKE Enterprise, vous pouvez éventuellement exécuter les hooks sur le même cluster où l'application est déployée.

Utiliser des hooks de déploiement avec un déploiement Canary

Lorsque vous configurez des hooks de déploiement pour un déploiement Canary, plusieurs points sont à prendre en compte:

  • À l'étape du pipeline de diffusion, la configuration du hook (predeploy et postdeploy) se trouve sous strategy.canary.canaryDeployment ou strategy.canary.customCanaryDeployment.phaseConfigs, et non sous strategy.standard.

  • Pour un canari automatisé, les hooks predeploy sont exécutés avant le déploiement dans la première phase uniquement, et les hooks postdeploy sont exécutés après le déploiement dans la dernière phase (stable) uniquement.

Configurer des actions dans Skaffold

Dans votre fichier skaffold.yaml, la strophe customActions contient une ou plusieurs strophes customActions, configurées comme suit:

customActions
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]

Dans cette strophe customerActions:

  • ACTION_NAME

    Nom de cette action. Ce nom peut être choisi librement, mais il doit être unique dans cet élément skaffold.yaml. Il s'agit du nom qui sera référencé à partir des actions de pré- et post-déploiement définies à l'étape du pipeline de diffusion.

  • CONTAINER_NAME

    Il s'agit d'un nom pour le conteneur spécifique. Vous pouvez utiliser le nom de votre choix, mais il doit être unique dans cette skaffold.yaml.

  • IMAGE

    Nom de l'image de conteneur dans laquelle votre commande sera exécutée.

  • COMMANDS_TO_RUN

    Il s'agit d'une liste de points d'entrée à exécuter sur ce conteneur. "/bin/sh" est une commande typique à spécifier ici pour appeler un shell. Vous devez inclure la commande à exécuter dans ce shell dans les arguments.

  • LIST_OF_ARGS

    Il s'agit d'une liste d'arguments à fournir à la commande. Il s'agit d'une liste séparée par des virgules, avec chaque argument entre guillemets. Si votre COMMAND_TO_RUN est "/bin/sh", l'un des arguments ici est "-c", et un autre argument est la commande complète que vous souhaitez exécuter dans le shell que vous appelez.

    Exemple :

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

Pour en savoir plus sur les actions personnalisées Skaffold, consultez la documentation Skaffold.

Configurer le pipeline pour référencer les actions

Pour terminer la configuration de vos hooks de déploiement, vous devez configurer le pipeline de diffusion pour qu'il référence les actions personnalisées que vous avez définies dans votre fichier skaffold.yaml. Les actions de pré- et post-déploiement sont configurées à une ou plusieurs étapes spécifiques de la progression du pipeline.

Voici comment configurer les hooks de pré- et post-déploiement dans une étape de pipeline lorsque vous utilisez une stratégie de déploiement standard:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["PREDEPLOY-ACTION"]
        postdeploy:
          actions: ["POSTDEPLOY-ACTION"]

Dans ce fichier YAML:

  • PREDEPLOY_ACTION

    Correspond à l'ACTION_NAME que vous avez utilisé dans votre skaffold.yaml pour définir l'action personnalisée que vous souhaitez exécuter avant le déploiement.

  • POSTDEPLOY_ACTION

    Il s'agit du même ACTION_NAME que celui que vous avez utilisé dans votre skaffold.yaml pour définir l'action personnalisée que vous souhaitez exécuter après le déploiement.

Vous pouvez spécifier plusieurs actions pour predeploy et postdeploy, séparées par des virgules. Lorsque plusieurs actions sont spécifiées, elles s'exécutent de manière séquentielle, dans l'ordre dans lequel elles sont spécifiées. La tâche (prédéploiement ou postdéploiement) échoue à la première action qui échoue, et les actions restantes ne sont pas exécutées.

Par défaut, si vous exécutez plusieurs conteneurs en parallèle et qu'une tâche échoue, les deux conteneurs sont arrêtés. Vous pouvez configurer ce comportement à l'aide de la stratégie d'échec de l'action personnalisée Skaffold.

Exécuter les hooks sur le cluster d'applications

Par défaut, les hooks de déploiement s'exécutent dans l'environnement d'exécution Cloud Deploy. Vous pouvez également configurer Skaffold pour exécuter ces actions personnalisées sur le même cluster que votre application. Lorsque vous configurez des actions personnalisées dans skaffold.yaml et que vous les activez à une étape de pipeline, l'action s'exécute automatiquement dans le cluster de cette cible.

Cette fonctionnalité n'est disponible que pour les déploiements sur GKE et GKE Enterprise, et non pour Cloud Run. Les déploiements dans Cloud Run ne peuvent exécuter des hooks que dans l'environnement d'exécution Cloud Deploy.

Pour exécuter votre hook sur le cluster, incluez une strophe executionMode.kubernetesCluster dans votre fichier de configuration skaffold.yaml, dans la strophe customActions pour l'action personnalisée spécifique:

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

Voici un exemple de strophe customActions qui inclut executionMode pour appeler le conteneur de hook sur le cluster d'applications:

customActions:
- name: predeploy-action
  containers:
  - name: predeploy-echo
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", 'echo "this is a predeploy action"' ]
  executionMode:
    kubernetesCluster: {}

La strophe executionMode est facultative. Si vous l'omettez, Skaffold exécute le conteneur d'action personnalisée dans l'environnement d'exécution Cloud Deploy.

Variables d'environnement disponibles

Cloud Deploy fournit et renseigne les variables d'environnement suivantes dans l'environnement d'exécution, que vous pouvez utiliser pour vos hooks:

  • ANTHOS_MEMBERSHIP

    Pour les cibles de type ANTHOS, nom de ressource entièrement spécifié de l'appartenance Anthos.

  • CLOUD_RUN_LOCATION

    Pour les cibles de type RUN, la région dans laquelle le service Cloud Run est déployé.

  • CLOUD_RUN_PROJECT

    Pour les cibles de type RUN, le projet dans lequel le service Cloud Run a été créé.

  • CLOUD_RUN_SERVICE

    Pour les cibles de type RUN, nom du service Cloud Run déployé.

  • CLOUD_RUN_SERVICE_URLS

    Pour les cibles de type RUN, l'URL ou les URL (liste séparée par une virgule) que les utilisateurs finaux utiliseront pour accéder à votre service. Vous les trouverez dans les détails du service Cloud Run pour votre service, dans la console Google Cloud.

  • CLOUD_RUN_REVISION

    Pour les cibles de type RUN, la révision spécifique du service Cloud Run.

  • GKE_CLUSTER

    Pour les cibles de type GKE, nom de ressource entièrement spécifié du cluster Google Kubernetes Engine, par exemple projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    Type d'environnement d'exécution spécifique de la cible. GKE, ANTHOS ou RUN. Pour les cibles personnalisées, ce paramètre ne sera pas défini.

  • CLOUD_DEPLOY_LOCATION

    Région contenant les ressources Cloud Deploy.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    ID du pipeline de diffusion.

  • CLOUD_DEPLOY_TARGET

    ID de la cible.

  • CLOUD_DEPLOY_PROJECT

    Projet Google Cloud contenant les ressources Cloud Deploy.

  • CLOUD_DEPLOY_RELEASE

    ID de la version dans laquelle les hooks s'exécuteront.

  • CLOUD_DEPLOY_ROLLOUT

    ID du déploiement contenant les tâches des hooks.

  • CLOUD_DEPLOY_JOB_RUN

    ID de l'exécution de la tâche qui représente l'exécution actuelle de la tâche.

  • CLOUD_DEPLOY_PHASE

    Phase du déploiement qui contient la tâche pour les hooks.

Déployer des paramètres en tant que variables d'environnement

En plus des variables d'environnement listées dans cette section, Cloud Deploy peut transmettre à vos conteneurs personnalisés tous les paramètres de déploiement que vous avez définis.

En savoir plus

Étape suivante