Utiliser une stratégie de déploiement Canary

Ce document explique comment configurer et utiliser une stratégie de déploiement Canary.

Qu'est-ce qu'un déploiement Canary ?

Un déploiement Canary est un déploiement progressif d'une application qui répartit le trafic entre une version déjà déployée et une nouvelle version, en la déployant auprès d'un sous-ensemble d'utilisateurs avant de la déployer complètement.

Types de cibles compatibles

Le déploiement Canary dans Cloud Deploy est compatible avec tous les types de cibles, y compris les suivants:

• Google Kubernetes Engine
• Cloud Run (services uniquement, pas de jobs)
• GKE Enterprise

Canary fonctionne également avec les multicibles.

Pourquoi utiliser une stratégie de déploiement Canary ?

Un déploiement Canary vous permet de publier partiellement votre application. Vous pouvez ainsi vous assurer que la nouvelle version de votre application est fiable avant de la déployer pour tous les utilisateurs.

Si vous effectuez un déploiement sur GKE ou GKE Enterprise, par exemple, vous déployez la nouvelle version de votre application sur un nombre limité de pods. L'ancienne version continuerait de s'exécuter, mais une plus grande partie du trafic serait envoyée aux nouveaux pods.

Si vous effectuez un déploiement sur Cloud Run, Cloud Run répartit lui-même le trafic entre l'ancienne et la nouvelle version, en fonction des pourcentages que vous configurez.

Types de canari

Cloud Deploy vous permet de configurer les types de déploiement Canary suivants:

• Automatique

  Avec un déploiement canari automatique, vous configurez Cloud Deploy avec une série de pourcentages qui expriment un déploiement progressif. Cloud Deploy effectue des opérations supplémentaires en votre nom pour répartir les pourcentages de trafic entre l'ancienne et la nouvelle version.

• Automatisé sur mesure

  Pour un canari automatisé personnalisé, vous pouvez fournir les éléments suivants:

  • Nom de la phase
  • L'objectif en pourcentage
  • Profil Skaffold à utiliser pour la phase
  • Indique si une tâche de validation doit être incluse ou non.
  • Indique si vous souhaitez inclure une tâche de prédéploiement ou de postdéploiement, ou les deux.

  Toutefois, vous n'avez pas besoin de fournir d'informations sur l'équilibrage du trafic. Cloud Deploy crée les ressources nécessaires.

• Personnalisé

  Avec un canari personnalisé, vous configurez chaque phase de canari séparément, y compris les éléments suivants:

  • Nom de la phase
  • L'objectif en pourcentage
  • Profil Skaffold à utiliser pour la phase
  • Indique si une tâche de validation doit être incluse ou non.
  • Indique si vous souhaitez inclure une tâche de prédéploiement ou de postdéploiement, ou les deux.

  De plus, pour un canari entièrement personnalisé, vous devez fournir l'ensemble de la configuration d'équilibrage de charge, comme décrit ici.

Phases d'un déploiement Canary

Lorsque vous créez une version pour un déploiement Canary, le déploiement est créé avec une phase pour chaque incrément Canary, plus une phase stable finale pour 100%.

Par exemple, si vous configurez un canari pour des incréments de 25%, 50 % et 75 %, le déploiement se déroulera en plusieurs phases:

• canary-25
• canary-50
• canary-75
• stable

Pour en savoir plus sur les phases de déploiement, les tâches et les exécutions de tâches, consultez la page Gérer les déploiements.

Que se passe-t-il lors d'un canari automatique ou personnalisé ?

Pour prendre en charge votre déploiement canari, Cloud Deploy inclut des étapes de traitement spéciales lors de l'affichage de votre fichier manifeste Kubernetes ou de la configuration de votre service Cloud Run:

Si vous souhaitez voir les différences entre les phases d'un déploiement Canary, vous pouvez afficher les modifications apportées au fichier manifeste affiché par phase disponible dans l'inspecteur de version. Vous pouvez le faire avant même le début du déploiement. En outre, si vous utilisez le déploiement parallèle, vous pouvez également inspecter le fichier manifeste affiché de chaque enfant.

Configurer un déploiement Canary

Cette section explique comment configurer votre pipeline de diffusion et vos cibles pour un déploiement canari.

