Usa reglas de automatización

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

Solo puedes usar las 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:

Cómo 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 todas las reglas tienen en común, así como cómo 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 relevante (por lo general, se llama 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 las reglas de automatización individuales. Consulta Automatiza tu implementación para configurar la automatización.

Cómo configurar 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 promocione automáticamente al segundo.

Cuando configuras una automatización de promoteReleaseRule, puedes especificar un objetivo al que 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 wait.

También puedes promocionar una versión a una fase específica en el destino previsto con la propiedad destinationPhase. La estrofa rules que se muestra aquí se encuentra 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 la versión esté lista para la promoción antes de que se promocione. Por ejemplo, 1m. m es obligatorio.

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

• [TO_TARGET]

  Es el targetId del destino al que se promocionará.

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

Cómo configurar una regla de automatización de timedPromoteReleaseRule

La regla timedPromoteReleaseRule te permite programar cuándo promocionar una versión de los destinos seleccionados al siguiente destino en el progreso o a un destino específico. Cuando configuras una automatización de timedPromoteReleaseRule, especificas cuándo promocionar la versión según un programa 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 publicación.

• [CRON]

  Es el programa cron que especifica cuándo promocionar el lanzamiento. Usa este programa para especificar la fecha y hora en la 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 publicación programada incluye el siguiente programa: 0 9 * * 1, tu lanzamiento se promociona todos los lunes a las 9 a.m.

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

  • Un rango (0-5)
  • Una lista (1,3,5)
  • Una función de paso (por ejemplo, */3 en el campo de horas se 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 debe promocionar o @next para promocionar la versión automáticamente al siguiente destino después del destino especificado en selector.targets property en esta configuración de automatización. Esto es opcional. El valor predeterminado es @next.

• [TO_PHASE]

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

Cómo configurar una regla de automatización de advanceRolloutRule

advanceRolloutRule avanza tu lanzamiento, automáticamente, después de completar una fase de forma correcta, a la siguiente fase. Esta regla de automatización es útil para las implementaciones canary. Por ejemplo, si tienes una estrategia de implementación de versiones canary configurada en un objetivo, con fases de 25%, 50% y stable, podrías 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 avanzar (el sourcePhase). La estrofa rules que se muestra aquí se encuentra 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 publicación.

• [WAIT_TIME]

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

  El valor predeterminado es 0, o bien 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 el lanzamiento. Es decir, cuando cualquiera de las fases enumeradas finaliza correctamente, el lanzamiento avanza automáticamente de esa fase a la siguiente.

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

Cómo configurar una regla de automatización de repairRolloutRule

La regla repairRolloutRule vuelve a intentar un lanzamiento fallido 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 que se realizó correctamente.

Cuando configuras una automatización de repairRolloutRule, puedes especificar cuántas veces se debe reintentar el lanzamiento y el tiempo de espera entre los reintentos. También puedes configurar fases o trabajos específicos, o ambos, para que se vuelvan a intentar. Si falla cada intento de reintento, falla el lanzamiento. Si alguno de los reintentos se realiza correctamente, la automatización se detiene y el lanzamiento se realiza correctamente.

De manera opcional, puedes configurar la automatización para que se revierta a la última versión que se implementó correctamente en el destino. Los reintentos también son opcionales, pero debes tener una cantidad de reintentos o una reversión, o ambas.

La estrofa rules que se muestra aquí se encuentra 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 publicación.

• [PHASES_TO_REPAIR]

  Es la fase o fases del lanzamiento que se volverán a intentar. Esto es opcional, y el valor predeterminado es todas las fases del lanzamiento.

• [JOBS_TO_REPAIR]

  Es el trabajo o los trabajos que se volverán a intentar. Esta opción es opcional y el valor predeterminado es todos los trabajos.

• [NUMBER_OF_ATTEMPTS]

  Es opcional. Es la cantidad de veces que se debe reintentar el lanzamiento antes de considerar que falló.

• [WAIT_TIME]

  Es la cantidad de tiempo que se debe esperar entre dos 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 detalles).

• backoffMode

  LINEAR o EXPONENTIAL, que indica si se debe aumentar o no el tiempo entre los retiros. Si es LINEAR, el tiempo entre los reintentos es constante, en 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 1m y backoffMode está configurado en EXPONENTIAL, entonces 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

  Opcional: Indica si se debe revertir o no la implementación fallida después de que se agoten 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 establecerá de forma predeterminada en la fase stable.

Cómo abortar una ejecución de automatización de repairRolloutRule

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

• Cómo reintentar un trabajo
• Cancelar lanzamiento
• Cómo ignorar un trabajo
• Cómo finalizar la ejecución de un trabajo

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 vuelve a intentar hasta 3 veces, con un tiempo de espera de un minuto entre cada intento. Si todos los intentos de reintento fallan, se inicia una reversión mediante la creación de un lanzamiento nuevo para implementar la versión correcta más reciente del destino en ese destino.

¿Qué sigue?

• Prueba la guía de inicio rápido: Automatiza la creación de lanzamientos y el avance del lanzamiento.

• Obtén más información sobre la automatización de la implementación en Cloud Deploy.