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 se divise entre une version déjà déployée et une nouvelle version, le déploiement à un sous-ensemble d'utilisateurs avant le déploiement complet.

Types de cibles acceptés

Le déploiement Canary dans Cloud Deploy est compatible avec tous les types de cibles, dont les suivantes:

Canary fonctionne également avec 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 déployez sur Cloud Run, Cloud Run répartit le trafic entre l'ancienne et la nouvelle révision, en fonction que vous configurez.

Types de versions Canary

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 afin de répartir le trafic entre l'ancienne et la nouvelle version.

  • Automatisé sur mesure

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

    • Le nom de la phase
    • L'objectif en pourcentage
    • Profil Skaffold à utiliser pour la phase
    • Inclure ou non une tâche de validation
    • 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 le les ressources nécessaires.

  • Personnalisé

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

    • Nom de la phase
    • L'objectif en pourcentage
    • Profil Skaffold à utiliser pour la phase
    • Inclure ou non une tâche de validation
    • Inclure ou non une tâche de prédéploiement ou de post-dé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 jobs et les exécutions de jobs, consultez Gérer les déploiements

Que se passe-t-il lors d'un canari automatisé 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 :

GKE/Enterprise

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

  1. Vous devez fournir 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 le Canary sur la base du calcul décrit cliquez ici. Ce calcul diffère selon que vous activez ou désactivez le surprovisionnement de pods.

    Si nous passons directement à la phase stable, Cloud Deploy ajoute les étiquettes à utiliser pour faire correspondre les pods afin qu'elles soient disponibles pour les prochaines exécutions Canary.

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

    De plus, les Secrets et les ConfigMaps sont également copiés et renommés -canary.

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

    Cloud Deploy ne modifie pas le déploiement d'origine tant que stable.

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

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

Provisionnement de 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 de canari 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 canari pour chaque phase de canari, lorsque le surprovisionnement de pods est activé :

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

Avec cette formule, le nombre actuel de réplications (le nombre de pods que vous possédez déjà, avant ce canari) est multiplié par le pourcentage de canari pour la phase, et le résultat est divisé par (100 moins le pourcentage).

Par exemple, si vous avez déjà quatre pods et que votre phase de canari est de 50 %, le nombre de pods de canari est de quatre. (Le résultat de 100-percentage est utilisé comme pourcentage: 100-50=50, traité comme .50.)

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

Provisionnement de pods avec le surprovisionnement désactivé

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

La formule suivante montre comment Cloud Deploy calcule le provisionnement de pod pour le déploiement de canari pour chaque phase de canari, lorsque le surprovisionnement de pod est désactivé :

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

Dans cette formule, ReplicaCountOfCanaryDeploymentOnCluster n'existe que s'il y avait déjà une phase canari. S'il s'agit de la première phase Canary, n'est pas 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, et deux nouveaux pods sont créés pour le déploiement Canary. Si vous avez ensuite une phase de canari à 75 %, vous avez 2 (déploiement d'origine) +2 (première phase de canari), *.75, pour obtenir des pods de canari 3 et un pod 1 exécutant le déploiement d'origine.

Passerelle GKE/Enterprise

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 de déploiement et de service, vous fournissez une ressource HTTPRoute, avec une règle backendRefs qui fait référence au service.

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

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

  3. Pour chaque phase Canary, Cloud Deploy modifie la route HTTP pour mettre à jour la pondération entre les pods du déploiement d'origine et les pods du déploiement Canary, en fonction du pourcentage utilisé pour cette phase.

    Parce qu'il peut y avoir un délai lors de la propagation des modifications à HTTPRoute. ressources, vous pouvez inclure la propriété routeUpdateWaitTime dans votre configuration. Le système attend donc un certain temps la propagation.

  4. Au cours de 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, l'instance HTTPRoute d'origine est maintenant rétablie.

    Cloud Deploy ne modifie pas le déploiement d'origine Service jusqu'à la phase stable.

Cloud Run

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

  • Pour un déploiement canari sur Cloud Run, n'indiquez pas de strophe traffic dans le fichier YAML de votre service.

  • Lorsque vous créez un déploiement pour un canari, Cloud Deploy répartit le trafic entre la version précédente qui a été déployée avec succès par Cloud Deploy et une nouvelle version.

Pour voir les différences entre les phases d'un déploiement Canary, pouvez voir les modifications apportées au fichier manifeste rendu par phase disponible dans outil d'inspection des versions. Vous pouvez le faire avant même que le déploiement a commencé. De plus, si vous utilisez déploiement parallèle, vous pouvez aussi inspecter l'infrastructure le fichier manifeste affiché.

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 Identity and Access Management dont vous avez besoin pour utiliser Cloud Deploy, vous devez disposer des autorisations suivantes pour : d'effectuer des actions supplémentaires qui peuvent être nécessaires dans le cadre d'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 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.

GKE et GKE Enterprise

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

  • Un déploiement et un service.

  • Le service doit définir un sélecteur, et ce sélecteur doit sélectionner les pods du déploiement spécifié. La valeur par défaut est app.

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

Cloud Run

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

Configurer une version Canary automatisée

Les instructions suivantes concernent Cloud Run et Mise en réseau basée sur les services GKE et GKE Enterprise cibles. 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 :

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"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

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.

  • LABEL est une étiquette de sélecteur de pod. Il doit correspondre au libellé dans le service Kubernetes défini dans votre fichier manifeste. Cette opération est facultative. La valeur par défaut est app.

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

    Cela n'inclut pas 100, car un déploiement à 100% est assum dans la version Canary et est géré par la stable

  • Vous pouvez activer la validation du déploiement (verify: true). Si vous le faites, une tâche verify est activée à chaque phase.

  • PREDEPLOY_ACTION

    Il est identique à 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

    Correspond à l'ACTION_NAME 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.

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
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

