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:

Canary fonctionne également avec plusieurs cibles.

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

Un déploiement Canary vous permet de déployer partiellement votre application. De cette manière, vous pouvez vous assurer que la nouvelle version de votre application est fiable avant de la diffuser auprès de tous les utilisateurs.

Par exemple, si vous effectuez un déploiement sur GKE ou GKE Enterprise, vous devez déployer la nouvelle version de votre application sur un nombre limité de pods. L'ancienne version continue de fonctionner, mais une plus grande partie du trafic est 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 révision, en fonction des pourcentages que vous configurez.

Types de versions Canary

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

  • Automatique

    Avec un déploiement Canary automatisé, vous configurez Cloud Deploy avec une série de pourcentages représentant un déploiement progressif. Cloud Deploy effectue des opérations supplémentaires en votre nom afin de répartir les pourcentages de trafic entre l'ancienne et la nouvelle version.

  • Automatisation personnalisée

    Pour une version Canary automatisée personnalisée, vous pouvez fournir les éléments suivants:

    • Nom de la phase
    • L'objectif en pourcentage
    • Le profil Skaffold à utiliser pour la phase
    • Inclure ou non une tâche de vérification

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

  • personnalisée ;

    Avec une version Canary personnalisée, vous configurez chaque phase Canary séparément, y compris les suivantes:

    • Nom de la phase
    • L'objectif en pourcentage
    • Le profil Skaffold à utiliser pour la phase
    • Inclure ou non une tâche de vérification

    En outre, pour une version Canary entièrement personnalisée, vous devez fournir toute la configuration de l'équilibrage du trafic, 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 finale stable pour 100%.

Par exemple, si vous configurez une version Canary pour des incréments de 25%, 50 % et 75 %, le déploiement se déroule selon les phases suivantes:

  • 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 pendant une période Canary automatisée ou personnalisée

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

GKE/GKE Enterprise (réseau)

Voici comment Cloud Deploy exécute un déploiement Canary dans GKE et GKE Enterprise basés sur le réseau:

  1. Vous devez indiquer le nom de la ressource de déploiement et de la ressource de service.

  2. Cloud Deploy crée une ressource de déploiement supplémentaire, avec le nom de votre déploiement actuel suivi de -canary.

  3. Cloud Deploy modifie le service pour ajuster le sélecteur afin de sélectionner les pods du déploiement actuel et les pods Canary.

    Cloud Deploy calcule le nombre de pods à utiliser pour la version Canary en fonction du calcul décrit ici. Ce calcul diffère selon que vous avez activé ou désactivé le surprovisionnement des pods.

    Si vous passez à la phase stable, Cloud Deploy ajoute les étiquettes à utiliser pour faire correspondre les pods, afin qu'elles soient disponibles pour les exécutions Canary ultérieures.

    Cloud Deploy crée un déploiement qui inclut le pourcentage de pods spécifique à chaque phase, en le mettant à jour pour chaque phase. Pour ce faire, calculez le nombre de pods sous la forme d'un pourcentage du nombre d'origine de pods. Cela peut entraîner une répartition du trafic inexacte. Si vous avez besoin d'une répartition exacte du trafic, vous pouvez l'obtenir à l'aide de l'API Gateway.

    Les secrets et les ConfigMaps sont également copiés et renommés avec -canary.

  4. Pendant la phase stable, le déploiement -canary est réduit à zéro et le déploiement d'origine est remplacé par le nouveau.

    Cloud Deploy ne modifie pas le déploiement d'origine avant la phase stable.

Cloud Deploy provisionne les pods pour atteindre le pourcentage Canary demandé le plus près possible. Cette valeur est basée sur le nombre de pods, et non sur le trafic vers les pods. Si vous souhaitez que votre version Canary soit basée sur le trafic, vous devez utiliser l'API Gateway.

Pour la version Canary basée sur le réseau de GKE, vous pouvez activer ou désactiver le surprovisionnement des pods. Les sections suivantes décrivent comment Cloud Deploy calcule le nombre de pods à provisionner pour le déploiement Canary pour chaque phase Canary.

Provisionnement des pods avec surprovisionnement activé

L'activation du surprovisionnement (disablePodOverprovisioning: false) permet à Cloud Deploy de créer suffisamment de pods supplémentaires pour exécuter le pourcentage Canary souhaité, en fonction du nombre de pods exécutant votre déploiement existant. La formule suivante montre comment Cloud Deploy calcule le nombre de pods à provisionner pour le déploiement Canary pour chaque phase Canary, lorsque le surprovisionnement des pods est activé:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Avec cette formule, le nombre actuel d'instances répliquées (le nombre de pods que vous possédez déjà avant cette version Canary) est multiplié par le pourcentage Canary pour la phase, puis divisé par (100 moins le pourcentage).

