Usar regras de automatização

Este documento descreve as regras de automatização, que são ações que podem ser tomadas automaticamente na sua pipeline de entrega. Por exemplo, pode configurar o pipeline de implementação para que a promoção para um alvo específico ocorra automaticamente, nas circunstâncias certas.

Só pode usar regras de automatização integradas no Cloud Deploy. As regras de automatização disponíveis estão listadas neste documento.

Regras de automatização disponíveis

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

Regra Descrição
timedPromoteReleaseRule Promova automaticamente de um alvo para o seguinte

com base num horário cron.
promoteReleaseRule Promove automaticamente uma versão para o destino indicado após a conclusão bem-sucedida

implementação no alvo anterior na progressão.
advanceRolloutRule Avança automaticamente uma implementação a partir do

fase para a fase seguinte.
repairRolloutRule Tentar novamente automaticamente a tarefa ou as tarefas com falhas na implementação

especificado, e reverter se todas as novas tentativas falharem.

Configure regras de automatização

A configuração de cada regra de automatização depende da regra específica. Esta secçã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 automatização é configurada como parte da configuração do recurso de automatização. Pode estar no mesmo ficheiro que a configuração do pipeline de entrega relevante (normalmente denominado clouddeploy.yaml) ou em qualquer ficheiro que quiser. Saiba como configurar automatizações.

As secções seguintes descrevem a configuração específica das regras de automatização individuais. Consulte Automatize a sua implementação para configurar a automatização propriamente dita.

Configure uma regra de automatização timedPromoteReleaseRule

A regra timedPromoteReleaseRule permite-lhe agendar quando promover um lançamento a partir do alvo ou alvos selecionados para o alvo seguinte na progressão ou para um alvo especificado. Quando configura uma automatização timedPromoteReleaseRule, especifica quando promover o lançamento com base num horário cron.

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

Onde:

  • [RULE_NAME]

    É qualquer nome que queira dar a esta regra. Este nome tem de ser exclusivo no pipeline de entrega.

  • [CRON]

    É o horário cron que especifica quando promover o lançamento. Use este horário para especificar a data e a hora em que quer promover o lançamento.

    Este horário usa a sintaxe padrão cron:

    * * * * *

    Neste horário…

    • 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 sua regra de promoção por tempo limitado incluir a seguinte programação: 0 9 * * 1, o lançamento é promovido todas as segundas-feiras às 09:00.

    Também pode usar funcionalidades de programação cron padrão, como:

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

  • [TIME_ZONE]

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

  • [TO_TARGET]

    É o targetId do destino para o qual a versão vai ser promovida ou @next para promover automaticamente a versão para o destino seguinte após o destino especificado no selector.targets property nesta configuração de automatização. Esta ação é opcional; o valor predefinido é @next.

  • [TO_PHASE]

    É o nome da fase da fase que quer promover, por exemplo, canary-25 ou stable. Esta propriedade é opcional. Se a omitir, o lançamento é promovido para a primeira fase no destino.

Configure uma regra de automatização promoteReleaseRule

A regra promoteReleaseRule promove o lançamento após uma implementação bem-sucedida num alvo. Por exemplo, se tiver três alvos, pode configurar esta regra para que, quando o lançamento for implementado com êxito no primeiro alvo, seja promovido automaticamente ao segundo alvo.

Quando configura uma automatização promoteReleaseRule, pode especificar um alvo para promover (destinationTargetId) ou @next. Quando a implementação termina com êxito no alvo especificado na definição Automation, a versão é promovida para o alvo especificado em destinationTargetId, sujeita a um intervalo de tempo wait.

Também pode promover uma versão para uma fase específica no destino pretendido, usando a propriedade destinationPhase. A secção rules apresentada aqui é colocada na sua definição de automatização.

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

Onde:

  • [RULE_NAME]

    É qualquer nome que queira dar a esta regra. Este nome tem de ser exclusivo no recurso de automatização.

  • [WAIT_TIME]

    É o período de tempo, em minutos, a aguardar após o lançamento estar pronto para promoção antes de ser promovido. Por exemplo, 1m. O campo m é obrigatório.

    O valor predefinido é 0, ou seja, sem tempo de espera. O máximo é de 20160m (ou 14 dias).

  • [TO_TARGET]

    É o targetId do alvo a promover.

    Também pode ser @next, que promove automaticamente o lançamento para o próximo destino após o destino especificado na propriedade selector.targets nesta configuração de automatização. Esta é a predefinição se omitir o valor de destinationTargetId.

  • [TO_PHASE]

    É o nome da fase para a qual quer promover, por exemplo, canary-25 ou stable. Esta propriedade é opcional. Se a omitir, o lançamento é promovido para a primeira fase no destino.