Les instructions ci-dessous ne concernent que ce qui est spécifique à la configuration du canari. Le document Déploiement de votre application contient les instructions générales pour configurer et exécuter votre pipeline de déploiement.

Assurez-vous de disposer des autorisations requises

En plus des autres autorisations de Identity and Access Management dont vous avez besoin pour utiliser Cloud Deploy, vous avez besoin des autorisations suivantes pour effectuer des actions supplémentaires qui peuvent être nécessaires pour un déploiement canari:

• clouddeploy.rollouts.advance
• clouddeploy.rollouts.ignoreJob
• clouddeploy.rollouts.cancel
• clouddeploy.rollouts.retryJob
• clouddeploy.jobRuns.get
• clouddeploy.jobRuns.list
• clouddeploy.jobRuns.terminate

Pour en savoir plus sur les rôles disponibles qui incluent ces autorisations, consultez la section Rôles et autorisations IAM.

Préparation de votre skaffold.yaml

Comme pour un déploiement standard, votre canari a besoin d'un fichier skaffold.yaml, qui définit la façon dont les fichiers manifestes et les définitions de service sont affichés et déployés.

Le skaffold.yaml que vous créez pour un déploiement Canary n'a pas d'exigences particulières au-delà de ce qui est nécessaire pour le déploiement standard.

Préparer votre fichier manifeste ou votre définition de service

Comme pour un déploiement standard, votre canari a besoin d'un fichier manifeste Kubernetes ou d'une définition de service Cloud Run.

Configurer un canari automatisé

Les instructions suivantes s'appliquent aux cibles de mise en réseau basées sur les services Cloud Run, GKE et GKE Enterprise. Si vous utilisez l'API Kubernetes Gateway avec GKE ou GKE Enterprise, consultez cette documentation.

Vous configurez le canari automatisé dans la définition de votre pipeline de livraison:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

Configurer un canari personnalisé

Vous pouvez configurer votre canari manuellement au lieu de vous appuyer entièrement sur l'automatisation fournie par Cloud Deploy. Avec la configuration personnalisée du canari, vous spécifiez les éléments suivants dans la définition de votre pipeline de diffusion:

• Noms des phases de déploiement

  Dans un canari entièrement automatisé, Cloud Deploy nomme les phases à votre place (canary-25, canary-75, stable, par exemple). Toutefois, avec un canari personnalisé, vous pouvez attribuer n'importe quel nom à chaque phase, à condition qu'il soit unique parmi toutes les phases de cette phase de canari et qu'il respecte les restrictions de nom de ressource. Toutefois, le nom de la phase finale (100%) doit être stable.

• Objectifs en pourcentage pour chaque phase

  Spécifiez les pourcentages séparément, par phase.

• Profils Skaffold à utiliser pour la phase

  Vous pouvez utiliser un profil Skaffold distinct pour chaque phase, ou le même profil, ou toute combinaison. De plus, chaque profil peut utiliser un fichier manifeste Kubernetes ou une définition de service Cloud Run différents. Vous pouvez également utiliser plusieurs profils pour une phase donnée. Cloud Deploy les combine.

• Indique si une tâche de validation est associée à la phase

  N'oubliez pas que si vous activez la validation, vous devez également configurer votre skaffold.yaml pour la validation.

• Indique si des tâches de prédéploiement ou de postdéploiement sont prévues pour la phase

  Si vous activez des tâches de prédéploiement ou de postdéploiement, vous devez configurer votre skaffold.yaml pour ces tâches.

Tous les types de cibles sont compatibles avec le canari personnalisé.

Éléments de configuration Canary personnalisés

Le code YAML suivant montre la configuration des phases de déploiement de canari entièrement personnalisé:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

Dans ce fichier YAML

• PHASE1_NAME

  Indique le nom de la phase. Chaque nom de phase doit être unique.

• [ "PROFILE_NAME" ]

  Nom du profil à utiliser pour la phase. Vous pouvez utiliser le même profil pour chaque phase, un profil différent pour chacune d'elles ou une combinaison des deux. Vous pouvez également spécifier plusieurs profils. Cloud Deploy utilise tous les profils que vous spécifiez, ainsi que le profil ou le fichier manifeste utilisé par l'étape globale.

• stable

  La phase finale doit être nommée stable.