Par exemple, si quatre pods sont déjà en fin de vie et que la phase Canary est de 50%, le nombre de pods Canary est de quatre. (Le résultat de 100-percentage est utilisé sous forme de pourcentage: 100-50=50, traité comme .50.)

Le surprovisionnement des pods est le comportement par défaut.

Provisionnement des pods avec surprovisionnement désactivé

Vous pouvez désactiver le surprovisionnement (disablePodOverprovisioning: true) pour vous assurer que Cloud Deploy n'augmente pas le nombre d'instances répliquées.

La formule suivante montre comment Cloud Deploy calcule le provisionnement des pods pour le déploiement Canary pour chaque phase Canary, lorsque le surprovisionnement des pods est désactivé:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

Dans cette formule, ReplicaCountOfCanaryDeploymentOnCluster n'existe que s'il existe déjà une phase Canary. S'il s'agit de la première phase Canary, il n'y a pas de ReplicaCountOfCanaryDeploymentOnCluster.

Si vous commencez avec quatre pods, ce nombre est multiplié par le pourcentage Canary (par exemple, 50%, ou .5) pour obtenir 2. Le déploiement d'origine est donc réduit à deux pods, et deux pods sont créés pour le déploiement Canary. Si la phase Canary s'élève à 75 %, vous disposez de 2 (déploiement d'origine) +2 (première étape Canary), *.75, pour obtenir 3 pods Canary et 1 pods exécutant le déploiement d'origine.

GKE/GKE Enterprise (passerelle)

Voici comment Cloud Deploy exécute un déploiement Canary dans GKE et GKE Enterprise à l'aide de l'API Gateway:

  1. En plus des références au déploiement et au service, vous fournissez une ressource HTTPRoute, avec une règle backendRefs qui référence le service.

  2. Cloud Deploy crée un déploiement, avec le nom de votre déploiement d'origine suivi de -canary, et un nouveau service avec le nom d'origine du service suivi de -canary.

    Les secrets, les ConfigMaps et les autoscalers horizontaux de pods sont également copiés et renommés avec -canary.

  3. Pour chaque phase Canary, Cloud Deploy modifie la méthode HTTPRoute afin de mettre à jour la pondération entre les pods du déploiement d'origine et les pods du déploiement Canary, en fonction du pourcentage correspondant à cette phase.

    Étant donné que la propagation des modifications aux ressources HTTPRoute peut prendre un certain temps, vous pouvez inclure la propriété routeUpdateWaitTime dans votre configuration afin que le système attende un certain temps pour cette propagation.

  4. Pendant la phase stable, le déploiement -canary est réduit à zéro et le déploiement d'origine est mis à jour pour utiliser le déploiement de la nouvelle version.

    De plus, la version d'origine que vous avez fournie est désormais rétablie pour HTTPRoute.

    Cloud Deploy ne modifie pas le déploiement ni le service d'origine avant la phase stable.

Cloud Run

Voici comment Cloud Deploy exécute un déploiement Canary pour Cloud Run:

  • Pour un déploiement Canary sur Cloud Run, ne fournissez pas de stanza traffic dans le fichier YAML de service.

  • Lors de la création d'un déploiement pour la version Canary, Cloud Deploy répartit le trafic entre la révision précédente qui a été déployée avec succès par Cloud Deploy et une nouvelle révision.

Si vous souhaitez afficher les différences entre les phases d'un déploiement Canary, vous pouvez afficher les modifications dans le 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 en parallèle, vous pouvez également inspecter le fichier manifeste affiché pour chaque enfant.

Configurer un déploiement Canary

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

Les instructions fournies ici n'incluent que les éléments spécifiques à la configuration Canary. Le document Déployer votre application contient des 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 Identity and Access Management dont vous avez besoin pour utiliser Cloud Deploy, vous devez disposer des autorisations suivantes pour effectuer les actions supplémentaires qui peuvent être nécessaires dans un déploiement Canary:

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

Consultez la page Rôles et autorisations IAM pour en savoir plus sur les rôles disponibles qui incluent ces autorisations.

Préparez votre skaffold.yaml

Comme pour un déploiement standard, votre version Canary a besoin d'un fichier skaffold.yaml, qui définit la manière dont les fichiers manifestes et les définitions de service sont affichés et déployés.

Le fichier skaffold.yaml que vous créez pour un déploiement Canary ne présente aucune exigence particulière en plus des requis pour le déploiement standard.

Préparer le fichier manifeste ou la définition du service

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

GKE et GKE Enterprise

Pour la version Canary, le fichier manifeste doit comporter les éléments suivants:

  • Un déploiement et un service.

  • Le service doit définir un sélecteur app et sélectionner les pods du déploiement spécifié.

  • Si vous utilisez une version Canary basée sur l'API Gateway, le fichier manifeste doit également comporter une HTTPRoute.

Cloud Run

Pour la version Canary sur Cloud Run, votre fichier de définition de service Cloud Run normal est suffisant, mais sans stanza traffic. Cloud Deploy gère la répartition du trafic entre la dernière révision réussie et la nouvelle.

Configurer une version Canary automatisée

Les instructions suivantes concernent les cibles de mise en réseau basée 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 la version Canary automatisée dans la définition de votre pipeline de livraison:

GKE et GKE Enterprise

À l'étape du pipeline, incluez une propriété strategy, comme suit:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

Dans cette configuration...

  • SERVICE_NAME est le nom du service Kubernetes, défini dans votre fichier manifeste.

  • DEPLOYMENT_NAME est le nom de votre déploiement Kubernetes, défini dans votre fichier manifeste.

  • PERCENTAGES est une liste de valeurs en pourcentage séparées par une virgule représentant vos incréments Canary, par exemple [5, 25, 50].

    Cela n'inclut pas non plus 100, car le déploiement à 100% est supposé dans la version Canary et géré par la phase stable.

  • Vous pouvez activer la validation du déploiement (verify: true). Dans ce cas, une tâche verify est activée à chaque phase.

Cloud Run

À l'étape du pipeline, incluez une propriété strategy, comme suit:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

Dans cette configuration...

  • PERCENTAGES est une liste de valeurs en pourcentage séparées par une virgule représentant vos incréments Canary, par exemple [25, 50, 75]. Notez que cela n'inclut pas 100, car le déploiement à 100% est assumé dans la version Canary et est géré par la phase stable.
  • Vous pouvez activer la validation du déploiement (verify: true). Dans ce cas, une tâche verify est ajoutée à chaque phase Canary.

Configurer une version Canary personnalisée

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

  • Noms des phases de déploiement

    Dans une version Canary entièrement automatisée, Cloud Deploy nomme automatiquement les phases (canary-25, canary-75 et stable, par exemple). Toutefois, avec une version Canary personnalisée, vous pouvez attribuer n'importe quel nom à chaque phase, à condition qu'il soit unique parmi toutes les phases de cette phase Canary et qu'il respecte les restrictions de nom de ressource. Mais le nom final de la phase (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, le même profil ou n'importe quelle combinaison. Chaque profil peut utiliser un fichier manifeste Kubernetes ou une définition de service Cloud Run différente. Vous pouvez également utiliser plusieurs profils pour une phase donnée. Cloud Deploy les combine.

  • Existence ou non d'une tâche de vérification pour la phase

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

Tous les types de cibles sont compatibles avec les versions Canary personnalisées.

Éléments de configuration Canary personnalisés

Le fichier YAML suivant présente la configuration des phases d'un déploiement Canary entièrement personnalisé:

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

Dans ce fichier YAML

  • PHASE1_NAME

    Il s'agit du nom de la phase. Chaque nom de phase doit être unique.

  • [ "PROFILE_NAME" ]

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

  • PERCENTAGE1

    Pourcentage à déployer pour la première phase. Chaque phase doit avoir une valeur de pourcentage unique, qui doit être un pourcentage entier (et non 10.5, par exemple). Les phases doivent être dans l'ordre croissant.

  • verify: true|false

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

  • stable

    La phase finale doit être nommée stable.

Le pourcentage pour la dernière phase doit être 100. Les phases sont exécutées dans l'ordre dans lequel vous les avez configurées dans ce stanza ​customCanaryDeployment, mais si les valeurs de pourcentage ne sont pas dans l'ordre croissant, la commande d'enregistrement du pipeline de livraison échoue et génère une erreur.

Notez que la configuration d'une version Canary personnalisée n'inclut pas de stanza runtimeConfig. Si vous incluez runtimeConfig, il est considéré comme une version Canary personnalisée et automatisée.

Configurer une version Canary automatisée personnalisée

Une version Canary automatisée et personnalisée est semblable à une version Canary personnalisée, car vous spécifiez les phases Canary distinctes, avec des noms de phase personnalisés, des valeurs de pourcentage, des profils Skaffold et des tâches de vérification des emplois. Toutefois, avec une version Canary personnalisée, vous ne fournissez pas les configurations qui définissent la répartition du trafic. Cloud Deploy le fait pour vous, mais vous fournissez les profils Skaffold à utiliser pour chaque étape.

Pour configurer une version Canary automatisée personnalisée, incluez un stanza runtimeConfig, comme indiqué ici, et incluez le stanza customCanaryDeployment, comme indiqué ici.

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

Bien que vous puissiez utiliser un déploiement Canary Cloud Deploy pour déployer votre application sur la mise en réseau basée sur les services Kubernetes, une autre solution consiste à utiliser le maillage de services de l'API Gateway de Kubernetes. Cette section décrit la procédure à suivre.

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

  1. Configurez vos ressources API Gateway:

    Notez qu'il s'agit uniquement d'exemples.

  2. Votre fichier manifeste Kubernetes, fourni à Cloud Deploy lors de la création de la version, inclut les éléments suivants:

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

    • Un déploiement

    • Un service

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

    • La configuration de la cible est la même que pour toutes les cibles.

    • La configuration du pipeline de livraison, dans la séquence de progression pour la cible spécifique, inclut un stanza 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"
   canaryDeployment:
     percentages:
     - 50

      Où...

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

      • SERVICE est votre configuration de service, requise par Cloud Deploy pour les déploiements Canary sur GKE et GKE Enterprise.

      • DEPLOYMENT est la configuration de déploiement requise par Cloud Deploy pour les déploiements Canary sur GKE et GKE Enterprise.

      • WAIT_TIME correspond à la durée pendant laquelle Cloud Deploy attend que les modifications apportées à la ressource HTTPRoute se terminent pour éviter l'abandon des requêtes. Par exemple : routeUpdateWaitTime: 60s.

        Si vous exécutez une version Canary à 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 lors du scaling à la baisse de l'instance Canary. Vous pouvez configurer ce paramètre si vous observez ce comportement.

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

Vous pouvez exécuter un déploiement Canary à l'aide d'un déploiement parallèle. Cela signifie que la cible sur laquelle vous effectuez le déploiement progressif peut comprendre deux cibles enfants ou plus. Par exemple, vous pouvez procéder progressivement au déploiement sur les 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 effectuez un déploiement sur des cibles GKE, vous devez disposer 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 livraison doit inclure un stanza strategy.canary dans la définition de l'étape applicable.

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

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

    Les deux types de déploiement (contrôleur et enfant) disposent de phases distinctes pour tous les pourcentages Canary configurés, et d'une phase stable pour la version Canary à 100%.

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

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

  • Vous ne pouvez pas relancer les tâches 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 ignore 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 du contrôleur, mais vous ne pouvez pas annuler les déploiements enfants.

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

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

Lorsqu'un déploiement enfant échoue, le déploiement du contrôleur peut passer à des états différents, en fonction de ce qu'il advient des 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 réussit, le déploiement du contrôleur est défini sur HALTED s'il existe d'autres phases après le déploiement actuel.

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

    HALTED vous permet d'ignore, de relancer les tâches ayant échoué dans le déploiement enfant ayant échoué, 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 de l'échec d'un déploiement enfant, et que vous ignorez la tâche ayant échoué dans le déploiement enfant, celui-ci revient à l'état IN_PROGRESS.

Exécuter la version Canary configurée

Pour exécuter le déploiement Canary, procédez comme suit:

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

    gcloud deploy apply --file=PIPELINE

    Le pipeline de livraison inclut la configuration Canary automatisée 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 ont déjà été enregistrées. Si ce n'est pas le cas, 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 livraison identifié par PIPELINE_NAME contient la configuration Canary automatisée ou personnalisée décrite dans ce document.

  3. Avancez dans la version Canary:

    gcloud CLI 

    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 à laquelle ce déploiement fait partie.

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

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

    Consultez la documentation de référence de Google Cloud SDK pour plus d'informations sur la commande gcloud deploy rollouts advance.

    console Google Cloud

    1. Ouvrez la page des pipelines de diffusion.

    2. Cliquez sur votre pipeline affiché dans la liste des pipelines de livraison.

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

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

      La page d'informations sur ce déploiement s'affiche.

      Détails du déploiement dans la console Google Cloud

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

    4. Cliquez sur Avancer le déploiement.

      Le déploiement est avancé à la phase suivante.

Phases ignorées

Si vous déployez une version Canary et que votre application n'a pas encore été déployée dans cet environnement d'exécution, Cloud Deploy ignore la phase Canary et exécute la phase stable. Consultez la section Ignorer des phases pour la première fois pour en découvrir la raison.

Étapes suivantes