Gérer les déploiements

Un déploiement Cloud Deploy comprend des phases. Une phase est un regroupement logique et ordonné de tâches à effectuer lors d'un déploiement.

Chaque phase comprend des jobs, qui sont les actions à effectuer dans chaque phase (par exemple, deploy ou verify). Chaque job peut avoir zéro ou plusieurs exécutions de job. Une exécution de job est une instance de job. Si le job n'a pas été exécuté, il n'y a pas d'exécutions de job.

Ce document décrit les phases, les tâches et les exécutions de tâches, et explique comment les gérer.

Structure d'un déploiement

Un déploiement est une ressource Cloud Deploy qui associe une version à une cible.

Phases

Un déploiement se compose d'une ou de plusieurs phases.

Pour une stratégie de déploiement standard, il n'y a qu'une seule phase : stable.

Pour une stratégie de déploiement canari, une phase distincte est prévue pour chaque pourcentage configuré. Par exemple, si vous configurez un déploiement Canary qui déploie 25 %, puis 50 %, puis 100 %, il y aura trois phases :

• canary-25
• canary-50
• stable

Les noms de phases suivants sont standards : canary-[PERCENTAGE] pour les phases Canary et stable pour la phase à 100 %. Toutefois, si vous configurez une analyse Canary personnalisée ou personnalisée et automatisée, vous pouvez contrôler les noms des phases.

Tâches et exécutions de tâches

Chaque phase de déploiement inclut un ou plusieurs jobs.

Pour un déploiement avec une stratégie de déploiement standard, sans validation de déploiement activée, il n'y a qu'une seule phase (stable).

Pour un déploiement Canary, il existe une phase pour chaque partie du déploiement Canary (par exemple, canary-25, canary-50, stable) et, pour chaque phase, il existe un job deploy. Si la validation est activée, il existe également un job verify pour chaque phase.

Une exécution de job est une instance de job. Par exemple, une exécution de job pour un job deploy est exécutée. Si elle réussit, aucune autre exécution de job n'est effectuée pour ce job. En cas d'échec, vous pouvez réessayer en tant qu'autre exécution de job.

Ignorer des phases la première fois

Certaines stratégies de déploiement (par exemple, Canary) répartissent le trafic entre les anciennes et les nouvelles versions. Si vous effectuez un déploiement vers une cible pour la première fois, il n'y a pas d'ancienne version. Nous ne pouvons donc pas répartir le trafic.

Pour cette raison, lorsque vous déployez un canary pour la première fois, nous ignorons la ou les phases canary et exécutons la phase stable. L'application est ensuite déployée, et les futurs déploiements Canary incluront les phases Canary.

Dans une situation réelle, vous effectuerez généralement un déploiement Canary lorsque votre application est déjà en cours d'exécution. Il est donc rare que vous sautiez cette phase.

États d'un déploiement

Les déploiements, les phases, les jobs et les exécutions de jobs ont tous des états. Cette section décrit les états de chacun.

États de déploiement

Un déploiement peut avoir l'un des états suivants :

• APPROVAL_REJECTED

  Le déploiement nécessitait une approbation, mais celle-ci a été refusée.

• CANCELLED

  État final des déploiements qui ont été annulés par un utilisateur.

• CANCELLING

  Un utilisateur a annulé le déploiement, mais l'annulation n'a pas encore été traitée.

• HALTED

  Dans un déploiement parallèle, si un ou plusieurs déploiements enfants échouent, mais qu'au moins un réussit, le déploiement du contrôleur est ARRÊTÉ s'il y a d'autres phases après celle en cours.

  Pour reprendre le déploiement d'un contrôleur arrêté, procédez de l'une des manières suivantes :

  • Annuler le déploiement du contrôleur

  • Réessayez ou ignorez les jobs qui ont échoué dans les déploiements enfants.

• IN_PROGRESS

  Une exécution de job est en cours de traitement.

• FAILED

  Un job a échoué et l'utilisateur n'a pas choisi d'ignorer l'échec.