Dans cette configuration :

  • PERCENTAGES est une liste de pourcentages séparés par une virgule valeurs 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 le canari et est géré par la phase stable.

  • Vous pouvez activer la validation du déploiement (verify: true). Si vous le faites, une tâche verify est ajoutée à chaque phase de canari.

  • PREDEPLOY_ACTION

    Il est identique à 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

    Correspond à l'ACTION_NAME 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.

Configurer une version Canary personnalisée

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. Mais le dernier Le nom 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, ou le même profil, ou toute combinaison. Chaque profil peut utiliser un fichier manifeste Kubernetes différent ou la définition de service Cloud Run. Vous pouvez également utiliser plusieurs profils pour une phase donnée. Cloud Deploy les combine.

  • Indique s'il existe une tâche de vérification pour 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 les versions Canary personnalisées.

É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 toutes les spécifiés, plus le profil ou le fichier manifeste utilisé par à l'étape précédente.

  • 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 disposer d'un valeur de pourcentage. Cette valeur doit être un pourcentage entier (et non 10.5, pour exemple), et les phases doivent être classées dans l'ordre croissant.

  • verify: true|false

    Indique à Cloud Deploy si une tâche de validation doit être incluse pour la phase. Notez que pour chaque phase à utiliser la validation, Skaffold utilise le même profil pour pour le rendu et le déploiement pour cette phase.

  • PREDEPLOY_ACTION

    Identique au ACTION_NAME que vous avez utilisé dans votre skaffold.yaml pour définir l'action personnalisée à 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 pour la dernière phase doit être 100. Les phases sont exécutées en fonction dans l'ordre dans lequel vous les configurez dans cette section ​customCanaryDeployment, mais si les valeurs de pourcentage ne sont pas dans l'ordre croissant, la commande enregistrer le pipeline de livraison échoue et génère 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 personnalisé et automatisé.

Configurer une version Canary automatisée personnalisée

Une version Canary automatisée personnalisée est semblable à une version Canary personnalisée car vous spécifiez les phases Canary distinctes, avec des noms de phase personnalisés, valeurs de pourcentage, profils Skaffold, vérifier les jobs, et prédéploiement et post-déploiement emplois. Avec un modèle Canary personnalisé, vous ne fournissez pas qui définissent la répartition du trafic : c'est Cloud Deploy qui s'en charge. pour vous, mais vous fournissez tout de même Profils Skaffold à utiliser pour chaque étape.

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

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

Même si vous pouvez utiliser un déploiement Canary Cloud Deploy 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 explique comment procéder.

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

  1. Configurez vos ressources de l'API Gateway :

    Ce ne sont que des exemples.

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

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

    • 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 est la durée nécessaire à Cloud Deploy pour d'attendre la fin de la propagation des modifications apportées à la ressource HTTPRoute, pour éviter l'abandon des requêtes. 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 une étiquette 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 le 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 en parallèle. Cela signifie que la cible à laquelle vous déployez progressivement peut comprendre deux ou plusieurs cibles enfants. Par exemple, vous pouvez les déployer progressivement sur des clusters plusieurs régions en même temps.

Différences entre les canaris parallèles et les 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 livraison Vous devez inclure un bloc strategy.canary dans la définition de l'espace de création pour étape applicable.

  • De plus, vous devez configurer un ciblage multicible, et vous devez configurer les cibles enfants auquel cette stratégie multicible 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) 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 pouvez uniquement faire avancer 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 le déploiement d'un contrôleur. mais vous ne pouvez pas annuler 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 ?

En cas d'échec d'un déploiement enfant, le déploiement du contrôleur peut passer à un autre 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 réussit, le déploiement du contrôleur est défini sur HALTED s'il y a plusieurs phases après la 1.

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

    HALTED vous permet de : ignorer, réessayer les jobs ayant échoué dans le déploiement enfant ayant échoué ; annuler le déploiement du contrôleur et 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 enfant ayant échoué et que vous ignorez la tâche ayant échoué dans le déploiement enfant, le contrôleur le déploiement revient à l'état IN_PROGRESS.

Exécuter la version Canary configurée

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 livraison inclut la configuration Canary automatisée ou personnalisée, pour l'environnement d'exécution choisi.

    Cette commande suppose que vos cibles sont définies dans le même fichier soit déjà enregistré. Si ce n'est pas le cas, veillez à 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 document.

  3. Faites progresser la version Canary:

    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 actuel. que vous faites passer à la phase suivante.

    RELEASE_NAME correspond au nom de la version de ce déploiement.

    PIPELINE_NAME est le nom de la livraison. 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 du SDK Google Cloud.

    console Google Cloud

    1. Ouvrez la page des pipelines de diffusion.

    2. Cliquez sur le pipeline qui s'affiche dans la liste des pipelines de livraison.

      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 d'informations de 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 un stable. Votre déploiement peut comporter plusieurs phases ou des .

    4. Cliquez sur Avancer le déploiement.

      Le déploiement passe à la phase suivante.

Phases ignorées

Si vous déployez une version Canary et que votre application n'y est pas déployée l'environnement d'exécution, Cloud Deploy exécute la version stable à chaque phase. Consultez Ignorer des phases la première fois pour savoir pourquoi cela se produit.

Étape suivante