Utiliser des règles d'automatisation

Ce document décrit les règles d'automatisation, qui sont des actions pouvant être effectuées automatiquement sur votre pipeline de diffusion. Par exemple, vous pouvez configurer votre pipeline de diffusion afin que la promotion dans une cible spécifique se produise automatiquement, dans les bonnes conditions.

Vous ne pouvez utiliser que les règles d'automatisation intégrées à Cloud Deploy. Les règles d'automatisation disponibles sont listées dans ce document.

Règles d'automatisation disponibles

Les règles d'automatisation suivantes sont disponibles dans Cloud Deploy:

Configurer des règles d'automatisation

La configuration de chaque règle d'automatisation dépend de la règle spécifique. Cette section décrit la configuration commune à toutes les règles, ainsi que la configuration de chacune des règles disponibles.

Chaque règle d'automatisation est configurée dans le cadre de la configuration de la ressource d'automatisation. Cela peut se trouver dans le même fichier que la configuration du pipeline de diffusion approprié (généralement appelé clouddeploy.yaml) ou dans n'importe quel fichier de votre choix. Découvrez comment configurer des automatisations.

Les sections suivantes décrivent la configuration spécifique à chaque règle d'automatisation. Pour configurer l'automatisation elle-même, consultez Automatiser votre déploiement.

Configurer une règle d'automatisation promoteReleaseRule

La règle promoteReleaseRule promeut votre version après un déploiement réussi dans une cible. Par exemple, si vous avez trois cibles, vous pouvez configurer cette règle afin que, lorsque la version est déployée avec succès dans la première cible, elle soit automatiquement promue vers la deuxième cible.

Lorsque vous configurez une automatisation promoteReleaseRule, vous pouvez spécifier une cible à promouvoir (destinationTargetId) ou @next. Lorsque le déploiement se termine avec succès dans la cible spécifiée dans la définition Automation, la version est ensuite promue vers la cible spécifiée dans destinationTargetId, sous réserve d'un intervalle de temps wait.

Vous pouvez également promouvoir une version vers une phase spécifique de la cible souhaitée à l'aide de la propriété destinationPhase. La strophe rules illustrée ici se trouve dans votre définition d'automatisation.

rules:
- promoteReleaseRule:
    name: "[RULE_NAME]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Où :

• [RULE_NAME]

  Nom que vous souhaitez attribuer à cette règle. Ce nom doit être unique dans la ressource d'automatisation.

• [WAIT_TIME]

  Indique le délai, en minutes, à attendre après la publication de la version avant qu'elle ne soit promue. Par exemple, 1m. m est obligatoire.

  La valeur par défaut est 0, ce qui signifie qu'il n'y a pas de temps d'attente. La valeur maximale est 20160m (ou 14 jours).

• [TO_TARGET]

  Il s'agit de l'targetId de la cible à promouvoir.

  Il peut également s'agir de @next, qui promeut automatiquement la version sur la cible suivante après la cible spécifiée dans la propriété selector.targets dans cette configuration d'automatisation. Il s'agit de la valeur par défaut si vous omettez la valeur de destinationTargetId.

• [TO_PHASE]

  Indique le nom de la phase à laquelle vous souhaitez promouvoir la phase, par exemple canary-25 ou stable. Cette propriété est facultative. Si vous l'omettez, la version est promue à la première phase de la cible.

Configurer une règle d'automatisation timedPromoteReleaseRule

La règle timedPromoteReleaseRule vous permet de planifier le moment où une version doit être promue de la ou des cibles sélectionnées vers la cible suivante dans la progression ou vers une cible spécifiée. Lorsque vous configurez une automatisation timedPromoteReleaseRule, vous spécifiez quand promouvoir la version, en fonction d'une planification cron.

rules:
- timedPromoteReleaseRule:
    name: "[RULE_NAME]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Où :

• [RULE_NAME]

  Nom que vous souhaitez attribuer à cette règle. Ce nom doit être unique dans le pipeline de diffusion.