• PERCENTAGE1

  Il s'agit du pourcentage à déployer pour la première phase. Chaque phase doit avoir une valeur de pourcentage unique, qui doit être un pourcentage entier (par exemple, pas 10.5), et les phases doivent être triées par ordre croissant.

• verify: true|false

  Indique à Cloud Deploy s'il doit inclure une tâche de validation pour la phase. Notez que pour chaque phase à utiliser pour la validation, Skaffold utilise le même profil de validation que celui spécifié pour l'affichage et le déploiement de cette phase.

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

Le pourcentage de la dernière phase doit être 100. Les phases sont exécutées dans l'ordre que vous configurez dans cette strophe ​customCanaryDeployment, mais si les valeurs de pourcentage ne sont pas dans l'ordre croissant, la commande d'enregistrement du pipeline de diffusion échoue avec une erreur.

Notez que la configuration d'un canari personnalisé n'inclut pas de strophe runtimeConfig. Si vous incluez runtimeConfig, il est considéré comme un canari automatisé personnalisé.

Configurer un canari personnalisé et automatisé

Un canari automatisé personnalisé est semblable à un canari personnalisé, car vous spécifiez les phases de canari distinctes, avec des noms de phases personnalisés, des valeurs de pourcentage, des profils Skaffold, des tâches de validation, ainsi que des tâches de prédéploiement et de postdéploiement. Toutefois, avec un canari personnalisé, vous ne fournissez pas les configurations qui définissent la répartition du trafic. Cloud Deploy s'en charge, mais vous devez tout de même fournir les profils Skaffold à utiliser pour chaque étape.

Pour configurer un canari automatisé personnalisé, incluez une strophe runtimeConfig, comme indiqué ici, et incluez la strophe customCanaryDeployment, comme indiqué ici.

Configurer un déploiement canari à l'aide du maillage de services de l'API Kubernetes Gateway

Bien que vous puissiez utiliser un déploiement canari Cloud Deploy pour déployer votre application sur un réseau Kubernetes basé sur les services, vous pouvez également utiliser le maillage de services de l'API Kubernetes Gateway. Cette section explique comment procéder.

Vous pouvez utiliser l'API Gateway avec Istio ou toute implémentation compatible.

1. Configurez vos ressources de l'API Gateway:

   • Utiliser Istio

   • Contrôleur GKE Gateway

   Ce ne sont que des exemples.

2. Dans votre fichier manifeste Kubernetes, fourni à Cloud Deploy lorsque vous avez créé la version, incluez les éléments suivants:

   • Un HTTPRoute qui fait référence à votre ressource de passerelle

   • Un déploiement

   • Un service

3. Configurez votre pipeline de diffusion et la cible à laquelle vous allez effectuer un déploiement Canary:

   • La configuration de la cible est la même que pour n'importe quelle cible.

   • La configuration du pipeline de diffusion, dans la séquence de progression de la cible spécifique, inclut une strophe gatewayServiceMesh pour référencer votre configuration HTTPRoute de l'API Kubernetes Gateway, ainsi que votre déploiement et votre service.

     strategy:
      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "ROUTE"
              service: "SERVICE"
              deployment: "DEPLOYMENT"
              routeUpdateWaitTime: "WAIT_TIME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages:
          - 50
     

     Où...

     • ROUTE est votre configuration httpRoute qui définit le comportement de routage souhaité.

     • SERVICE correspond à la configuration de votre service, qui est requise par Cloud Deploy pour les déploiements canari sur GKE et GKE Enterprise.

     • DEPLOYMENT correspond à votre configuration de déploiement, qui est requise par Cloud Deploy pour les déploiements canari sur GKE et GKE Enterprise.

     • WAIT_TIME correspond au délai d'attente de Cloud Deploy pour que les modifications apportées à la ressource HTTPRoute soient propagées, afin d'éviter les requêtes abandonnées. Par exemple : routeUpdateWaitTime: 60s.

       Si vous exécutez un canari à l'aide de l'API Gateway sans Istio et que l'API Gateway est connectée à un équilibreur de charge Google Cloud, une petite quantité de trafic peut être perdue lorsque l'instance de canari est réduite. Vous pouvez configurer ce paramètre si vous observez ce comportement.

     • LABEL est un libellé de sélecteur de pod. Il doit correspondre au sélecteur d'étiquettes dans le service et le déploiement Kubernetes définis dans votre fichier manifeste. Cette opération est facultative. La valeur par défaut est app.

