O arquivo ou os arquivos de configuração do Cloud Deploy definem o pipeline de entrega, os destinos para implantação e a progressão desses destinos.
O arquivo de configuração do pipeline de entrega pode incluir
definições de destino, esses itens podem estar em um arquivo separado ou
. Por convenção, um arquivo contendo a configuração do pipeline de entrega e
a configuração de destino é chamada de clouddeploy.yaml
, e uma configuração de pipeline sem
destino é chamado delivery-pipeline.yaml
. Mas você pode atribuir a esses arquivos
com o nome que quiser. Outras definições de recursos, como automações e políticas de implantação, também podem estar no mesmo arquivo que um pipeline de entrega ou uma definição de destino.
O que vai para onde
O Cloud Deploy usa dois arquivos de configuração principais:
- Definição do pipeline de entrega
- Definição do objetivo
Eles podem ser arquivos separados ou o pipeline de entrega e os destinos podem ser configurados no mesmo arquivo.
Estrutura de um arquivo de configuração de pipeline de entrega
A configuração a seguir inclui uma definição de destino:
# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
name:
annotations:
labels:
description:
suspended:
serialPipeline:
stages:
- targetId:
profiles: []
# Deployment strategies
# One of:
# standard:
# canary:
# See the strategy section in this document for details.
strategy:
standard:
verify:
predeploy:
actions: []
postdeploy:
actions: []
deployParameters:
- values:
matchTargetLabels:
- targetId:
profiles: []
strategy:
deployParameters:
---
# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
annotations:
labels:
description:
multiTarget:
targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
cluster:
internalIp:
proxyUrl:
#
# or:
anthosCluster:
membership:
#
# or:
run:
location:
#
# or:
customTarget:
customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
- [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
---
# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
name:
annotations:
labels:
description:
customActions:
renderAction:
deployAction:
includeSkaffoldModules:
- configs:
# either:
googleCloudStorage:
source:
path:
# or:
git:
repo:
path:
ref:
---
# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
name:
labels:
annotations:
description:
suspended:
serviceAccount:
selector:
- target:
id:
# or
labels:
rules:
- [RULE_TYPE]:
name:
[RULE-SPECIFIC_CONFIG]
Esse YAML tem três componentes principais:
O principal pipeline de entrega e a progressão
O arquivo de configuração pode incluir qualquer número de definições de canal.
As definições de destino
Para simplificar, apenas um destino é mostrado neste exemplo, mas pode haver qualquer um deles. Além disso, os destinos podem ser definidos em um ou mais arquivos.
Definições de tipo de segmentação personalizada
Segmentações personalizadas: exigem uma definição de tipo de segmentação personalizada. Assim como as segmentações e automações, os tipos de segmentações personalizadas podem ser definidos no mesmo arquivo que o pipeline de entrega ou em um arquivo separado.
Definições de automação
É possível criar automações de implantação no mesmo arquivo que o pipeline de entrega e os destinos ou em um ou mais arquivos separados. Para simplificar, apenas um
Automation
é mostrado aqui, mas é possível criar como quantos quiser.
Esses componentes são definidos no restante deste documento.
Definição e progressão do pipeline
Além dos metadados do pipeline, como name
, a principal definição do pipeline
inclui uma lista de referências a destinos em
ordem de sequência de implantação. Ou seja, o primeiro destino listado é o primeiro destino de implantação. Depois de implantar nesse destino, a promoção da versão
é implantada no próximo destino da lista.
Confira a seguir as propriedades de configuração de um pipeline de entrega, sem incluir definições de destino.
metadata.name
O campo name
usa uma string que precisa ser exclusiva por projeto e local.
metadata.annotations
e metadata.labels
A configuração do pipeline de entrega pode incluir anotações e rótulos. As anotações e os rótulos são armazenados com o recurso de pipeline de entrega depois que o pipeline é registrado.
Para mais informações, consulte Como usar rótulos e anotações com o Cloud Deploy.
description
Uma string arbitrária descrevendo esse pipeline de entrega. Esta descrição é mostrada nos detalhes do pipeline de entrega no console do Google Cloud.
suspended
Um booleano, que, se true
, suspenderá o pipeline de entrega.
de modo que elas não possam ser usadas para criar, promover, reverter ou reimplantar versões.
Além disso, se o pipeline de envio estiver suspenso, não será possível aprovar ou rejeitar um lançamento criado com esse pipeline.
O padrão é false
.
serialPipeline
O início da definição de um pipeline de entrega de progressão serial. Esta estrofe é obrigatória.
stages
Uma lista de todos os destinos em que esse pipeline de entrega está configurado para implantação.
A lista precisa estar na ordem em que a sequência de exibição você quer. Por exemplo, se você tiver destinos chamados dev
, staging
e production
, liste-os na mesma ordem, de modo que a primeira implantação seja dev
; sua implantação final
será em production
.
Preencha cada campo stages.targetId
com o valor do campo metadata.name
na definição de destino correspondente. E em targetId
, inclua
profiles
:
serialPipeline:
stages:
- targetId:
profiles: []
strategy:
standard:
verify:
targetId
Identifica o destino específico a ser usado neste estágio do pipeline de entrega.
O valor é a propriedade metadata.name
da definição de destino.
strategy.standard.verify
definido como true
ativa a
verificação de implantação no destino. Se nenhuma estratégia de implantação for especificada, a estratégia de implantação standard
será usada, com a verificação definida como false
.
profiles
Usa uma lista de zero ou mais nomes de perfil do Skaffold do skaffold.yaml
.
O Cloud Deploy usa o perfil com skaffold render
ao criar a versão. Os perfis do Skaffold permitem que você varie a configuração entre
os destinos ao usar um único arquivo de configuração.
strategy
Inclui propriedades para especificar uma estratégia de implantação. O seguinte têm suporte:
standard:
O aplicativo é totalmente implantado no destino especificado.
Essa é a estratégia de implantação padrão. Se você omitir
strategy
, o Cloud Deploy vai usar a estratégia de implantaçãostandard
.canary:
Em uma implantação canário, você implantar uma nova versão do aplicativo progressivamente, substituindo versão em execução por incrementos baseados em porcentagem (por exemplo, 25%, depois 50%, depois 75% e então totalmente.)
A estratégia de implantação é definida por destino. Por exemplo, você pode ter um
estratégia canário para sua meta de prod
, mas uma estratégia padrão (sem strategy
)
especificada) para seus outros destinos.
Para mais informações, consulte Usar uma estratégia de implantação.
Configuração strategy
Esta seção mostra os elementos de configuração de strategy
, para cada
no ambiente de execução.
Estratégia de implantação padrão
A estratégia padrão inclui apenas os seguintes elementos:
strategy:
standard:
verify: true|false
A propriedade verify
é opcional. O padrão é false
, o que significa que não haverá
fase de verificação para os lançamentos resultantes.
É possível omitir o elemento strategy
para uma classe standard.
estratégia de implantação.
Estratégia de implantação canário
As seções a seguir descrevem a configuração de um de implantação canário para cada ambiente de execução com suporte do Cloud Deploy.
Para destinos do Cloud Run
strategy:
canary:
runtimeConfig:
cloudRun:
automaticTrafficControl: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
Para destinos do GKE e GKE Enterprise
O YAML a seguir mostra como configurar uma estratégia de implantação para um GKE ou GKE Enterprise, usando rede baseada em serviço:
canary:
runtimeConfig:
kubernetes:
serviceNetworking:
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
disablePodOverprovisioning: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
O YAML a seguir mostra como configurar uma estratégia de implantação para um destino do GKE ou do GKE Enterprise usando a API Gateway:
canary:
runtimeConfig:
kubernetes:
gatewayServiceMesh:
httpRoute: "HTTP_ROUTE_NAME"
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
routeUpdateWaitTime: "WAIT_TIME"
canaryDeployment:
percentages: ["PERCENTAGES"]
verify: true | false
Observe neste exemplo
routeUpdateWaitTime
. Isso
está incluído porque a API Gateway divide o tráfego usando um recurso HTTPRoute
.
e, às vezes, há um atraso na propagação das mudanças feitas no HTTPRoute
. Nesses casos, as solicitações podem ser descartadas porque o tráfego está sendo enviado para recursos indisponíveis. Você pode usar routeUpdateWaitTime
para causar
O Cloud Deploy deve aguardar após a aplicação de HTTPRoute
alterações, se você
observar esse atraso.
O YAML a seguir mostra como configurar uma estratégia de implantação canário personalizada
ou personalizada-automatizada. Configuração específica do ambiente de execução, no arquivo
runtimeConfig
, foi omitida para o canário personalizado, mas foi incluída na
configuração canário automatizada e personalizada.
strategy:
canary:
# Runtime configs are configured as shown in the
# Canary Deployment Strategy section of this document.
runtimeConfig:
# Manual configuration for each canary phase
customCanaryDeployment:
- name: "PHASE1_NAME"
percent: PERCENTAGE1
profiles: [ "PROFILE1_NAME" ]
verify: true | false
- …
- name: "stable"
percent: 100
profiles: [ "LAST_PROFILE_NAME" ]
verify: true|false
verify
Booleano opcional que indica se é ou não compatível com a verificação de implantação
para esse destino. O padrão é false
.
Ativar a verificação de implantação também requer uma stanza verify
no skaffold.yaml
. Se você não fornecer essa propriedade, o job de verificação
falhar.
deployParameters
Permite especificar pares de chave-valor para transmitir valores a manifestos de alvos com correspondência de rótulo ao usar parâmetros de implantação.
Também é possível incluir isso nas segmentações.
Implante parâmetros definidos em um pipeline de entrega usando rótulos para corresponder aos destinos:
deployParameters:
- values:
someKey: "value1"
matchTargetLabels:
label1: firstLabel
- values:
someKey: "value2"
matchTargetLabels:
label2: secondLabel
Neste exemplo, há dois valores fornecidos para a chave e, para cada valor, há um rótulo. O valor é aplicado ao manifesto para qualquer destino que tenha um rótulo correspondente.
Jobs predeploy
e postdeploy
Elas permitem que você faça referência a ações personalizadas
(definidos separadamente, no
skaffold.yaml
) para executar antes do job de implantação (predeploy
) e depois da
vaga, se presente (postdeploy
). Se não houver um job de verificação, o job de pós-implantação
é executado após o job de implantação.
Os hooks de implantação são configurados em strategy.standard
ou
strategy.canary
da seguinte maneira:
serialPipeline:
stages:
- targetId:
strategy:
standard:
predeploy:
actions: [ACTION_NAME]
postdeploy:
actions: [ACTION_NAME]
Em que ACTION_NAME é o nome configurado em skaffold.yaml
para
customActions.name
.
É possível configurar trabalhos predeploy
e postdeploy
em qualquer estratégia
(standard
, canary
, por exemplo).
Para mais informações sobre como configurar e usar hooks de pré e pós-implantação, consulte Executar ganchos antes e depois da implantação.
Definições de destino
O arquivo de definição do pipeline de entrega pode conter definições de destino ou é possível especificar destinos em um arquivo separado. É possível repetir nomes de destino em um projeto, mas eles precisam ser exclusivos em um pipeline de entrega.
É possível reutilizar destinos entre vários pipelines de entrega. No entanto, só é possível referenciar um destino uma vez a partir da progressão de um único pipeline de entrega.
Consulte também: Definições de tipo de segmentação personalizada
Para destinos do GKE
O YAML a seguir mostra como configurar um destino que implantações em um cluster do GKE:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
annotations:
labels:
description:
deployParameters:
multiTarget:
targetIds: []
requireApproval:
gke:
cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
internalIp:
proxyUrl:
executionConfigs:
- usages:
- [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
verbose:
metadata.name
O nome dessa segmentação. Esse nome precisa ser globalmente exclusivo.
metadata.annotations
e metadata.labels
A configuração de destino oferece suporte a anotações do Kubernetes e rótulos, mas o Cloud Deploy não os exige.
Anotações e rótulos são armazenados com o recurso de destino. Para mais informações, consulte Como usar rótulos e anotações com o Cloud Deploy.
description
Esse campo usa uma string arbitrária que descreve o uso desse destino.
deployParameters
É possível incluir parâmetros de implantação em qualquer destino, junto com valores. Esses valores são atribuídos às chaves correspondentes no manifesto, após a renderização.
A estrofe deployParameters
usa pares de chave-valor, conforme mostrado:
deployParameters:
someKey: "someValue"
someOtherKey: "someOtherValue"
Se você definir parâmetros de implantação em um destinos múltiplos, o valor é atribuído à o manifesto para todos os destinos filhos.
multiTarget.targetIds: []
Esta propriedade é opcional e é usada para configurar um destinos múltiplos a serem usados para implantação paralela.
O valor é uma lista separada por vírgulas de destinos filhos.
Os destinos filhos são configurados como destinos normais e não incluem esse
multiTarget
.
requireApproval
Indica se a promoção para esta meta requer aprovação manual. Pode ser true
ou false
.
Esta propriedade é opcional. O padrão é false
.
Ao configurar a implantação paralela, você pode exigir aprovação somente em destinos múltiplos, não em destinos filhos.
gke
Para clusters do GKE, o caminho do recurso que identifica o cluster em que o aplicativo será implantado:
gke:
cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
project_name
O projeto do Google Cloud em que o cluster reside.
location
O local em que o cluster reside. Por exemplo,
us-central1
O cluster também pode ser zonal (us-central1-c
).cluster_name
O nome do cluster, como aparece na lista de clusters em console do Google Cloud.
Veja um exemplo:
gke:
cluster: projects/cd-demo-01/locations/us-central1/clusters/prod
Omita a propriedade gke
ao configurar um vários alvos.
O cluster do GKE é configurado dentro do cluster
destino filho.
Consulte executionConfigs
, neste artigo, para descrições
das propriedades do ambiente de execução.
internalIp
Indica se o cluster do GKE especificado usa ou não um endereço IP
particular. Esta propriedade é opcional. Por padrão, o Cloud Deploy usa
o endereço IP disponível publicamente para o cluster. Se houver um endereço IP
particular e você quiser usá-lo, defina-o como true
.
proxyUrl
Se você acessar clusters por um proxy, forneça a propriedade proxyUrl
aqui. O valor é o URL do cluster do GKE
de proxy, que é
transmitido para o kubectl
ao se conectar ao cluster.
Para destinos do Cloud Run
O YAML a seguir mostra como configurar um destino que implantadas em um serviço do Cloud Run:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
annotations:
labels:
description:
multiTarget:
targetIds: []
requireApproval:
run:
location: projects/[project_name]/locations/[location]
executionConfigs:
- usages:
- [RENDER | PREDEPLOY| DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
verbose:
metadata.name
O nome dessa segmentação. Esse nome precisa ser exclusivo por região.
metadata.annotations
e metadata.labels
A configuração de destino oferece suporte a anotações e rótulos, mas o Cloud Deploy não os exige.
Anotações e rótulos são armazenados com o recurso de destino. Para mais informações, consulte Como usar rótulos e anotações com o Cloud Deploy.
description
Esse campo usa uma string arbitrária que descreve o uso desse destino.
multiTarget.targetIds: []
Esta propriedade é opcional e é usada para configurar um destinos múltiplos a serem usados para implantação paralela.
O valor é uma lista separada por vírgulas de destinos filhos.
As segmentações filhas são configuradas como segmentações normais e não incluem essa
propriedade multiTarget
.
requireApproval
Indica se a promoção para esta meta requer aprovação manual. Pode ser true
ou false
.
Esta propriedade é opcional. O padrão é false
.
Ao configurar a implantação paralela, é possível exigir aprovação apenas no destino múltiplo, e não nos destinos filhos.
run
Para serviços do Cloud Run, o local em que o serviço será criado:
run:
location: projects/[project_name]/locations/[location]
project_name
O projeto do Google Cloud em que o serviço vai ficar.
location
O local em que o serviço vai ser hospedado. Por exemplo,
us-central1
A propriedade run
foi omitida ao configurar um [multi-target]. O local do
serviço do Cloud Run é configurado dentro da
meta filha correspondente.
Consulte executionConfigs
, neste artigo, para descrições
das propriedades do ambiente de execução.
Para destinos do GKE Enterprise
Configuração de destino para
A implantação em um cluster do GKE é semelhante à
configurar um destino para um destino do GKE;
exceto que a propriedade é anthosCluster.membership
, em vez de gke.cluster
,
o caminho do recurso é diferente e internalIp
não é aplicável.
anthosCluster:
membership: projects/[project_name]/locations/global/memberships/[membership_name]
project_name
O projeto do Google Cloud em que o cluster do GKE Enterprise fica.
/location/global/
O local em que o cluster está registrado.
global
, em todos os casos.membership_name
O nome da associação ao cluster do GKE Enterprise.
Veja um exemplo:
anthosCluster:
membership: projects/cd-demo-01/locations/global/memberships/prod
A propriedade anthosCluster
foi omitida ao configurar um [multi-target]. O
o cluster do GKE Enterprise é configurado
destino filho.
Para mais informações sobre implantações em clusters do GKE, consulte Como implantar em clusters de usuários do Anthos.
Para segmentações personalizadas
A configuração para destinos personalizados é semelhante a
todos os outros tipos de destino, exceto que não inclui uma estrofe gke
, uma
run
ou uma anthosCluster
.
Em vez disso, os destinos personalizados incluem uma estrofe de customTarget
:
customTarget:
customTargetType: [CUSTOM_TARGET_TYPE_NAME]
Em que CUSTOM_TARGET_TYPE_NAME
é o nome que você usou no
definição de tipo de segmentação personalizada.
Veja um exemplo:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: sample-env
customTarget:
customTargetType: basic-custom-target
executionConfigs
Um conjunto de campos para especificar um ambiente de execução não padrão para esse destino.
usages
RENDER
ouDEPLOY
ou ambos, além dePREDEPLOY
,VERIFY
ouPOSTDEPLOY
, se a verificação ou os hooks de implantação estiverem ativados no destino. Eles indicam quais operações devem ser performance para essa meta usando essa ou ambiente de execução. Para indicar que um ambiente de execução personalizado ser usado para hooks de pré-implantação, renderização, implantação, hooks de pós-implantação e verificação, configure-o da seguinte maneira:usages: - RENDER - PREDEPLOY - DEPLOY - VERIFY - POSTDEPLOY
Se a verificação estiver ativada no estágio do pipeline, e você não especificar
VERIFY
em uma estrofeusages
, o Cloud Deploy usa o ambiente de execução padrão para verificação. Os hooks de pré-implantação e pós-implantação funcionam da mesma forma.No entanto, se houver um ambiente de execução personalizado para
RENDER
eDEPLOY
, você deve especificar um paraVERIFY
,PREDEPLOY
, OUPOSTDEPLOY
se eles forem configurados no pipeline de entrega.VERIFY
,PREDEPLOY
ePOSTDEPLOY
pode estar no mesmousages
queRENDER
ouDEPLOY
ou emusages
separado.Não é possível especificar
usages.VERIFY
,usages.PREDEPLOY
ouusages.POSTDEPLOY
a menos queRENDER
eDEPLOY
sejam especificados na mesma regra ambientes de execução.workerPool
Configuração a ser usada pelo pool de workers. Isso usa um caminho de recurso que identifica o pool de workers do Cloud Build a ser usado para este destino. Exemplo:
projects/p123/locations/us-central1/workerPools/wp123
Para usar o pool padrão do Cloud Build, omita essa propriedade.
Um determinado destino pode ter dois
workerPool
s (um paraRENDER
e outro paraDEPLOY
). Ao configurar o pool padrão, você pode especificar uma conta de serviço alternativa ou um local de armazenamento ou ambos.serviceAccount
O nome da conta de serviço a ser usada nesta operação (
RENDER
ouDEPLOY
) para este destino.artifactStorage
O bucket do Cloud Storage a ser usado para essa operação (
RENDER
ouDEPLOY
) para este destino, em vez do bucket padrão.executionTimeout
Opcional. Define o tempo limite, em segundos, para operações que o Cloud Build executa para o Cloud Deploy. Por padrão, esse tempo é de
3600
segundos (1 hora).
Exemplo:executionTimeout: "5000s"
verbose
Opcional. Se for
true
, os níveis de detalhes serão definidos comodebug
para os seguintes ferramentas:O Skaffold
--verbosity
está definido comodebug
. O padrão do Skaffold éwarn
.kubectl
--v
é definido como4
, que é depuração. O padrão do kubectl é2
.A Google Cloud CLI
--verbosity
está definida paradebug
. O padrão éwarning
.
Sintaxe alternativa compatível
A configuração executionConfigs
descrita neste documento é nova. A
sintaxe anterior ainda é compatível:
executionConfigs:
- privatePool:
workerPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
- defaultPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
Ao configurar uma stanza executionConfigs
para um
destino múltiplo, cada destino filho
pode herdar esse ambiente de execução
desse destino múltiplo.
Definições de tipo de segmentação personalizada
Esta seção descreve os campos usados para definir tipos de destino personalizados.
Assim como nas metas e automações padrão, as definições de CustomTargetType
podem ser
incluído na definição do pipeline de entrega ou em um ou mais arquivos separados.
O YAML a seguir mostra como configurar um tipo de destino personalizado:
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
name: [CUSTOM_TARGET_TYPE_NAME]
annotations:
labels:
description:
customActions:
renderAction: [RENDER_ACTION_NAME]
deployAction: [DEPLOY_ACTION_NAME]
includeSkaffoldModules:
- configs:
# either:
googleCloudStorage:
source:
path:
# or:
git:
repo:
path:
ref:
Em que:
[CUSTOM_TARGET_TYPE_NAME]
É um nome arbitrário que você atribui a essa definição de tipo de destino personalizado. Esse nome é referenciado na definição de destino para qualquer destino que use o tipo de destino personalizado que você está definindo.
[RENDER_ACTION_NAME]
É o nome da ação de renderização personalizada. Esse valor é o
customAction.name
definido emskaffold.yaml
.[DEPLOY_ACTION_NAME]
É o nome da ação de implantação personalizada. Esse valor é o
customAction.name
definido emskaffold.yaml
.Para
includeSkaffoldModules
, consulte Usar configurações remotas do Skaffold.
Definições de Automation
Nesta seção, descrevemos os campos usados para definir o Cloud Deploy recursos de automation.
Assim como os destinos, as definições de Automation
podem ser incluídas na definição do pipeline de entrega ou em um ou mais arquivos separados.
Para mais informações sobre automação no Cloud Deploy, consulte a documentação sobre automação.
O YAML a seguir mostra como configurar uma automação. Os detalhes de uma regra de automação são diferentes para cada regra. A configuração do tipos de regras de automação está no documento Usar regras de automação.
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
name: [PIPELINE_NAME]/[PURPOSE]
labels:
annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
targets:
- id: [TARGET_ID]
labels:
[LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]:
name:[RULE_NAME]
[RULE-SPECIFIC_CONFIG]
Em que:
[PIPELINE_NAME]
É o mesmo que o valor
metadata.name
no pipeline de entrega que usa essa automação. Todas as automações são exclusivas dos pipelines de entrega em que são criadas. Ou seja, não é possível compartilhar uma automação de um pipeline de entrega.[PURPOSE]
É um nome descritivo para essa automação. Normalmente, essa é a ação automatizada. Por exemplo,
my-app-pipeline/promote
labels
eannotations
são os rótulos ou anotações que você quer associar a essa automação.[DESCRIPTION]
É uma descrição opcional para essa automação.
suspended
true
oufalse
, indicando se a automação está ativa ou suspensa. Se definido comotrue
, a automação não vai ser usada. Isso pode ser útil para testar uma automação sem afetar o pipeline de entrega.[SERVICE_ACCOUNT_ID]
É o ID da conta de serviço usada para executar automação. Por exemplo, se a automação usar
promoteReleaseRule
, esse conta de serviço realiza a promoção de lançamento e, portanto, exige que o permissões necessárias para promover um lançamento.Um valor é necessário para essa propriedade. O Cloud Deploy não usa a conta de serviço padrão para automações.
Essa conta de serviço precisa ter as seguintes permissões:
actAs
para representar a conta de serviço de execução.permissão para realizar a operação que está sendo automatizada. Por exemplo,
clouddeploy.releases.promote
para promover uma versão ouclouddeploy.rollouts.advance
para avançar uma fase de lançamento.
[TARGET_ID]
É o ID do destino em que essa automação é usada. Embora uma automação esteja vinculada a um pipeline de entrega, ela só é executada nos destinos específicos.
É possível definir esse valor como
*
para selecionar todos os destinos no pipeline de entrega.[LABEL_KEY]:[LABEL_VALUE]
É um par de chave-valor que corresponde a um par de chave-valor definido no destino. Isso seleciona todos os destinos associados ao pipeline de entrega que têm o mesmo rótulo e valor.
[RULE_TYPE]
É o nome da regra de automação usada para essa automação. Isso significa
promoteReleaseRule
ouadvanceRolloutRule
. É possível incluir mais de uma regra em uma automação, incluindo mais de umaRULE_TYPE
. Para é possível ter mais de uma regrapromoteReleaseRule
na mesma automação. Saiba mais.[RULE_NAME]
Um nome para a regra. Esse nome precisa ser exclusivo no pipeline de entrega. É necessário um valor para essa propriedade.
[RULE-SPECIFIC_CONFIG]
A configuração é diferente para cada tipo de automação compatível. Essas configurações são mostradas em Como usar regras de automação.
Implantar definições de políticas (pré-lançamento)
Esta seção descreve os campos usados para definir políticas de implantação.
Assim como em outros recursos do Cloud Deploy, é possível incluir definições de DeployPolicy
com a definição do pipeline de entrega ou em um arquivo separado.
O YAML a seguir mostra como configurar uma política de implantação:
apiVersion: deploy.cloud.google.com/v1
kind: DeployPolicy
metadata:
name: [POLICY_NAME]
annotations: [ANNOTATIONS]
labels: [LABELS]
description: [DESCRIPTION]
suspended: [true | false]
selectors:
- deliveryPipeline:
id: [PIPELINE_ID]
labels:
[LABEL_KEY]:[LABEL_VALUE]
target:
id: [TARGET_ID]
labels:
[LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]
[CONFIGS]
Em que:
[DESCRIPTION]
É um texto opcional que descreve a política.
[POLICY_NAME]
Um nome para a política. Esse campo usa uma string que deve ser exclusiva por o projeto e o local. Ele precisa ter letras minúsculas, números e hifens, com o primeiro caractere uma letra, o último caractere uma letra ou um número, e um máximo de 63 caracteres. Esse nome é usado como nome de exibição no console do Google Cloud.
[ANNOTATIONS]
e[LABELS]
As políticas podem incluir anotações e rótulos, que fazem parte do recurso de política depois que ele é criado. Para mais informações, consulte Como usar anotações e rótulos com o Cloud Deploy.
suspended: [true | false]
Definir
suspended
comotrue
desativa esta política.[PIPELINE_ID]
É o ID do pipeline de entrega que você quer que essa política afete. Você pode usar
*
para indicar todos os pipelines. Esse ID é o mesmo que a propriedademetadata.name
no pipeline de entrega.[TARGET_ID]
É o ID do destino que você quer que essa política afete. Você pode usar
*
para para indicar todos os destinos. Esse ID é o mesmo da propriedademetadata.name
no destino.[LABEL_KEY]:[LABEL_VALUE]
É um par de chave-valor que corresponde a um par de chave-valor definido no arquivo pipeline ou destino. Isso seleciona todos os pipelines ou destinos que têm o mesmo rótulo e valor. É possível especificar
labels
em vez ou além deid
.[RULE_TYPE]
É o tipo de regra de política específico que você está configurando. O único valor válido é
rolloutRestriction
.[CONFIGS]
É o conjunto de propriedades de configuração da regra de política específica que você está criando. A configuração das regras está descrita mais adiante nesta seção desta referência, para cada um as regras disponíveis.
Implantar regras de políticas
Esta seção descreve como configurar cada regra de política de implantação.
rolloutRestriction
A regra rolloutRestriction
impede que o Cloud Deploy execute
certas operações em lançamentos durante o
janela de tempo ou janelas especificadas, para os pipelines e destinos de entrega
indicado pelo selectors
para a política de implantação.
O YAML a seguir mostra como configurar uma regra rolloutRestriction
:
rules:
- rolloutRestriction:
id: [RULE_ID]
actions:
- [ACTIONS]
invokers:
- [INVOKERS]
timeWindows:
timeZone: [TIMEZONE]
oneTimeWindows:
- start: [START_DATE_TIME]
end: [END_DATE_TIME]
weeklyWindows:
- daysOfWeek:
- [DAY_OF_WEEK]
- [DAY_OF_WEEK]
startTime: [START_TIME]
endTime: [END_TIME]
Em que:
RULE_ID
Um identificador para esta regra. Obrigatório. Ele precisa consistir de letras minúsculas, números e hifens, com o primeiro caractere sendo uma letra, o último caractere sendo uma letra ou um número e um máximo de 63 caracteres. Ele precisa ser exclusivo na política de implantação.
ACTIONS
Opcional: ações de lançamento a serem restritas como parte da política. Se estiver vazio, todas as ações serão restritas. Os valores válidos são:
ADVANCE
As fases de lançamento não podem ser avançado.
APPROVE
Não é possível aprovar a promoção de lançamento.
CANCEL
Os lançamentos não podem ser cancelados.
CREATE
Não é possível criar lançamentos.
IGNORE_JOB
Os jobs não podem ser ignorados.
RETRY_JOB
Os jobs não podem ser retentativas.
ROLLBACK
Os lançamentos não podem ser revertidos.
TERMINATE_JOBRUN
As execuções de jobs não podem ser encerradas
INVOKERS
A especificação dos invocadores filtra a aplicação da política dependendo se o a ação restrita foi invocada por um usuário ou por uma automação de implantação. Válida são:
USER
A ação é conduzida pelo usuário. Por exemplo, criar um lançamento manualmente usando um comando da CLI gcloud.
DEPLOY_AUTOMATION
Uma ação automatizada pelo Cloud Deploy.
Você pode especificar um ou ambos os valores. O padrão, se você não especificar nada, é os dois.
TIMEZONE
O fuso horário, no formato IANA, em que você está expressando a janela de tempo. Por exemplo,
America/New_York
. Obrigatório.START_DATE_TIME
Para
oneTimeWindows
, a data e a hora que marcam o início da janela de restrição de acesso, no formato"yyyy-mm-dd hh:mm"
. Para o início do dia, use00:00
. Este campo é obrigatório.END_DATE_TIME
Para
oneTimeWindows
, a data e a hora que marcam o fim da restrição no formato"yyyy-mm-dd hh:mm"
. Para o fim do dia, use24:00
. Este campo é obrigatório.DAY_OF_WEEK
Para
weeklyWindows
, o dia da semana,SUNDAY
,MONDAY
,TUESDAY
,WEDNESDAY
,THURSDAY
,FRIDAY
ouSATURDAY
. Se você deixar esse campo em branco, corresponde a todos os dias da semanaSTART_TIME
Para
weeklyWindows
, o horário de início no dia da semana especificado. Se você incluir uma hora de início, você deve incluir uma hora de término. Para o início do dia, use00:00
.END_TIME
Para
weeklyWindows
, é o horário de término no dia da semana especificado. Se você incluir uma hora de início, você deve incluir uma hora de término. Para o fim do dia, use24:00
.
A seguir
Saiba mais sobre como o Cloud Deploy funciona.
Saiba como configurar um pipeline de entrega para o aplicativo.
Saiba como gerenciar seus manifestos.
Evite incompatibilidades entre a versão e o pipeline de entrega aprendendo sobre instâncias de pipeline.