Usar regras de automação

Este documento descreve as regras de automação, que são ações que podem ser realizadas automaticamente no pipeline de entrega. Por exemplo, é possível configurar o pipeline de entrega para que a promoção para um destino específico aconteça automaticamente, nas circunstâncias certas.

Só é possível usar regras de automação integradas ao Cloud Deploy. As regras de automação disponíveis estão listadas neste documento.

Regras de automação disponíveis

As seguintes regras de automação estão disponíveis no Cloud Deploy:

Regra Descrição
timedPromoteReleaseRule Promove automaticamente de um destino para o próximo

com base em uma programação cron.
promoteReleaseRule Promove automaticamente uma versão para o destino indicado após a

implantação bem-sucedida no destino anterior na progressão.
advanceRolloutRule Avança automaticamente uma implantação do

estágio indicado para o próximo.
repairRolloutRule Tenta novamente o job ou jobs com falha na implantação um

número especificado de vezes e reverter se todas as novas tentativas falharem.

Configurar regras de automação

A configuração de cada regra de automação depende da regra específica. Esta seção descreve a configuração que todas as regras têm em comum, bem como como configurar cada uma das regras disponíveis.

Cada regra de automação é configurada como parte da configuração do recurso de automação. Isso pode estar no mesmo arquivo que a configuração do pipeline de entrega relevante (geralmente chamado de clouddeploy.yaml) ou em qualquer arquivo que você quiser. Saiba mais sobre como configurar automações.

As seções a seguir descrevem a configuração específica de regras de automação individuais. Consulte Automatizar a implantação para a configuração da automação.

Configurar uma regra de automação timedPromoteReleaseRule

A regra timedPromoteReleaseRule permite programar quando promover uma versão dos destinos selecionados para o próximo destino na progressão ou para um destino especificado. Ao configurar uma automação timedPromoteReleaseRule, você especifica quando promover a versão, com base em uma programação cron.

rules:
- timedPromoteReleaseRule:
    id: "[RULE_ID]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Em que:

  • [RULE_ID]

    É qualquer nome que você queira dar a essa regra. Esse nome precisa ser exclusivo no recurso de automação.

  • [CRON]

    É a programação cron que especifica quando promover a versão. Use essa programação para especificar a data e a hora em que você quer promover a versão.

    Essa programação usa a sintaxe cron padrão:

    * * * * *

    Nessa programação...

    • A primeira posição é o minuto (0-59).
    • A segunda posição é a hora (0-23).
    • A terceira posição é o dia do mês (1-31).
    • A quarta posição é o mês (1-12).
    • A quinta posição é o dia da semana (0-6, domingo a sábado)

    Por exemplo, se a regra de promoção programada incluir a seguinte programação: 0 9 * * 1, a versão será promovida todas as segundas-feiras às 9h.

    Também é possível usar recursos de programação cron padrão, como:

    • Um intervalo (0-5)
    • Uma lista (1,3,5)
    • Uma função de etapa (por exemplo, */3 no campo de horas ativa a cada três horas)

  • [TIME_ZONE]

    É o fuso horário que você quer usar para programar a promoção, no formato IANA.

  • [TO_TARGET]

    É o targetId do destino para promover ou @next para promover a versão automaticamente para o próximo destino após o destino especificado no selector.targets property nesta configuração de automação. Isso é opcional. O padrão é @next.

  • [TO_PHASE]

    É o nome do estágio da fase para a qual você quer promover, por exemplo, canary-25 ou stable. Essa propriedade é opcional. Se você a omitir, a versão será promovida para o primeiro estágio no destino.

Configurar uma regra de automação promoteReleaseRule

A regra promoteReleaseRule promove sua versão após uma implantação bem-sucedida em um destino. Por exemplo, se você tiver três destinos, poderá configurar essa regra para que, quando a versão for implantada com sucesso no primeiro destino, ela seja promovida automaticamente para o segundo destino.

Ao configurar uma automação promoteReleaseRule, é possível especificar um destino para promover (destinationTargetId) ou @next. Quando a implantação termina com sucesso no destino especificado na definição Automation, a versão é promovida para o destino especificado em destinationTargetId, sujeita a um intervalo de tempo wait.

Também é possível promover uma versão para uma fase específica no destino pretendido, usando a propriedade destinationPhase. A estrofe rules mostrada aqui está dentro da sua definição de automação.

rules:
- promoteReleaseRule:
    id: "[RULE_ID]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Em que:

  • [RULE_ID]

    É qualquer nome que você queira dar a essa regra. Esse nome precisa ser exclusivo no recurso de automação.

  • [WAIT_TIME]

    É o tempo, em minutos, a aguardar após a versão estar pronta para promoção antes de ser promovida. Por exemplo, 1m. O m é obrigatório.

    O valor padrão é 0, ou nenhum tempo de espera. O máximo é 20160m (ou 14 dias).

  • [TO_TARGET]

    É o targetId do destino para promover.

    Também pode ser @next, que promove a versão automaticamente para o próximo destino após o destino especificado na propriedade selector.targets nesta configuração de automação. Esse é o padrão se você omitir o valor de destinationTargetId.

  • [TO_PHASE]

    É o nome do estágio para o qual você quer promover, por exemplo, canary-25 ou stable. Essa propriedade é opcional. Se você a omitir, a versão será promovida para o primeiro estágio no destino.