Utiliser un déploiement parallèle avec une stratégie de déploiement Canary

Vous pouvez exécuter un déploiement Canary à l'aide du déploiement parallèle. Cela signifie que la cible à laquelle vous déployez progressivement peut comprendre deux ou plusieurs cibles enfants. Par exemple, vous pouvez déployer progressivement dans des clusters situés dans des régions distinctes, en même temps.

En quoi un canari parallèle est-il différent des canaris à cible unique ?

• Comme pour le déploiement canari à cible unique, si vous déployez vers des cibles GKE, vous avez besoin d'une configuration de déploiement Kubernetes et d'une configuration de service Kubernetes dans votre fichier manifeste.

• Comme pour le déploiement Canary à cible unique, la configuration de votre pipeline de diffusion doit inclure une strophe strategy.canary dans la définition de l'étape applicable.

• Vous devez également configurer un groupe multicible et configurer les cibles enfants qu'il référence.

• Lorsque vous créez une version, un déploiement du contrôleur et des déploiements enfants sont créés.

  Les deux types de déploiement (contrôleur et enfant) comportent des phases distinctes pour tous les pourcentages de canari configurés, ainsi qu'une phase stable pour le canari à 100%.

• Vous ne pouvez pas avancer un déploiement enfant.

  Vous ne pouvez avancer que les déploiements de contrôleurs. Lorsque vous passez le déploiement du contrôleur à l'étape suivante, les déploiements enfants sont également avancés par Cloud Deploy.

• Vous ne pouvez pas réessayer les tâches ayant échoué lors du déploiement du contrôleur.

  Vous ne pouvez réessayer une tâche que dans les déploiements enfants.

• Vous ne pouvez pas ignorer les tâches ayant échoué lors du déploiement du contrôleur.

  Vous ne pouvez ignorer les jobs ayant échoué que dans les déploiements enfants.

• Vous pouvez annuler un déploiement de contrôleur, mais pas les déploiements enfants.

• Vous ne pouvez arrêter les exécutions de tâches que dans le cadre d'un déploiement enfant, et non d'un déploiement de contrôleur.

Que faire si un déploiement parallèle échoue dans Canary ?

Lorsqu'un déploiement enfant échoue, le déploiement du contrôleur peut passer à différents états, en fonction de ce qui se passe avec les déploiements enfants:

• Si un ou plusieurs déploiements enfants échouent, mais qu'au moins un déploiement enfant est toujours IN_PROGRESS, le déploiement du contrôleur reste IN_PROGRESS.

• Si un ou plusieurs déploiements enfants échouent, mais qu'au moins un déploiement enfant aboutit, le déploiement du contrôleur est HALTED s'il y a d'autres phases après la phase actuelle.

  S'il s'agit de la phase stable, le déploiement du contrôleur est FAILED.

  HALTED vous permet d'ignorer ou de relancer les jobs qui ont échoué dans le déploiement enfant, ou d'annuler le déploiement du contrôleur et d'empêcher toute autre action sur les déploiements enfants.

• Si le déploiement du contrôleur est dans un état HALTED en raison d'un échec de déploiement enfant et que vous ignorez la tâche ayant échoué dans le déploiement enfant, le déploiement du contrôleur revient à un état IN_PROGRESS.

Déployer une route HTTP vers un autre cluster

Lorsque vous avez configuré un canari à l'aide du maillage de services de l'API Gateway, vous pouvez spécifier un autre cluster non cible sur lequel déployer HTTPRoute.

Pour ce faire, vous utilisez une strophe routeDestinations, dans la configuration de votre stratégie canari, pour identifier le ou les clusters de destination de l'HTTPRoute, ainsi qu'un paramètre booléen pour propager le service au même cluster non cible. Vous créez également une strophe associatedEntities dans votre configuration cible pour identifier les clusters.

