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 pour que la promotion vers une cible spécifique se produise automatiquement, dans les bonnes circonstances.

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 :

Règle Description
timedPromoteReleaseRule Promouvoir automatiquement une version d'une cible à l'autre

en fonction d'une programmation cron.
promoteReleaseRule Promouvoir automatiquement une version vers la cible indiquée en cas de déploiement réussi

déploiement sur la cible précédente de la progression.
advanceRolloutRule Fait automatiquement passer un déploiement de la phase indiquée à la suivante.

phase à la phase suivante.
repairRolloutRule Relancer automatiquement le ou les jobs ayant échoué dans le déploiement

le nombre de fois spécifié et effectue un rollback si toutes les tentatives échouent.

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 façon de configurer chacune des règles disponibles.

Chaque règle d'automatisation est configurée dans la configuration de la ressource d'automatisation. Cela peut se trouver dans le même fichier que la configuration du pipeline de diffusion concerné (généralement appelé clouddeploy.yaml) ou dans n'importe quel fichier de votre choix. Découvrez comment configurer les 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 timedPromoteReleaseRule

La règle timedPromoteReleaseRule vous permet de programmer la promotion d'une version depuis la ou les 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]

    est le nom que vous souhaitez donner à cette règle. Ce nom doit être unique dans le pipeline de livraison.

  • [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 sortie.

    Cette programmation utilise la syntaxe cron standard :

    * * * * *

    Dans ce calendrier…

    • La première position correspond à la minute (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 la planification suivante :0 9 * * 1, votre sortie est promue tous les lundis à 9h.

    Vous pouvez également utiliser les fonctionnalités standards de planification Cron, telles que :

    • Une plage (0-5)
    • Une liste (1,3,5)
    • Une fonction par paliers (par exemple, */3 dans le champ "heures" active la tâche 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 vers laquelle promouvoir la version, ou de @next pour promouvoir automatiquement la version vers la cible suivante après celle spécifiée dans selector.targets property dans cette configuration d'automatisation. Ce champ est facultatif. La valeur par défaut est @next.

  • [TO_PHASE]

    Nom de la phase phase vers laquelle vous souhaitez promouvoir la version, 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 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 de sorte que, lorsque la version est déployée avec succès dans la première cible, elle soit automatiquement promue dans 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 correctement 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 prévue à l'aide de la propriété destinationPhase. La strophe rules présentée ici doit être placée dans votre définition d'automatisation.

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

Où :

  • [RULE_NAME]

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

  • [WAIT_TIME]

    Il s'agit du temps d'attente, en minutes, après que la sortie est prête à être promue avant qu'elle ne le soit. 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 de 20160m (ou 14 jours).

  • [TO_TARGET]

    targetId de la cible à promouvoir.

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

  • [TO_PHASE]

    Nom de la phase vers laquelle vous souhaitez promouvoir la phase actuelle, 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

advanceRolloutRule fait passer automatiquement votre déploiement à la phase suivante une fois la phase en cours terminée. 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 de 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 à partir de laquelle avancer (le sourcePhase). La strophe rules présenté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]

    est le nom que vous souhaitez donner à cette règle. Ce nom doit être unique dans le pipeline de déploiement.

  • [WAIT_TIME]

    Il s'agit du temps d'attente, en minutes, avant de faire progresser le 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 de 20160m (ou 14 jours).

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

    Il s'agit de la ou des phases à partir desquelles le déploiement est automatiquement avancé. Autrement dit, lorsqu'une des phases listées se termine correctement, le déploiement passe automatiquement à la phase 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 rétablir automatiquement la cible sur 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 temps d'attente entre les tentatives. Vous pouvez également configurer des phases ou des jobs spécifiques, ou les deux, pour qu'ils soient relancés. Si chaque 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 revenir à la dernière version réussie sur la cible. Les nouvelles tentatives sont également facultatives, mais vous devez prévoir un certain nombre de nouvelles tentatives ou une restauration, ou les deux.

La strophe rules présentée ici doit être placée 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]

    est le nom que vous souhaitez donner à cette règle. Ce nom doit être unique dans le pipeline de déploiement.

  • [PHASES_TO_REPAIR]

    Phase ou phases de déploiement à réessayer. Ce champ est facultatif. Par défaut, toutes les phases du déploiement sont incluses.

  • [JOBS_TO_REPAIR]

    Il s'agit de la ou des tâches à réessayer. Cette option est facultative. Par défaut, tous les jobs sont inclus.

  • [NUMBER_OF_ATTEMPTS]

    Facultatif : nombre de tentatives de déploiement avant de le considérer comme ayant échoué.

  • [WAIT_TIME]

    correspond à 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 défini sur linear, cet intervalle est le même pour chaque nouvelle tentative. Si mode est défini sur exponential, l'intervalle augmente à chaque fois. (Pour en savoir plus, consultez mode.)

  • backoffMode

    LINEAR ou EXPONENTIAL, indiquant s'il faut ou non augmenter le délai entre les tentatives. Si la valeur est LINEAR, le délai entre les tentatives est constant et défini sur WAIT_TIME. Si la valeur est EXPONENTIAL, le délai entre les nouvelles tentatives est doublé à chaque nouvelle tentative. La valeur par défaut est LINEAR.

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

  • rollback

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

  • [PHASE_NAME]

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

Abandonner l'exécution d'une automatisation repairRolloutRule

Si vous exécutez l'une des commandes suivantes sur votre déploiement, l'automatisation repairRolloutRule est abandonnée :

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 une minute d'attente entre chaque tentative. Si toutes les tentatives échouent, un rollback est lancé en créant un déploiement pour déployer la dernière version réussie de la cible sur cette cible.

Étapes suivantes