Configurar uma regra de automação advanceRolloutRule

A advanceRolloutRule avança a implantação automaticamente, após a conclusão bem-sucedida de uma fase, para a próxima. Essa regra de automação é útil para implantações canário. Por exemplo, se você tiver uma estratégia de implantação canário configurada em um destino, com fases de 25%, 50% e stable, poderá configurar uma regra de automação que avança a fase automaticamente para stable após a conclusão da fase 50%.

Ao configurar uma automação advanceRolloutRule, você identifica a fase a ser avançada de (a sourcePhase). A estrofe rules mostrada aqui está dentro da sua definição de automação.

rules:
- advanceRolloutRule:
    id: "[RULE_ID]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Em que:

  • [RULE_ID]

    É qualquer nome que você queira dar a essa regra. Esse nome precisa ser exclusivo no recurso de automação.

  • [WAIT_TIME]

    É o tempo, em minutos, a aguardar para avançar a implantação depois que ela estiver pronta. Por exemplo, 1m. O m é obrigatório.

    O valor padrão é 0, ou nenhum tempo de espera. O máximo é 20160m (ou 14 dias).

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

    É a fase ou fases de que a implantação é avançada automaticamente. Ou seja, quando qualquer uma das fases listadas terminar com sucesso, a implantação será avançada automaticamente dessa fase para a próxima.

    Os nomes das fases diferenciam maiúsculas de minúsculas. Além disso, esses nomes de fase são opcionais. Se você omitir sourcePhases, todas as fases na implantação serão avançadas automaticamente.

Configurar uma regra de automação repairRolloutRule

A regra repairRolloutRule tenta novamente uma implantação com falha um número especificado de vezes. Se esse número de novas tentativas for esgotado, essa regra poderá reverter automaticamente o destino para a última versão bem-sucedida.

Ao configurar uma automação repairRolloutRule, é possível especificar quantas vezes tentar novamente a implantação e o tempo de espera entre as novas tentativas. Também é possível configurar fases ou jobs específicos, ou ambos, para tentar novamente. Se cada tentativa falhar, a implantação falhará. Se alguma tentativa for bem-sucedida, a automação será interrompida e a implantação será bem-sucedida.

Opcionalmente, é possível configurar a automação para reverter para a última versão bem-sucedida no destino. As novas tentativas também são opcionais, mas é necessário ter um número de novas tentativas ou uma reversão, ou ambos.

A estrofe rules mostrada aqui está dentro da sua definição de automação.

rules:
- repairRolloutRule:
    id: "[RULE_ID]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]
        disableRollbackIfRolloutPending: [true | false]

Em que:

  • [RULE_ID]

    É qualquer nome que você queira dar a essa regra. Esse nome precisa ser exclusivo no recurso de automação.

  • [PHASES_TO_REPAIR]

    É a fase ou fases de implantação a serem repetidas. Isso é opcional, e o padrão é todas as fases na implantação.

  • [JOBS_TO_REPAIR]

    É o job ou jobs a serem repetidos. Isso é opcional, e o padrão é todos os jobs.

  • [NUMBER_OF_ATTEMPTS]

    Opcional, o número de vezes para tentar novamente a implantação antes de considerá-la com falha.

  • [WAIT_TIME]

    É o tempo de espera entre as novas tentativas. Por exemplo, 1m para um intervalo de um minuto. A unidade de tempo (m neste caso) é obrigatória.

    Se mode for linear, esse intervalo será o mesmo para cada nova tentativa. Se mode for exponential, o intervalo aumentará a cada vez. (Consulte mode para mais descrição.)

  • backoffMode

    LINEAR ou EXPONENTIAL, indicando se é necessário ou não aumentar o tempo entre as novas tentativas. Se LINEAR, o tempo entre as novas tentativas será constante, em WAIT_TIME. Se EXPONENTIAL, o tempo entre as novas tentativas será dobrado a cada nova tentativa. O padrão é LINEAR.

    Por exemplo, se WAIT_TIME for 1m e backoffMode estiver definido como EXPONENTIAL, o tempo entre a falha e a primeira nova tentativa será de 1 minuto, o tempo entre a primeira e a segunda novas tentativas será de 2 minutos e o tempo entre a segunda e a terceira novas tentativas será de 4 minutos.

  • rollback

    Opcional, se é necessário ou não reverter a implantação com falha após todas as novas tentativas serem esgotadas.

  • [PHASE_NAME]

    É o nome de uma fase específica para a qual você quer reverter. Se você omitir toPhase, a reversão será padrão para a fase stable.

  • disableRollbackIfRolloutPending:

    Se definido como true, a operação de reversão será interrompida se houver uma implantação pendente no destino.

Interromper uma execução de automação repairRolloutRule

Se você executar um dos comandos a seguir na implantação, a automação repairRolloutRule será interrompida:

Exemplo

A seguir, um exemplo de configuração de automação com uma 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:
    id: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

Nessa automação, se uma implantação falhar no destino identificado, ela será repetida até três vezes, com um minuto de espera entre as novas tentativas. Se todas as novas tentativas falharem, uma reversão será iniciada criando uma nova implantação para implantar a versão bem-sucedida mais recente do destino.

A seguir