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:
- Google Kubernetes Engine
- Cloud Run (services uniquement, pas jobs.)
- GKE Enterprise
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. Dans Ainsi, vous pouvez vous assurer que la nouvelle version de votre application est fiable avant vous le livrez à tous les utilisateurs.
Si vous effectuez un déploiement sur GKE ou GKE Enterprise, Par exemple, vous pouvez déployer la nouvelle version de votre application le nombre de pods. L'ancienne version continuait de fonctionner, mais avec une plus grande le trafic envoyé 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 fichiers Canary suivants déploiement:
Automatique
Avec un canari automatisé vous configurez Cloud Deploy avec une série 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.
Automatisation personnalisée
Pour une version Canary automatisée, vous pouvez fournir le paramètre suivantes:
- Le nom de la phase
- L'objectif en pourcentage
- Profil Skaffold à utiliser pour la phase
- Inclure ou non une tâche de validation
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 cliquez ici.
Personnalisé
Avec une version Canary personnalisée, vous configurez chaque phase Canary séparément, dont les suivantes:
- Le nom de la phase
- L'objectif en pourcentage
- Profil Skaffold à utiliser pour la phase
- Inclure ou non une tâche de validation
De plus, pour une version Canary entièrement personnalisée, vous fournissez toutes les de l'équilibrage du trafic, comme décrit cliquez 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 une version Canary pour des incréments de 25%, 50 % et 75 %, le déploiement comportera les phases suivantes:
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 dans le cadre d'une campagne Canary automatisée ou personnalisée ?
Pour faciliter le déploiement Canary, Cloud Deploy inclut des fonctionnalités les étapes de traitement lors du rendu de votre fichier manifeste Kubernetes Configuration du service Cloud Run:
GKE/Enterprise
Voici comment Cloud Deploy exécute un déploiement Canary dans GKE et GKE Enterprise basés sur le réseau:
Vous indiquez le nom de la ressource Déploiement et la ressource Service.
Cloud Deploy crée une ressource de déploiement supplémentaire, avec le nom de votre déploiement actuel, suivi de
-canary
.Cloud Deploy modifie le service pour ajuster le sélecteur sur sélectionnez 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 si vous activez ou désactivez le surprovisionnement des pods.
Si nous passons à la phase
stable
Cloud Deploy ajoute les étiquettes à utiliser pour faire correspondre les pods. ils sont disponibles pour les exécutions Canary ultérieures.Cloud Deploy crée un déploiement qui inclut pourcentage de pods par phase, en le mettant à jour pour chaque phase. C'est en calculant le nombre de pods sous la forme d'un pourcentage le nombre de pods. Cela peut entraîner une répartition du trafic inexacte. Si vous avez besoin 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
.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 les pods pour obtenir la version Canary demandée le pourcentage le plus proche possible. Cette métrique est basée sur le nombre de pods, le trafic vers les pods. Si vous voulez que votre version Canary soit basée sur le trafic, vous devez utiliser l'API Gateway.
Avec la version Canary GKE basée sur le réseau, vous pouvez activer ou désactiver le surprovisionnement des pods. Les sections suivantes décrivent comment Cloud Deploy calcule la valeur Nombre de pods à provisionner pour le déploiement Canary pour chaque phase Canary.
Provisionnement de pods avec surprovisionnement activé
Activer le 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
déploiement existant. La formule suivante montre comment
Cloud Deploy calcule le nombre de pods à provisionner pour
déploiement Canary pour chaque phase Canary, lorsque le surprovisionnement des pods
activé:
math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))
Avec cette formule, le nombre actuel d'instances répliquées (nombre de pods que vous avez déjà avant cette version) est multipliée par le pourcentage de la version Canary pour phase, et le résultat est divisé par (100 moins le pourcentage).
Par exemple, si vous disposez déjà de quatre pods et que la phase Canary est à 50%, alors
le nombre de pods Canary est de 4. (Le résultat de 100-percentage
est utilisé comme
pourcentage: 100-50=50
, traité comme .50
.)
Le surprovisionnement des pods est le comportement par défaut.
Provisionnement de 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 nombre de pods pour le déploiement Canary pour chaque phase Canary, lorsque le pod le surprovisionnement est désactivé:
math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)
Dans cette formule, ReplicaCountOfCanaryDeploymentOnCluster
n'existe que si
il y avait déjà une phase Canary. 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
et 2 pods sont créés pour le déploiement Canary. Si
une phase Canary de 75 %, avec 2
(déploiement d'origine) +2
(première phase Canary), *.75
, afin d'obtenir 3
pods Canary et 1
pod 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:
En plus des références Déploiement et Service, vous fournissez Ressource HTTPRoute, avec une règle
backendRefs
qui référence le service.Cloud Deploy crée un déploiement, avec le nom de votre déploiement d'origine plus
-canary
, et un nouveau service avec le déploiement d'origine Nom du service suivi de-canary
.Les secrets, les ConfigMaps et les autoscalers horizontaux de pods sont également copiés. et renommée
-canary
.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.Pendant la phase
stable
, le déploiement-canary
est réduit à et le déploiement d'origine est mis à jour pour utiliser Déploiement.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 Canary sur Cloud Run, ne fournissez pas de Stanza
traffic
dans le fichier YAML de votre service.Lors de la création d'un déploiement Canary, Cloud Deploy se divise entre la révision précédente qui a été déployée avec succès Cloud Deploy et une nouvelle révision.
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 en 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 livraison et vos cibles pour un déploiement Canary.
Les instructions ci-après concernent uniquement les aspects spécifiques à la configuration Canary. La 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 : 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 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 skaffold.yaml
que vous créez pour un déploiement Canary n'a pas de code
autres que ce qui est nécessaire
le déploiement.
Préparer votre fichier manifeste ou la définition de votre service
Comme pour un déploiement standard, votre version Canary a besoin d'un fichier manifeste Kubernetes Définition du 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
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 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 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, défini dans votre fichier manifeste.
PERCENTAGES est une liste de pourcentages séparés par une virgule valeurs représentant vos incréments Canary, 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 lastable
Vous pouvez activer la validation du déploiement (
verify: true
). Dans ce cas, un jobverify
est activé à 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 pourcentages séparés par une virgule
valeurs représentant vos incréments Canary, par exemple
[25, 50, 75]
. Remarque que100
n'est pas inclus, car un déploiement à 100% est assumé dans la version Canary et est géré par lastable
- Vous pouvez activer la validation du déploiement
(
verify: true
). Dans ce cas, une tâcheverify
est ajoutée à chaque la phase Canary.
Configurer une version Canary personnalisée
Vous pouvez configurer votre version Canary manuellement au lieu de vous reposer entièrement sur fournie par Cloud Deploy. Avec version 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 les phases à votre place (
canary-25
,canary-75
,stable
, par exemple). Avec une version Canary personnalisée, Cependant, vous pouvez donner n'importe quel nom à chaque phase, à condition qu'elle soit unique parmi toutes pour cette phase Canary, et il honore restrictions liées aux noms de ressources. Mais le dernier Le nom de la phase (100%) doit êtrestable
.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 une combinaison des deux. Chaque profil peut utiliser un fichier manifeste Kubernetes différent ou la définition de service Cloud Run. Vous pouvez également utiliser plus de un profil 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 configurer 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 code YAML suivant montre la configuration des phases de création de versions Canary entièrement personnalisées déploiement:
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
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 code différent pour chaque phase, ou une combinaison quelconque. 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'ensemble à l'étape précédente.
PERCENTAGE1
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.
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 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 fichier Canary personnalisé n'inclut pas
runtimeConfig
stanza. Si vous incluez runtimeConfig
, il est considéré comme un
Canary automatique sur mesure.
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, les valeurs de pourcentage, les profils Skaffold et la vérification des tâches. Mais avec une version Canary personnalisée, vous ne fournissez pas les configurations 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 une version Canary automatisée personnalisée, incluez un strophe runtimeConfig
, tel que
cliquez ici,
et incluez le strophe customCanaryDeployment
, comme indiqué
cliquez 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 décrit la procédure à suivre.
Vous pouvez utiliser l'API Gateway avec Istio ou toute autre implémentation compatible.
Configurez vos ressources API Gateway:
Notez qu'il s'agit uniquement d'exemples.
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 GatewayUn déploiement
Un service
Configurer votre pipeline de livraison et la cible que vous allez déployer en version Canary par:
La configuration de la cible est identique à celle de toutes les cibles.
La configuration du pipeline de livraison, dans l'ordre de progression de la une cible spécifique, inclut un strophe
gatewayServiceMesh
pour référencer votre ConfigurationHTTPRoute
de l'API Kubernetes Gateway, ainsi que votre déploiement et de service.strategy: canary: runtimeConfig: kubernetes: gatewayServiceMesh: httpRoute: "ROUTE" service: "SERVICE" deployment: "DEPLOYMENT" routeUpdateWaitTime: "WAIT_TIME" canaryDeployment: percentages: - 50
Où...
ROUTE est votre configuration httpRoute qui définit le routage le comportement souhaité.
SERVICE est votre configuration de service, qui Cloud Deploy est nécessaire pour les déploiements Canary GKE et GKE Enterprise.
DEPLOYMENT est votre configuration de déploiement, qui Cloud Deploy est nécessaire pour les déploiements Canary 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 Canary à l'aide de l'API Gateway sans Istio et que la passerelle est connectée à un équilibreur de charge Google Cloud, le trafic peut être perdu lors du scaling à la baisse de l'instance Canary. Vous pouvez configurer ce paramètre si vous observez ce comportement.
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 sur laquelle vous déployez progressivement peut comprendre au moins deux cibles enfants. Par exemple, vous pouvez les déployer progressivement sur des clusters plusieurs régions en même temps.
Quelle est la différence entre un test Canary parallèle et une version Canary à cible unique ?
Comme pour le déploiement Canary à cible unique, les cibles GKE, vous avez besoin d'une configuration de déploiement Kubernetes 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) ont des phases distinctes pour tous les pourcentages Canary configurés et une phase
stable
pour le paramètre Canary 100%.Vous ne pouvez pas avancer un déploiement enfant.
Vous ne pouvez avancer que les déploiements de contrôleurs. Lorsque vous faites avancer le contrôleur déployer à l'étape suivante, les déploiements enfants sont également avancés, en Cloud Deploy.
Vous ne pouvez pas réessayer en échec dans le déploiement du contrôleur.
Vous ne pouvez relancer une tâche que dans les déploiements enfants.
Vous ne pouvez pas ignorer en échec dans le 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 pouvez terminer les exécutions de jobs dans le cadre d'un déploiement enfant uniquement, et non d'un déploiement de contrôleur.
Que faire si un déploiement parallèle échoue en version 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 resteIN_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 estFAILED
.HALTED
vous donne la possibilité d'effectuer l'une des actions suivantes : 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'étatIN_PROGRESS
.
Exécuter la version Canary configurée
Pour exécuter le déploiement Canary:
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 choisi.
Cette commande suppose que vos cibles sont définies dans le même fichier dans le cas contraire. Si ce n'est pas le cas, veillez à enregistrer vos cibles. .
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.Avancez dans 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
est le nom de la version qui ce déploiement fait partie.PIPELINE_NAME
est le nom de la livraison. que vous utilisez pour gérer le déploiement de cette version.REGION
est le nom de la région dans laquelle version a été créée, par exempleus-central1
. Ce champ est obligatoire.Consultez la documentation de référence de Google Cloud SDK pour en savoir plus sur Commande
gcloud deploy rollouts advance
console Google Cloud
Cliquez sur le pipeline affiché dans la liste des pipelines de livraison.
La page "Détails du pipeline de livraison" affiche une représentation graphique des éléments suivants : la progression de votre pipeline de livraison.
Dans l'onglet Déploiements, sous Détails du pipeline de livraison, cliquez sur le nom de votre déploiement.
La page d'informations de ce déploiement s'affiche.
Notez que dans cet exemple, le déploiement comporte une phase
canary-50
et unstable
. Votre déploiement peut comporter plusieurs phases ou des .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 la section Ignorer des phases la première fois. pour savoir pourquoi cela se produit.
Étape suivante
Consultez le guide de démarrage rapide du déploiement Canary.
Découvrez comment gérer le cycle de vie des déploiements Canary.
Obtenez plus d'informations sur le déploiement en parallèle.