1. Configurez associatedEntities sur votre cible.

   Chaque entité est un cluster dans lequel Cloud Deploy déploie HTTPRoute et, éventuellement, le service Kubernetes. Dans votre définition de cible, incluez une strophe associatedEntities:

   associatedEntities:
     [KEY]:
       gkeClusters:
       - cluster: [PATH]
         internalIp: [true|false]
         proxyUrl:
   

   Où :

   • KEY est un nom arbitraire pour ce groupe d'entités associées. Vous utiliserez ce nom pour faire référence aux entités de routeDestinations dans votre configuration Canary.

   • PATH est le chemin de ressource identifiant le cluster GKE dans lequel votre HTTPRoute (et éventuellement le service) sera déployé.

   • internalIp indique si vous souhaitez utiliser l'adresse IP interne (adresse IP privée) si le cluster dispose à la fois d'une adresse IP interne et d'une adresse IP publique configurées. La valeur par défaut est false.

   Vous pouvez inclure autant de clusters que vous le souhaitez, avec ou sans internalIp.

2. Configurez routeDestinations dans votre configuration Canary.

   Chaque destination de route fait référence à une strophe associatedEntities et indique si le service doit également être déployé sur le cluster de remplacement. Ajoutez le code suivant dans le stanza gatewayServiceMesh de votre configuration Canary:

   routeDestinations:
     destinationIds: ["KEY"]
     propagateService: [true|false]
   

   Où :

   • KEY correspond au nom que vous avez configuré dans la cible, dans associatedEntities. Utilisez ce nom pour faire référence aux entités de l'routeDestinations dans votre configuration Canary.

     Vous pouvez également fournir la valeur @self pour déployer HTTPRoute sur le cluster cible en plus de la destination associée.

   • propagateService indique si vous souhaitez ou non déployer le service dans le cluster associé, en plus de la route HTTPRoute. La valeur par défaut est false.

Exécuter le canari configuré

Pour exécuter le déploiement Canary:

1. Enregistrez le pipeline de diffusion et les cibles configurés.

   gcloud deploy apply --file=PIPELINE
   

   Le pipeline de diffusion inclut la configuration Canary automatique ou personnalisée pour l'environnement d'exécution de votre choix.

   Cette commande suppose que vos cibles sont définies dans le même fichier ou qu'elles ont déjà été enregistrées. Dans le cas contraire, veillez également à enregistrer vos cibles.

2. Créez une version:

   gcloud deploy releases create RELEASE_NAME \
                                 --delivery-pipeline=PIPELINE_NAME \
                                 --region=REGION
   

   Le pipeline de diffusion identifié par PIPELINE_NAME contient la configuration Canary automatisée ou personnalisée décrite dans ce document.

3. Développez le canari:

   CLI gcloud

   gcloud deploy rollouts advance ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION
   

   Où :

   ROLLOUT_NAME est le nom du déploiement en cours que vous passez à la phase suivante.

   RELEASE_NAME est le nom de la version de ce déploiement.

   PIPELINE_NAME est le nom du pipeline de diffusion que vous utilisez pour gérer le déploiement de cette version.

   REGION correspond au nom de la région dans laquelle la version a été créée, par exemple us-central1. Ce champ est obligatoire.

   Pour en savoir plus sur la commande gcloud deploy rollouts advance, consultez la documentation de référence de Google Cloud SDK.

   Console Google Cloud

   1. Ouvrez la page des pipelines de diffusion.

   2. Cliquez sur votre pipeline dans la liste des pipelines de diffusion.

      La page "Détails du pipeline de diffusion" affiche une représentation graphique de la progression de votre pipeline de diffusion.

   3. Dans l'onglet Déploiements, sous Détails du pipeline de diffusion, cliquez sur le nom de votre déploiement.

      La page des détails du déploiement s'affiche.

      

      Notez que dans cet exemple, le déploiement comporte une phase canary-50 et une phase stable. Votre déploiement peut comporter plus de phases ou des phases différentes.

   4. Cliquez sur Avancer le déploiement.

      Le déploiement passe à la phase suivante.

Phases ignorées

Si vous déployez un canari et que votre application n'a pas encore été déployée sur cet environnement d'exécution, Cloud Deploy ignore la phase de canari et exécute la phase stable. Consultez Ignorer des phases la première fois pour savoir pourquoi cela se produit.

Étape suivante

• Suivez le guide de démarrage rapide du déploiement canari.

• Découvrez comment gérer le cycle de vie des déploiements de votre canari.

• En savoir plus sur le déploiement en parallèle