Usa reglas de automatización

En este documento, se describen las reglas de automatización, que son acciones que se pueden realizar automáticamente en tu canalización de entrega. Por ejemplo, puedes configurar tu canalización de entrega para que la promoción a un destino específico se realice automáticamente en las circunstancias adecuadas.

Solo puedes usar reglas de automatización integradas en Cloud Deploy. En este documento, se indican las reglas de automatización disponibles.

Reglas de automatización disponibles

Las siguientes reglas de automatización están disponibles en Cloud Deploy:

Regla Descripción
timedPromoteReleaseRule Promover automáticamente de un destino al siguiente

según un programa de cron.
promoteReleaseRule Promueve automáticamente una versión al destino indicado después de una

lanzamiento en el destino anterior de la progresión.
advanceRolloutRule Avanza automáticamente un lanzamiento desde el

Fase a la siguiente fase.
repairRolloutRule Vuelve a intentar automáticamente el trabajo o los trabajos con errores en el lanzamiento.

se reintenta la cantidad de veces especificada y se revierte si fallan todos los reintentos.

Configura reglas de automatización

La configuración de cada regla de automatización depende de la regla específica. En esta sección, se describe la configuración que todas las reglas tienen en común, así como la forma de configurar cada una de las reglas disponibles.

Cada regla de automatización se configura como parte de la configuración del recurso de automatización. Esto puede estar dentro del mismo archivo que la configuración de la canalización de entrega pertinente (por lo general, llamado clouddeploy.yaml) o en cualquier archivo que desees. Obtén más información para configurar automatizaciones.

En las siguientes secciones, se describe la configuración específica de cada regla de automatización. Consulta Automatiza tu implementación para configurar la automatización.

Configura una regla de automatización de timedPromoteReleaseRule

La regla timedPromoteReleaseRule te permite programar cuándo promover una versión desde el destino o los destinos seleccionados al siguiente destino en la progresión o a un destino especificado. Cuando configuras una automatización de timedPromoteReleaseRule, especificas cuándo promover la versión según un programa de cron.

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

Aquí:

  • [RULE_NAME]

    Es cualquier nombre que quieras asignarle a esta regla. Este nombre debe ser único dentro de la canalización de entrega.

  • [CRON]

    Es el programa cron que especifica cuándo promocionar el lanzamiento. Usa este programa para especificar la fecha y la hora en que deseas promocionar el lanzamiento.

    Esta programación usa la sintaxis estándar de cron:

    * * * * *

    En este cronograma…

    • La primera posición es el minuto (0-59).
    • La segunda posición es la hora (0-23).
    • La tercera posición es el día del mes (1-31).
    • La cuarta posición es el mes (1-12).
    • La quinta posición es el día de la semana (0-6, de domingo a sábado).

    Por ejemplo, si tu regla de promoción programada incluye el siguiente programa: 0 9 * * 1, tu lanzamiento se promocionará todos los lunes a las 9 a.m.

    También puedes usar funciones estándar de programación de cron, como las siguientes:

    • Un rango (0-5)
    • Una lista (1,3,5)
    • Una función escalonada (por ejemplo, */3 en el campo de horas activa cada tercera hora)

  • [TIME_ZONE]

    Es la zona horaria que deseas usar para programar la promoción, en formato IANA.

  • [TO_TARGET]

    Es el targetId del destino al que se promoverá la versión o @next para promover automáticamente la versión al siguiente destino después del destino especificado en selector.targets property en esta configuración de automatización. Este campo es opcional y el valor predeterminado es @next.

  • [TO_PHASE]

    Es el nombre de la fase a la que deseas promover la fase, por ejemplo, canary-25 o stable. Esta propiedad es opcional. Si la omites, la versión se promoverá a la primera fase del destino.

Configura una regla de automatización de promoteReleaseRule

La regla promoteReleaseRule promueve tu versión después de un lanzamiento exitoso en un destino. Por ejemplo, si tienes tres destinos, puedes configurar esta regla para que, cuando la versión se implemente correctamente en el primer destino, se promueva automáticamente al segundo.

Cuando configuras una automatización de promoteReleaseRule, puedes especificar un objetivo para promocionar (destinationTargetId) o @next. Cuando el lanzamiento finaliza correctamente en el destino especificado en la definición de Automation, la versión se promueve al destino especificado en destinationTargetId, sujeto a un intervalo de tiempo de wait.

También puedes promover una versión a una fase específica en el destino previsto con la propiedad destinationPhase. La sección rules que se muestra aquí va dentro de tu definición de automatización.

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

Aquí:

  • [RULE_NAME]

    Es cualquier nombre que quieras asignarle a esta regla. Este nombre debe ser único dentro del recurso de automatización.

  • [WAIT_TIME]

    Es la cantidad de tiempo, en minutos, que se debe esperar después de que el lanzamiento esté listo para la promoción antes de que se promocione. Por ejemplo, 1m. m es obligatorio.

    El valor predeterminado es 0, o sea, sin tiempo de espera. La cantidad máxima es 20160m (o 14 días).

  • [TO_TARGET]

    Es el targetId del objetivo al que se promocionará.

    También puede ser @next, que promueve automáticamente la versión al siguiente destino después del destino especificado en la propiedad selector.targets de esta configuración de automatización. Este es el valor predeterminado si omites el valor de destinationTargetId.

  • [TO_PHASE]

    Es el nombre de la fase a la que deseas promover la versión, por ejemplo, canary-25 o stable. Esta propiedad es opcional. Si la omites, la versión se promueve a la primera fase del destino.

