Utiliser des règles d'automatisation

Ce document décrit les règles d'automatisation, c'est-à-dire les actions qui peuvent être effectuées automatiquement sur votre pipeline de livraison. Par exemple, vous pouvez configurer votre le pipeline de livraison de manière à ce que la promotion dans une cible spécifique se produise automatiquement, dans les circonstances appropriées.

Vous ne pouvez utiliser que des 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
promoteReleaseRule Promeut automatiquement une version dans la cible indiquée en cas de réussite

déployer dans la cible précédente dans la progression.
advanceRolloutRule Avance automatiquement un déploiement à partir de la ligne indiquée

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

le nombre de fois spécifié et effectuer 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 concernée. Cette section décrit la configuration commune à toutes les règles, ainsi que la configuration de chacune des règles disponibles.

Les sections suivantes décrivent la configuration spécifique à chaque automatisation des règles de pare-feu. Consultez la page Automatiser votre déploiement. pour la configuration de l'automatisation elle-même.

Configurer une règle d'automatisation promoteReleaseRule

La règle promoteReleaseRule met en avant 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 cible à promouvoir sur (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.

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 le ressource d'automatisation de l'IA.

  • [WAIT_TIME]

    Indique le délai d'attente (en minutes) 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, ou aucun 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 vers la cible suivante après la cible spécifiée dans la propriété selector.targets dans cette configuration d'automatisation. Il s'agit du paramètre par défaut 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 promu à 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 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 à partir de laquelle vous souhaitez avancer (sourcePhase).

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 de livraison.

  • [WAIT_TIME]

    Temps d'attente, en minutes, avant l'avancement du déploiement le déploiement est prêt. Par exemple, 1m. m est obligatoire.

    La valeur par défaut est 0, ou aucun 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 avec succès, le déploiement est passe automatiquement de cette phase à la phase suivante.

    Les noms de phases sont sensibles à la casse. De plus, ces noms de phase 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 le nombre de tentatives est atteint, la règle peut effectuer un rollback de la cible vers 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. Il n'est pas obligatoire d'effectuer de nouvelles tentatives, un certain nombre de tentatives ou un rollback, ou les deux.

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 de livraison.

  • [PHASES_TO_REPAIR]

    correspond à la ou aux phases de déploiement à relancer. Ce paramètre est facultatif et la valeur par défaut est "Toutes les phases du déploiement".

  • [JOBS_TO_REPAIR]

    Il s'agit de la ou des tâches à relancer. Cette option est facultative et la valeur par défaut est "Toutes les tâches".

  • [NUMBER_OF_ATTEMPTS]

    Facultatif : nombre de tentatives d'exécution du déploiement avant de le considérer comme ayant é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 s'il faut ou non augmenter l'heure entre les retraits. Si la valeur est LINEAR, le délai entre les 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 correspond à 1 m et que backoffMode est défini sur EXPONENTIAL, alors le délai entre l'échec et la première tentative est d'une minute, ce qui correspond entre la première et la deuxième tentative est de 2 minutes, et le délai entre la deuxième et la troisième tentative dure 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, le rollback est défini par défaut sur la phase stable.

Annuler une exécution d'automatisation repairRolloutRule

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

Exemple

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

Étape suivante