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 sur 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 :

Canary fonctionne également avec les cibles multiples.

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 vers les nouveaux pods.

Si vous déployez sur Cloud Run, Cloud Run lui-même répartit le trafic entre les anciennes et les nouvelles révisions, en fonction des pourcentages que vous configurez.

Types de canary

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

  • Automatique

    Avec un déploiement canary automatisé (pour Service Networking, l'API Gateway ou Cloud Run), 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 les anciennes et les nouvelles versions.

  • Personnalisé et automatisé

    Pour un canary personnalisé et automatisé (pour Service Networking, Gateway API ou Cloud Run), vous pouvez fournir les éléments suivants :

    • Nom de la phase
    • Objectif en pourcentage
    • Profil Skaffold à utiliser pour la phase
    • Indique si un job de validation doit être inclus.
    • Indique si vous souhaitez inclure un job predeploy ou postdeploy, 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 (pour Service Networking, l'API Gateway ou Cloud Run).

  • Personnalisé

    Avec un canary personnalisé (pour service networking, gateway api ou Cloud Run), vous configurez chaque phase canary séparément, y compris les éléments suivants :

    • Nom de la phase
    • Objectif en pourcentage
    • Profil Skaffold à utiliser pour la phase
    • Indique si un job de validation doit être inclus.
    • Indique si vous souhaitez inclure un job predeploy ou postdeploy, ou les deux.

    De plus, pour un canary entièrement personnalisé, vous fournissez toute la configuration d'équilibrage du trafic.

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 finale stable pour 100 %.

Par exemple, si vous configurez un déploiement Canary avec 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 Gérer les déploiements.

Utiliser le 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 vers laquelle vous déployez progressivement peut comprendre deux cibles enfants ou plus. Par exemple, vous pouvez effectuer un déploiement progressif sur des clusters situés dans des régions distinctes, en même temps.

En quoi un canary parallèle est-il différent d'un canary à cible unique ?

  • Comme pour le déploiement canary à cible unique, si vous déployez sur 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 à une seule cible, la configuration de votre pipeline de diffusion doit inclure une strophe strategy.canary dans la définition de l'étape concernée.

  • De plus, vous devez configurer un groupe multicible et configurer les cibles enfants auxquelles ce groupe multicible fait référence.

  • Lorsque vous créez une version, un déploiement contrôleur et les 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 canary configurés, ainsi qu'une phase stable pour le canary à 100 %.

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

    Vous ne pouvez faire progresser que les déploiements de contrôleurs. Lorsque vous faites passer 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 jobs ayant échoué lors du déploiement du contrôleur.

    Vous ne pouvez relancer un job que dans les déploiements enfants.

  • Vous ne pouvez pas ignorer les jobs 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 pouvez mettre fin aux exécutions de job sous un déploiement enfant uniquement, et non sous un déploiement contrôleur.

Que faire en cas d'échec d'un déploiement parallèle dans Canary

Lorsqu'un déploiement enfant échoue, le déploiement 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 réussit, le déploiement du contrôleur est HALTED s'il y a d'autres phases après la phase actuelle.

    Si la phase est stable, le déploiement du contrôleur est FAILED.

    HALTED vous permet d'ignorer ou de réessayer les jobs ayant échoué dans le déploiement enfant en échec, ou d'annuler le déploiement du contrôleur et d'empêcher d'autres actions sur les déploiements enfants.

  • Si le déploiement du contrôleur est à l'état HALTED en raison d'un déploiement enfant ayant échoué, et que vous ignorez le job ayant échoué dans le déploiement enfant, le déploiement du contrôleur revient à l'état IN_PROGRESS.

Étapes suivantes