Configura una regla de automatización de advanceRolloutRule

advanceRolloutRule avanza tu lanzamiento automáticamente a la siguiente fase después de que se completa correctamente una fase. Esta regla de automatización es útil para las implementaciones de canary. Por ejemplo, si tienes una estrategia de implementación de versiones canary configurada en un destino, con fases de 25%, 50% y stable, puedes configurar una regla de automatización que avance la fase automáticamente a stable después de que finalice la fase 50%.

Cuando configuras una automatización de advanceRolloutRule, identificas la fase desde la que se avanzará (el sourcePhase). La estrofa rules que se muestra aquí va dentro de tu definición de automatización.

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

Aquí:

  • [RULE_NAME]

    Es cualquier nombre que quieras asignarle a esta regla. Este nombre debe ser único dentro de la canalización de entrega.

  • [WAIT_TIME]

    Es la cantidad de tiempo, en minutos, que se debe esperar para avanzar con el lanzamiento después de que esté listo. Por ejemplo, 1m. m es obligatorio.

    El valor predeterminado es 0, o sea, sin tiempo de espera. La cantidad máxima es 20160m (o 14 días).

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

    Es la fase o las fases desde las que se avanza automáticamente el lanzamiento. Es decir, cuando finaliza correctamente cualquiera de las fases enumeradas, el lanzamiento avanza automáticamente de esa fase a la siguiente.

    Los nombres de fase distinguen mayúsculas de minúsculas. Además, estos nombres de fase son opcionales. Si omites sourcePhases, todas las fases del lanzamiento se avanzarán automáticamente.

Configura una regla de automatización de repairRolloutRule

La regla repairRolloutRule vuelve a intentar una implementación fallida una cantidad especificada de veces. Si se agota esa cantidad de reintentos, esta regla puede revertir automáticamente el destino a la última versión correcta.

Cuando configuras una automatización de repairRolloutRule, puedes especificar cuántas veces se reintenta el lanzamiento y el tiempo de espera entre los reintentos. También puedes configurar fases o trabajos específicos, o ambos, para que se reintenten. Si falla cada intento de reintento, la versión falla. Si algún reintento se realiza correctamente, la automatización se detiene y el lanzamiento se completa.

De manera opcional, puedes configurar la automatización para revertir la versión al último lanzamiento exitoso en el destino. Los reintentos también son opcionales, pero debes tener una cantidad de reintentos o una reversión, o ambos.

La sección rules que se muestra aquí va dentro de tu definición de automatización.

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]

Aquí:

  • [RULE_NAME]

    Es cualquier nombre que quieras asignarle a esta regla. Este nombre debe ser único dentro de la canalización de entrega.

  • [PHASES_TO_REPAIR]

    Es la fase o las fases de lanzamiento que se volverán a intentar. Este campo es opcional y el valor predeterminado son todas las fases de la versión.

  • [JOBS_TO_REPAIR]

    Es el trabajo o los trabajos que se volverán a intentar. Este campo es opcional y, de forma predeterminada, se incluyen todos los trabajos.

  • [NUMBER_OF_ATTEMPTS]

    Es opcional. Es la cantidad de veces que se debe reintentar la implementación antes de considerarla fallida.

  • [WAIT_TIME]

    Es la cantidad de tiempo que se debe esperar entre los intentos. Por ejemplo, 1m para un intervalo de un minuto. La unidad de tiempo (m en este caso) es obligatoria.

    Si mode es linear, este intervalo es el mismo para cada reintento. Si mode es exponential, el intervalo aumenta cada vez. (Consulta mode para obtener más información).

  • backoffMode

    LINEAR o EXPONENTIAL, que indica si se debe aumentar el tiempo entre reintentos. Si es LINEAR, el tiempo entre reintentos es constante y equivale a WAIT_TIME. Si es EXPONENTIAL, el tiempo entre reintentos se duplica con cada reintento sucesivo. La ruta predeterminada es LINEAR

    Por ejemplo, si WAIT_TIME es 1 min y backoffMode se establece en EXPONENTIAL, el tiempo entre la falla y el primer reintento es de 1 minuto, el tiempo entre el primer y el segundo reintento es de 2 minutos, y el tiempo entre el segundo y el tercer reintento es de 4 minutos.

  • rollback

    Es opcional y determina si se revierte la versión fallida después de que se agotan todos los intentos de reintento.

  • [PHASE_NAME]

    Es el nombre de una fase específica a la que deseas revertir. Si omites toPhase, la reversión se establece de forma predeterminada en la fase stable.

Cómo anular la ejecución de una automatización de repairRolloutRule

Si ejecutas alguno de los siguientes comandos en tu lanzamiento, se abortará la automatización de repairRolloutRule:

Ejemplo

A continuación, se muestra un ejemplo de una configuración de automatización con 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"

En esta automatización, si un lanzamiento falla en el objetivo identificado, se reintenta hasta 3 veces, con un minuto de espera entre cada intento. Si fallan todos los intentos de reintento, se inicia una reversión creando un lanzamiento nuevo para implementar la versión exitosa más reciente del destino en ese destino.

¿Qué sigue?