• PENDING

  Le déploiement n'a pas encore commencé. Cet état passe à IN_PROGRESS ou CANCELED.

• PENDING_APPROVAL

  Le déploiement nécessite une approbation, mais n'a pas encore été approuvé.

• PENDING_RELEASE

  Le déploiement est en attente de rendu de la version.

• SUCCEEDED

  Le déploiement est terminé, sans échec.

États des phases

Une phase peut avoir l'un des états suivants :

• PENDING

  La phase attend la fin d'une autre phase du déploiement.

• IN_PROGRESS

  La phase a commencé.

• SUCCEEDED

  La phase s'est terminée avec succès.

• FAILED

  Une tâche de la phase a échoué et l'utilisateur n'a pas choisi d'ignorer l'échec.

• ABORTED

  Une phase précédente a échoué.

• SKIPPED

  Lorsque vous exécutez une stratégie de déploiement, telle qu'un Canary, Cloud Deploy passe à la phase stable dans les cas où il n'existe pas encore de version en cours d'exécution de l'application avec laquelle répartir le trafic. Dans ce cas, l'état est défini sur SKIPPED.

États des jobs

Une tâche peut présenter l'un des états suivants :

• ABORTED

  Si une phase échoue, les phases suivantes sont abandonnées.

  Si un job échoue et que cet échec n'est pas ignoré, les jobs suivants sont abandonnés. Par exemple, si une phase inclut un job de déploiement et un job de validation, et que le job de déploiement échoue, le job de validation est abandonné.

• DISABLED

  Il est possible que certains jobs d'une phase soient désactivés. Par exemple, les phases incluent toujours des tâches de validation, que l'option Validation soit activée ou non. Si la validation n'est pas activée, le job de validation est défini sur DISABLED.

• FAILED

  L'exécution d'un job pour ce job a échoué, et l'utilisateur n'a pas choisi d'ignorer l'échec.

  L'utilisateur a choisi d'arrêter l'exécution du job pour ce job.

• IGNORED

  L'exécution d'un job pour ce job a échoué, et l'utilisateur a choisi d'ignorer l'échec.

• IN_PROGRESS

  Une exécution de job est actuellement en cours pour ce job.

• PENDING

  L'exécution de ce job est en attente, car une autre phase ou un autre job n'est pas terminé.

• SKIPPED

  Lorsque vous exécutez une stratégie de déploiement, telle qu'un Canary, Cloud Deploy passe à la phase stable dans les cas où il n'existe pas encore de version en cours d'exécution de l'application avec laquelle répartir le trafic. Dans ce cas, l'état des jobs des phases ignorées est défini sur SKIPPED.

• SUCCEEDED

  L'exécution du job s'est terminée avec succès, et le job suivant de la phase a commencé, ou la phase suivante a commencé ou est prête à commencer (peut-être en attente d'une saisie de l'utilisateur), ou le déploiement est terminé.

États d'exécution du job

• FAILED

  L'exécution du job a échoué.

• IN_PROGRESS

  L'exécution du job a commencé, mais n'est pas terminée.

• TERMINATED

  L'utilisateur a mis fin à l'exécution du job.

• TERMINATING

  L'utilisateur a mis fin à l'exécution du job, mais celle-ci n'est pas encore terminée.

• SUCCEEDED

  Lorsqu'une exécution de job se termine correctement, sans échec ni arrêt par un utilisateur, elle passe à l'état SUCCEEDED, ce qui

Gérer votre déploiement

À l'aide de la console Google Cloud ou de Google Cloud SDK, vous pouvez effectuer les opérations suivantes avec un déploiement progressif Cloud Deploy :

• Avancer le déploiement

• Annuler le déploiement

• Arrêter l'exécution d'un job

• Ignorer un job

• Relancer un job en échec

Si vous utilisez le déploiement parallèle avec une stratégie de déploiement Canary, consultez Gérer les déploiements Canary parallèles.

Avancer un déploiement

