Usar regras de automação

Este documento descreve as regras de automação, que são ações que podem ser realizadas automaticamente no seu pipeline de entrega. Por exemplo, você pode configurar seu 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 Promover automaticamente de um destino para o próximo

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

lançamento no destino anterior da progressão.
advanceRolloutRule Avança automaticamente um lançamento da

fase para a próxima fase.
repairRolloutRule Tentar de novo automaticamente o job ou os jobs com falha no lançamento

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 a forma de configurar cada uma das regras disponíveis.

Cada regra de automação é configurada como parte da configuração do recurso de automação. Ele pode estar no mesmo arquivo da 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 cada regra de automação. Consulte Automatizar sua implantação para configurar a automação.

Configurar uma regra de automação do timedPromoteReleaseRule

Com a regra timedPromoteReleaseRule, é possível programar quando promover uma versão do destino ou destinos selecionados para o próximo destino na progressão ou para um destino especificado. Ao configurar uma automação de timedPromoteReleaseRule, você especifica quando promover a versão, com base em uma programação cron.

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

Em que:

  • [RULE_NAME]

    É qualquer nome que você queira dar a essa regra. Ele precisa ser exclusivo no pipeline de entrega.

  • [CRON]

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

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

    * * * * *

    Nesta 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, de domingo a sábado)

    Por exemplo, se a regra de promoção programada incluir a seguinte programação:0 9 * * 1, sua versão será promovida toda segunda-feira às 9h.

    Você também pode usar recursos padrão de programação cron, como:

    • Um intervalo (0-5)
    • Uma lista (1,3,5)
    • Uma função de etapa (por exemplo, */3 no campo "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 da fase da fase que você quer promover, por exemplo, canary-25 ou stable. Essa propriedade é opcional. Se você omitir, a versão será promovida para a primeira fase no destino.

Configurar uma regra de automação do promoteReleaseRule

A regra promoteReleaseRule promove a versão depois de um lançamento bem-sucedido 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.

Ao configurar uma automação de promoteReleaseRule, é possível especificar um destino para promover (destinationTargetId) ou @next. Quando o lançamento 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 seção rules mostrada aqui fica dentro da sua definição de automação.

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

Em que:

  • [RULE_NAME]

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

  • [WAIT_TIME]

    É o tempo, em minutos, que aguardamos depois que a versão está pronta para promoção antes de ser promovida. Por exemplo, 1m O m é obrigatório.

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

  • [TO_TARGET]

    É o targetId do destino a ser promovido.

    Também pode ser @next, que promove automaticamente a versão para o próximo destino após o 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 da fase para a qual você quer promover, por exemplo, canary-25 ou stable. Essa propriedade é opcional. Se você omitir, a versão será promovida para a primeira fase no destino.

Configurar uma regra de automação do advanceRolloutRule

O advanceRolloutRule avança o lançamento automaticamente para a próxima fase após a conclusão de uma delas. 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 uma meta, com fases de 25%, 50% e stable, poderá configurar uma regra de automação que avança automaticamente para a fase stable depois que a fase 50% terminar.

Ao configurar uma automação do advanceRolloutRule, você identifica a fase para avançar de (o sourcePhase). A estrofe rules mostrada aqui fica dentro da sua definição de automação.

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

Em que:

  • [RULE_NAME]

    É qualquer nome que você queira dar a essa regra. Ele precisa ser exclusivo no pipeline de entrega.

  • [WAIT_TIME]

    É a quantidade de tempo, em minutos, que aguarda para avançar o lançamento depois que ele está pronto. Por exemplo, 1m O m é obrigatório.

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

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

    É a fase ou as fases de onde o lançamento é avançado automaticamente. Ou seja, quando qualquer uma das fases listadas é concluída com sucesso, o lançamento é automaticamente avançado 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 do lançamento serão avançadas automaticamente.

Configurar uma regra de automação do repairRolloutRule

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

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

Também é 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 você precisa ter um número de novas tentativas ou um rollback, ou ambos.

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

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]

Em que:

  • [RULE_NAME]

    É qualquer nome que você queira dar a essa regra. Ele precisa ser exclusivo no pipeline de entrega.

  • [PHASES_TO_REPAIR]

    É a fase ou as fases de lançamento a serem repetidas. Isso é opcional, e o padrão são todas as fases do lançamento.

  • [JOBS_TO_REPAIR]

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

  • [NUMBER_OF_ATTEMPTS]

    Opcional: o número de vezes que o lançamento é repetido antes de ser considerado com falha.

  • [WAIT_TIME]

    É o tempo de espera entre as repetições das 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 vai aumentar a cada vez. Consulte mode para mais detalhes.

  • backoffMode

    LINEAR ou EXPONENTIAL, indicando se o tempo entre as novas tentativas deve ser aumentado ou não. Se LINEAR, o tempo entre novas tentativas será constante, em WAIT_TIME. Se EXPONENTIAL, o tempo entre novas tentativas vai dobrar a cada nova tentativa sucessiva. 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, entre a primeira e a segunda será de 2 minutos e entre a segunda e a terceira será de 4 minutos.

  • rollback

    Opcional. Indica se a reverter do lançamento com falha deve ser feita após todas as tentativas de nova tentativa serem esgotadas.

  • [PHASE_NAME]

    É o nome de uma fase específica para a qual você quer fazer reverter. Se você omitir toPhase, o rollback vai usar a fase stable por padrão.

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

Se você executar qualquer um dos comandos a seguir no seu lançamento, a automação do repairRolloutRule será cancelada:

Exemplo

Confira a seguir um exemplo de configuração de automação com um 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"

Nessa automação, se um lançamento falhar no destino identificado, ele será tentado novamente até três vezes, com um minuto de espera entre as tentativas. Se todas as tentativas de repetição falharem, uma reversão será iniciada criando uma nova implantação para implantar a versão mais recente do destino para ele.

A seguir