Configure uma regra de automatização advanceRolloutRule

O advanceRolloutRule avança a implementação automaticamente, após a conclusão bem-sucedida de uma fase, para a fase seguinte. Esta regra de automatização é útil para implementações de teste. Por exemplo, se tiver uma estratégia de implementação canária configurada num alvo, com fases de 25%, 50% e stable, pode configurar uma regra de automatização que avance automaticamente a fase para stable após a conclusão da fase 50%.

Quando configura uma automatização advanceRolloutRule, identifica a fase a avançar a partir (o sourcePhase). A secção rules apresentada aqui é incluída na definição de automatização.

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

Onde:

  • [RULE_NAME]

    É qualquer nome que queira dar a esta regra. Este nome tem de ser exclusivo no pipeline de entrega.

  • [WAIT_TIME]

    É o período de tempo, em minutos, a aguardar para avançar a implementação após a implementação estar pronta. Por exemplo, 1m. O campo m é obrigatório.

    O valor predefinido é 0, ou seja, sem tempo de espera. O máximo é de 20160m (ou 14 dias).

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

    É a fase ou as fases a partir das quais a implementação é avançada automaticamente. Ou seja, quando qualquer uma das fases indicadas termina com êxito, a implementação é automaticamente avançada dessa fase para a fase seguinte.

    Os nomes das fases são sensíveis a maiúsculas e minúsculas. Além disso, estes nomes de fases são opcionais. Se omitir sourcePhases, todas as fases na implementação são avançadas automaticamente.

Configure uma regra de automatização repairRolloutRule

A regra repairRolloutRule tenta novamente uma implementação falhada um número especificado de vezes. Se esse número de novas tentativas for esgotado, esta regra pode, em seguida, reverter automaticamente o destino para a última versão bem-sucedida.

Quando configura uma automatização repairRolloutRule, pode especificar quantas vezes tentar novamente a implementação e o tempo de espera entre as novas tentativas. Também pode configurar fases ou tarefas específicas, ou ambas, para repetir. Se cada tentativa de repetição falhar, a implementação falha. Se qualquer nova tentativa for bem-sucedida, a automatização é interrompida e a implementação é bem-sucedida.

Opcionalmente, pode configurar a automatização para reverter para a versão bem-sucedida mais recente no destino. As novas tentativas também são opcionais, mas tem de ter um determinado número de novas tentativas ou uma reversão, ou ambas.

A secção rules apresentada aqui é colocada na sua definição de automatizaçã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]

Onde:

  • [RULE_NAME]

    É qualquer nome que queira dar a esta regra. Este nome tem de ser exclusivo no pipeline de entrega.

  • [PHASES_TO_REPAIR]

    É a fase ou as fases de implementação a tentar novamente. Esta opção é opcional e a predefinição são todas as fases na implementação.

  • [JOBS_TO_REPAIR]

    É a tarefa ou as tarefas a repetir. Esta opção é opcional e a predefinição são todas as tarefas.

  • [NUMBER_OF_ATTEMPTS]

    Opcional, o número de vezes que deve tentar a implementação antes de a considerar com falhas.

  • [WAIT_TIME]

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

    Se mode for linear, este intervalo é o mesmo para cada nova tentativa. Se mode for exponential, o intervalo aumenta de cada vez. (Consulte mode para ver uma descrição mais detalhada.)

  • backoffMode

    LINEAR ou EXPONENTIAL, indicando se deve ou não aumentar o tempo entre novas tentativas. Se LINEAR, o tempo entre novas tentativas é constante, em WAIT_TIME. Se EXPONENTIAL, o tempo entre as novas tentativas duplica a cada nova tentativa sucessiva. A predefinição é LINEAR.

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

  • rollback

    Opcional: se deve ou não reverter a implementação com falha depois de esgotadas todas as tentativas de repetição.

  • [PHASE_NAME]

    É o nome de uma fase específica para a qual quer reverter. Se omitir toPhase, a reversão usa a fase stable por predefinição.

Anule uma execução de automatização repairRolloutRule

Se executar qualquer um dos seguintes comandos na implementação, a automação repairRolloutRule é anulada:

Exemplo

Segue-se um exemplo de uma configuração de automatizaçã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"

Nesta automatização, se uma implementação falhar no alvo identificado, essa implementação é tentada novamente até 3 vezes, com um minuto de espera entre cada tentativa. Se todas as tentativas de repetição falharem, é iniciada uma reversão através da criação de uma nova implementação para implementar a versão bem-sucedida mais recente do destino nesse destino.

O que se segue?