• [CRON]

  Il s'agit de la planification cron qui spécifie quand promouvoir la version. Utilisez cette programmation pour spécifier la date et l'heure auxquelles vous souhaitez promouvoir la version.

  Cette planification utilise la syntaxe cron standard:

  * * * * *

  Dans ce calendrier :

  • La première position correspond aux minutes (0-59).
  • La deuxième position correspond à l'heure (0-23).
  • La troisième position correspond au jour du mois (1-31).
  • La quatrième position correspond au mois (1-12).
  • La cinquième position correspond au jour de la semaine (0-6, du dimanche au samedi)

  Par exemple, si votre règle de promotion programmée inclut le calendrier suivant : 0 9 * * 1, votre publication est promue tous les lundis à 9h.

  Vous pouvez également utiliser les fonctionnalités de planification cron standards, comme les suivantes:

  • Une plage (0-5)
  • Une liste (1,3,5)
  • Une fonction par étapes (par exemple, */3 dans le champ "heures" s'active toutes les trois heures)

• [TIME_ZONE]

  Fuseau horaire que vous souhaitez utiliser pour planifier la promotion, au format IANA.

• [TO_TARGET]

  Il s'agit de l'targetId de la cible à promouvoir ou de @next pour promouvoir automatiquement la version vers la cible suivante après la cible spécifiée dans selector.targets property dans cette configuration d'automatisation. Cette opération est facultative. La valeur par défaut est @next.

• [TO_PHASE]

  Nom de la phase à laquelle vous souhaitez promouvoir la phase, par exemple canary-25 ou stable. Cette propriété est facultative. Si vous l'omettez, la version est promue à la première phase de la cible.

Configurer une règle d'automatisation advanceRolloutRule

Une fois qu'une phase est terminée, advanceRolloutRule passe automatiquement à la phase suivante. Cette règle d'automatisation est utile pour les déploiements Canary. Par exemple, si vous avez configuré une stratégie de déploiement Canary sur une cible, avec des phases 25%, 50% et stable, vous pouvez configurer une règle d'automatisation qui fait passer automatiquement la phase à stable une fois la phase 50% terminée.

Lorsque vous configurez une automatisation advanceRolloutRule, vous identifiez la phase à dépasser (sourcePhase). La strophe rules illustrée ici se trouve dans votre définition d'automatisation.

rules:
- advanceRolloutRule:
    name: "[RULE_NAME]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Où :

• [RULE_NAME]

  Nom que vous souhaitez attribuer à cette règle. Ce nom doit être unique dans le pipeline de diffusion.

• [WAIT_TIME]

  Indique le temps d'attente (en minutes) avant de procéder au déploiement une fois qu'il est prêt. Par exemple, 1m. m est obligatoire.

  La valeur par défaut est 0, ce qui signifie qu'il n'y a pas de temps d'attente. La valeur maximale est 20160m (ou 14 jours).

• ["[START_PHASE]", "[START_PHASE]"...]

  Indique la ou les phases à partir desquelles le déploiement est automatiquement avancé. Autrement dit, lorsque l'une des phases listées se termine correctement, le déploiement passe automatiquement de cette phase à la suivante.

  Les noms de phases sont sensibles à la casse. De plus, ces noms de phases sont facultatifs. Si vous omettez sourcePhases, toutes les phases du déploiement sont automatiquement avancées.

Configurer une règle d'automatisation repairRolloutRule

La règle repairRolloutRule relance un déploiement ayant échoué un nombre de fois spécifié. Si ce nombre de tentatives est épuisé, cette règle peut alors annuler automatiquement la cible à la dernière version réussie.

Lorsque vous configurez une automatisation repairRolloutRule, vous pouvez spécifier le nombre de nouvelles tentatives de déploiement et le délai d'attente entre les tentatives. Vous pouvez également configurer des phases ou des tâches spécifiques, ou les deux, pour qu'elles soient réessayées. Si chaque tentative de nouvelle tentative échoue, le déploiement échoue. Si une nouvelle tentative aboutit, l'automatisation s'arrête et le déploiement réussit.

Vous pouvez éventuellement configurer l'automatisation pour qu'elle revienne à la dernière version réussie sur la cible. Les nouvelles tentatives sont également facultatives, mais vous devez définir un nombre de nouvelles tentatives ou un rollback, ou les deux.

La strophe rules illustrée ici se trouve dans votre définition d'automatisation.

rules:
- repairRolloutRule:
    name: "[RULE_NAME]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]

Où :

• [RULE_NAME]

  Nom que vous souhaitez attribuer à cette règle. Ce nom doit être unique dans le pipeline de diffusion.

• [PHASES_TO_REPAIR]

  Phase ou phases de déploiement à réessayer. Ce paramètre est facultatif et la valeur par défaut est "Toutes les phases du déploiement".

• [JOBS_TO_REPAIR]

  Indique la ou les tâches à relancer. Cette option est facultative. Par défaut, toutes les tâches sont sélectionnées.

• [NUMBER_OF_ATTEMPTS]

  Facultatif : nombre de tentatives d'exécution du déploiement avant de considérer qu'il a échoué.

• [WAIT_TIME]

  Indique la durée d'attente entre les nouvelles tentatives. Par exemple, 1m pour un intervalle d'une minute. L'unité de temps (m dans ce cas) est obligatoire.

  Si mode est linear, cet intervalle est le même pour chaque nouvelle tentative. Si mode est exponential, l'intervalle augmente à chaque fois. (Pour en savoir plus, consultez mode.)

• backoffMode

  LINEAR ou EXPONENTIAL, indiquant si le délai entre les arrêts doit être augmenté ou non. Si LINEAR, l'intervalle entre les nouvelles tentatives est constant, à WAIT_TIME. Si EXPONENTIAL, le délai entre les nouvelles tentatives est doublé à chaque tentative. La valeur par défaut est LINEAR.

  Par exemple, si WAIT_TIME est 1m et que backoffMode est défini sur EXPONENTIAL, le temps entre l'échec et la première tentative est de 1 minute, le temps entre la première et la deuxième tentative est de 2 minutes, et le temps entre la deuxième et la troisième tentative est de 4 minutes.

• rollback

  Facultatif : indique si le déploiement ayant échoué doit être annulé une fois toutes les tentatives de nouvelle tentative épuisées.

• [PHASE_NAME]

  Nom d'une phase spécifique à laquelle vous souhaitez revenir. Si vous omettez toPhase, la phase de rollback est définie par défaut sur stable.

Arrêter l'exécution d'une automatisation repairRolloutRule

Si vous exécutez l'une des commandes suivantes lors de votre déploiement, l'automatisation repairRolloutRule est interrompue:

• Nouvelle tentative d'exécution du job
• Annuler le déploiement
• Ignorer la tâche
• Arrêter l'exécution du job

Exemple

Voici un exemple de configuration d'automatisation avec un repairRolloutRule:

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    name: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

Dans cette automatisation, si un déploiement échoue sur la cible identifiée, il est relancé jusqu'à trois fois, avec un temps d'attente d'une minute entre chaque tentative. Si toutes les tentatives de nouvelle tentative échouent, un rollback est lancé en créant un nouveau déploiement pour déployer la version réussie la plus récente de la cible sur cette cible.

Étape suivante

• Consultez le guide de démarrage rapide: Automatiser la création de versions et l'avancement du déploiement.

• En savoir plus sur l'automatisation du déploiement dans Cloud Deploy