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 entrega para que se lleve a cabo la promoción en un objetivo específico automáticamente, en las circunstancias adecuadas.

Solo puedes usar las reglas de automatización que están integradas en Cloud Deploy. Las reglas de automatización disponibles se enumeran en este documento.

Reglas de automatización disponibles

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

Regla Descripción
promoteReleaseRule Promueve automáticamente una versión en el destino indicado una vez exitosa

lanzamiento en el objetivo anterior en el progreso.
advanceRolloutRule Adelantar automáticamente un lanzamiento desde el valor indicado

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

cantidad de veces especificada y revertir 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. Esta describe la configuración que tienen todas las reglas en común, así como para configurar cada una de las reglas disponibles.

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.

Configura una regla de automatización de promoteReleaseRule

La regla promoteReleaseRule promueve tu versión después de un lanzamiento exitoso en un objetivo. 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 termine correctamente en el destino especificado en la definición de Automation, el versión se asciende 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.

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 luego de que la versión esté lista promoción antes de que se promocione. Por ejemplo, 1m. m es obligatorio.

    El valor predeterminado es 0 o sin 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. Esta es la opción predeterminada si omite el valor de destinationTargetId.

  • [TO_PHASE]

    Es el nombre de la fase de la fase a la que quieres promover, 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 advanceRolloutRule

La advanceRolloutRule avanza el lanzamiento automáticamente después de que se realiza correctamente la finalización de una fase a la fase siguiente. Esta regla de automatización es útil implementaciones de versiones canary. Por ejemplo, si tienes una estrategia de implementación de versiones canary configurado en un destino, con fases de 25%, 50% y stable, podrías configura una regla de automatización que avance automáticamente la fase a stable después de que finalice la fase 50%.

Cuando configuras una automatización de advanceRolloutRule, identificas la fase que avanzar desde (el sourcePhase).

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 la implementación después de la el lanzamiento 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]"...]

    Indica la fase o fases a partir de las cuales el lanzamiento avanza automáticamente. Es decir, cuando alguna de las fases de la lista finaliza correctamente, el lanzamiento se y avanzar 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 se omite sourcePhases, todas las fases del lanzamiento avanzan automáticamente.

Configura una regla de automatización repairRolloutRule

La regla repairRolloutRule vuelve a intentar un lanzamiento fallido una cantidad especificada de veces. Si esa cantidad de reintentos se agota, esta regla puede revertir el destino a la última versión exitosa

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 en cada reintento falla, el lanzamiento falla. Si un reintento tiene éxito, la automatización se detiene y el lanzamiento exitoso.

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

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 del canalización de entrega continua.

  • [PHASES_TO_REPAIR]

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

  • [JOBS_TO_REPAIR]

    Es el trabajo o los trabajos que se deben reintentar. 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 en 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 indican si se debe aumentar el tiempo o no entre los retiros. Si es LINEAR, el tiempo entre reintentos es constante, en WAIT_TIME Si es EXPONENTIAL, el tiempo entre reintentos se duplica con cada un reintento sucesivo. La ruta predeterminada es LINEAR

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

  • rollback

    Opcional, si se debe revertir o no el lanzamiento con errores después de todos los reintentos se agotan todos los intentos.

  • [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 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:

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?