Pour les cibles configurées pour utiliser une stratégie de déploiement autre que "standard", vous devez faire progresser le déploiement de phase en phase.

Par exemple, si vous avez configuré une cible pour effectuer un déploiement Canary simple avec des phases de 50 % et stable (100 %) uniquement, vous devrez faire progresser le déploiement une fois, de la phase canary-50 à la phase stable (100 %).

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

Annuler un déploiement

Vous pouvez annuler tout déploiement qui n'est pas terminé. Vous pouvez également annuler un déploiement ayant échoué pour éviter d'autres actions à ce niveau (comme ignorer ou réessayer). Le déploiement doit être dans l'un des états suivants :

• FAILED
• HALTED
• IN_PROGRESS
• PENDING
• PENDING_APPROVAL
• PENDING_RELEASE

Une fois que vous avez annulé un déploiement, il passe à l'état CANCELLING jusqu'à ce que toutes les exécutions de tâches en attente soient terminées. Vous pouvez mettre fin aux exécutions de jobs en attente que vous ne souhaitez pas attendre. Une fois le déploiement CANCELLED, il ne peut plus être avancé ni modifié.

Pour annuler un déploiement :

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

Arrêter l'exécution d'un job

Vous pouvez mettre fin à une exécution de job en cours. Vous pouvez le faire, par exemple, si une exécution de job semble prendre trop de temps ou ne pas fonctionner comme prévu. Pour pouvoir mettre fin à l'exécution d'un job, celle-ci doit être IN_PROGRESS.

gcloud deploy job-runs terminate JOB_RUN_ID \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --rollout=ROLLOUT_NAME \
                               --region=REGION

Une fois l'exécution d'un job terminée, le job est considéré comme ayant échoué. Vous pouvez alors effectuer l'une des opérations suivantes :

• Laissez-le tel quel et ignorez le déploiement ayant échoué.
• Relancer le job
• Ignorer le job et passer au job ou à la phase suivante du déploiement

Ignorer un job

Vous pouvez ignorer un job ayant échoué et passer immédiatement au job suivant de la phase. Il est possible que ce job ait échoué pour une raison quelconque, y compris si vous ou une autre personne avez arrêté une exécution de job pour ce job.

Un échec de tâche signifie un échec de phase et un échec de déploiement. Toutefois, si vous ignorez l'échec, la phase et le déploiement peuvent progresser et atteindre finalement l'état SUCCEEDED.

gcloud deploy rollouts ignore-job ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --job-id=JOB_ID \
                               --phase-id=PHASE_ID \
                               --region=REGION

Relancer un job en échec

Vous pouvez relancer une exécution de job qui a échoué. La tâche peut échouer pour l'une des raisons suivantes :

• L'exécution d'un job n'a pas pu être menée à bien.

  Par exemple, une erreur d'autorisation peut s'être produite.

• Un utilisateur a arrêté l'exécution d'un job à partir de ce job.

  Si vous mettez fin à l'exécution d'un job, celui-ci échoue. Vous pouvez alors réessayer de l'exécuter.

• Un test de validation a échoué.

  Pour un job de validation, un test de validation a échoué. Même si le job de validation s'est terminé correctement, l'un de vos tests de validation a échoué. Nous le signalons donc dans le job de validation. Dans ce cas, vous devez réessayer le job pour déboguer le test ayant échoué par rapport à votre application.

Pour relancer une tâche ayant échoué :

gcloud deploy rollouts retry-job JOB_NAME \
                       --release=RELEASE_NAME \
                       --delivery-pipeline=PIPELINE_NAME \
                       --rollout=ROLLOUT_NAME \
                       --phase=PHASE_ID \
                       --region=REGION

Étapes suivantes

• Découvrez le fonctionnement des stratégies de déploiement dans Cloud Deploy.

• Pour en savoir plus sur la façon dont les déploiements progressifs, les phases, les jobs et les exécutions de jobs s'intègrent au reste de Cloud Deploy, consultez la documentation sur l'architecture du service Cloud Deploy.