Este documento descreve as regras de automação, que são ações que podem ser realizadas no pipeline de entrega automaticamente. Por exemplo, é possível 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 |
---|---|
promoteReleaseRule
|
Promove automaticamente uma versão no destino indicado após a conclusão
no destino anterior na progressão. |
advanceRolloutRule
|
Avançar automaticamente um lançamento a partir do indicado
fase para a próxima fase. |
repairRolloutRule
|
Tente automaticamente o job ou os jobs com falha no lançamento a
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. Isso descreve as configurações que todas as regras têm em comum, além de como para configurar cada uma das regras disponíveis.
As seções a seguir descrevem a configuração específica de regras de automação individuais. Consulte Automatizar a implantação para saber como configurar a automação.
Configurar uma regra de automação promoteReleaseRule
A regra promoteReleaseRule
promove sua versão após um lançamento bem-sucedido no
um alvo. Por exemplo, se você tiver três metas, configure essa regra para que
quando a versão for implantada com sucesso no primeiro destino,
promovido automaticamente para o segundo destino.
Ao configurar uma automação promoteReleaseRule
, é possível especificar um
destino para promover (destinationTargetId
) ou @next
. Quando o lançamento
terminar com sucesso no destino especificado na definição de Automation
, a
versão será promovida para o destino especificado em destinationTargetId
,
sujeito a um intervalo de tempo wait
.
Também é possível promover um lançamento para uma fase específica no destino pretendido. Para isso, use
a propriedade destinationPhase
.
rules:
- promoteReleaseRule:
name: "[RULE_NAME]"
wait: [WAIT_TIME]
destinationTargetId: "[TO_TARGET]"
destinationPhase: "[TO_PHASE]"
Em que:
[RULE_NAME]
É qualquer nome que você quer dar a essa regra. Esse nome precisa ser exclusivo no recurso de automação.
[WAIT_TIME]
É o tempo, em minutos, que você precisa esperar depois que a versão estiver pronta para ser promovida. Por exemplo,
1m
Om
é 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 para promover.Também pode ser
@next
, que promove o lançamento automaticamente para o próximo depois da especificada na propriedadeselector.targets
desta configuração de automação. Esse é o padrão se você omitir o valor dedestinationTargetId
.[TO_PHASE]
É o nome da fase que você quer promover, por exemplo,
canary-25
. oustable
. Essa propriedade é opcional. se você omiti-lo, o lançamento promovido para a primeira fase no destino.
Configurar uma regra de automação advanceRolloutRule
O advanceRolloutRule
avança o lançamento automaticamente após a conclusão
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 avance a fase automaticamente para stable
após o término da fase 50%
.
Ao configurar uma automação advanceRolloutRule
, você identifica a fase para
avançar (o sourcePhase
).
rules:
- advanceRolloutRule:
name: "[RULE_NAME]"
sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
wait: [WAIT_TIME]
Em que:
[RULE_NAME]
É qualquer nome que você quer dar a essa regra. Esse nome precisa ser exclusivo no pipeline de entrega.
[WAIT_TIME]
É a quantidade de tempo, em minutos, de espera para avançar o lançamento após o e o lançamento está pronto. Por exemplo,
1m
Om
é 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 fases em que o lançamento é avançado automaticamente. Ou seja, quando qualquer uma das fases listadas for concluída, o lançamento será automaticamente avançado para a próxima fase.
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.
Como configurar uma regra de automação 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, essa regra poderá reverter automaticamente
o destino para a última versão com êxito.
Ao configurar uma automação repairRolloutRule
, é possível especificar quantas
tempos para tentar novamente o lançamento e o tempo de espera entre novas tentativas. Você também pode
configurar fases ou jobs específicos, ou ambos, para tentar novamente. Se houver uma nova tentativa
falhar, o lançamento falhará. Se alguma nova tentativa for bem-sucedida, a automação será interrompida, e a
lançamento seja bem-sucedido.
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, reversões ou ambos.
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ê quer dar a essa regra. Esse nome precisa ser exclusivo no pipeline de entrega.
[PHASES_TO_REPAIR]
É a fase ou as fases de lançamento para tentar novamente. Isso é opcional, e o padrão é todas as fases do lançamento.
[JOBS_TO_REPAIR]
São 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 para tentar novamente o lançamento antes de considerá-lo falhou.
[WAIT_TIME]
É o tempo de espera entre as tentativas. Por exemplo,
1m
para em um intervalo de um minuto. A unidade de tempo (m
, neste caso) é obrigatória.Se
mode
forlinear
, o intervalo será o mesmo para cada nova tentativa. Semode
forexponential
, o intervalo aumenta a cada vez. Consultemode
para mais description.)backoffMode
LINEAR
ouEXPONENTIAL
, indicando se é necessário aumentar o tempo entre aposentados. Se forLINEAR
, o tempo entre novas tentativas será constante, emWAIT_TIME
. Se forEXPONENTIAL
, o tempo entre novas tentativas será duplicado a cada em uma nova tentativa sucessiva. O padrão éLINEAR
.Por exemplo, se
WAIT_TIME
for 1 minuto ebackoffMode
for definido comoEXPONENTIAL
, o tempo entre a falha e a primeira nova tentativa será de 1 minuto, o tempo entre a primeira e a segunda será de 2 minutos, e o tempo entre a segunda e a terceira será de 4 minutos.rollback
Opcional: reverter ou não o lançamento com falha depois que todas as tentativas de repetição forem esgotadas.
[PHASE_NAME]
É o nome de uma fase específica para a qual você quer reverter. Se você omitir
toPhase
, a reversão vai usar a fasestable
por padrão.
Interromper uma execução de automação repairRolloutRule
Se você executar qualquer um dos comandos a seguir no lançamento, a
automatização repairRolloutRule
será interrompida:
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á refeito até três vezes, com um minuto de espera entre as tentativas. Se todos novas tentativas falharem, uma reversão será iniciada criando um novo lançamento para implantar a versão bem-sucedida mais recente do destino para esse destino.
A seguir
Confira o guia de início rápido: automatizar a criação de versões e o avanço do lançamento.
Saiba mais sobre a automação de implantação no Cloud Deploy.