Usar reglas de automatización

En este documento se describen las reglas de automatización, que son acciones que se pueden llevar a cabo automáticamente en tu canal de distribución. Por ejemplo, puedes configurar tu flujo de procesamiento de entrega para que la promoción a un destino específico se produzca automáticamente en las circunstancias adecuadas.

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

Reglas de automatización disponibles

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

Regla Descripción
timedPromoteReleaseRule Ascender automáticamente de un destino a otro

basado en una programación cron.
promoteReleaseRule Asciende automáticamente una versión al destino indicado después de que se haya completado correctamente

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

fase a la siguiente.
repairRolloutRule Volver a intentar automáticamente la tarea o las tareas fallidas de la implementación

el número de veces especificado y se revierte si fallan todos los reintentos.

Configurar 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 tienen en común todas las reglas, 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. Puede estar en el mismo archivo que la configuración de la canalización de distribución correspondiente (normalmente, clouddeploy.yaml) o en cualquier archivo que quieras. Más información sobre cómo configurar automatizaciones

En las siguientes secciones se describe la configuración específica de cada regla de automatización. Consulta Automatización del despliegue para configurar la automatización.

Configurar una regla de automatización timedPromoteReleaseRule

La regla timedPromoteReleaseRule te permite programar cuándo promocionar una versión desde el objetivo o los objetivos seleccionados hasta el siguiente objetivo de la progresión o hasta un objetivo específico. Cuando configuras una automatización timedPromoteReleaseRule, especificas cuándo se debe promocionar la versión según una programación cron.

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

Donde:

  • [RULE_NAME]

    Es el nombre que quieras dar a esta regla. Este nombre debe ser único en la canalización de distribución.

  • [CRON]

    Es la programación cron que especifica cuándo se debe promocionar la versión. Usa esta programación para especificar la fecha y la hora en las que quieres promocionar el lanzamiento.

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

    * * * * *

    En esta programación...

    • 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 la siguiente programación: 0 9 * * 1, tu lanzamiento se promocionará todos los lunes a las 9:00.

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

    • Un intervalo (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 quiere usar para programar la promoción en formato IANA.

  • [TO_TARGET]

    Es el targetId de destino al que se va a ascender o el @next al que se va a ascender la versión automáticamente después del destino especificado en el selector.targets property de esta configuración de automatización. Este paso es opcional. El valor predeterminado es @next.

  • [TO_PHASE]

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

Configurar una regla de automatización promoteReleaseRule

La regla promoteReleaseRule asciende tu versión después de un lanzamiento correcto a 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 ascienda automáticamente al segundo.

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

También puedes promocionar una versión a una fase específica del objetivo previsto mediante la propiedad destinationPhase. La estrofa rules que se muestra aquí va dentro de la definición de automatización.

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

Donde:

  • [RULE_NAME]

    Es el nombre que quieras dar a esta regla. Este nombre debe ser único en el recurso de automatización.

  • [WAIT_TIME]

    Es el tiempo, en minutos, que se debe esperar después de que el lanzamiento esté listo para promocionarse antes de que se promocione. Por ejemplo, 1m. El campo m es obligatorio.

    El valor predeterminado es 0, es decir, no hay tiempo de espera. El máximo es 20160m (o 14 días).

  • [TO_TARGET]

    Es el targetId del objetivo al que se va a promocionar.

    También puede ser @next, que asciende automáticamente la versión al siguiente destino después del 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 quieres ascender, por ejemplo, canary-25 o stable. Esta propiedad es opcional. Si la omite, la versión se promocionará a la primera fase del destino.

Configurar una regla de automatización advanceRolloutRule

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

Cuando configuras una automatización advanceRolloutRule, identificas la fase a la que quieres pasar (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]

Donde:

  • [RULE_NAME]

    Es el nombre que quieras dar a esta regla. Este nombre debe ser único en la canalización de distribución.

  • [WAIT_TIME]

    Es el tiempo, en minutos, que se debe esperar para avanzar en el lanzamiento una vez que esté listo. Por ejemplo, 1m. El campo m es obligatorio.

    El valor predeterminado es 0, es decir, no hay tiempo de espera. El máximo es 20160m (o 14 días).

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

    Es la fase o las fases desde las que se avanza automáticamente la implementación. Es decir, cuando se completa correctamente cualquiera de las fases indicadas, el lanzamiento pasa automáticamente de esa fase a la siguiente.

    En los nombres de las fases se distingue entre mayúsculas y minúsculas. Además, estos nombres de fase son opcionales. Si omites sourcePhases, todas las fases de la implementación se completarán automáticamente.

Configurar una regla de automatización repairRolloutRule

La regla repairRolloutRule vuelve a intentar una implementación fallida un número específico de veces. Si se agota ese número de reintentos, esta regla puede revertir automáticamente el destino a la última versión correcta.

Cuando configures una repairRolloutRule automatización, puedes especificar cuántas veces se debe reintentar el lanzamiento y el tiempo de espera entre reintentos. También puedes configurar fases o tareas específicas, o ambas, para que se vuelvan a intentar. Si falla cada reintento, la implementación falla. Si se completa correctamente algún reintento, la automatización se detiene y el lanzamiento se realiza correctamente.

También puedes configurar la automatización para que vuelva a la última versión correcta en el destino. Los reintentos también son opcionales, pero debes tener un número de reintentos o una reversión, o ambas opciones.

La estrofa rules que se muestra aquí va dentro de la 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]

Donde:

  • [RULE_NAME]

    Es el nombre que quieras dar a esta regla. Este nombre debe ser único en la canalización de distribución.

  • [PHASES_TO_REPAIR]

    Es la fase o las fases de lanzamiento que se deben volver a intentar. Este campo es opcional y, de forma predeterminada, se incluyen todas las fases del lanzamiento.

  • [JOBS_TO_REPAIR]

    Es la tarea o las tareas que se van a volver a intentar. Es opcional y el valor predeterminado es "Todos los trabajos".

  • [NUMBER_OF_ATTEMPTS]

    Opcional: número de veces que se debe volver a intentar la implementación antes de considerarla fallida.

  • [WAIT_TIME]

    Es el tiempo que se debe esperar entre los intentos de reintento. Por ejemplo, 1m para un intervalo de un minuto. Es obligatorio indicar la unidad de tiempo (m en este caso).

    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 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. El valor predeterminado es LINEAR.

    Por ejemplo, si WAIT_TIME es 1m y backoffMode es EXPONENTIAL, el tiempo entre el error 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

    Opcional. Indica si se debe revertir la implementación fallida después de que se hayan agotado todos los intentos.

  • [PHASE_NAME]

    Es el nombre de una fase específica a la que quieres volver. Si omite toPhase, la reversión se realizará de forma predeterminada en la fase stable.

Abortar una repairRolloutRule automatización

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

Ejemplo

A continuación, se muestra un ejemplo de 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 una implementación falla en el destino identificado, se vuelve a intentar hasta 3 veces, con un minuto de espera entre cada intento. Si fallan todos los intentos, se inicia una reversión creando un nuevo lanzamiento para desplegar la versión correcta más reciente del objetivo en ese objetivo.

Siguientes pasos