Referência do esquema de configuração

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 ou pode estar em um ou mais arquivos separados. Por convenção, um arquivo que contém a configuração do pipeline de entrega e as configurações de destino é chamado clouddeploy.yaml, e uma configuração de pipeline sem destinos é chamada delivery-pipeline.yaml. Mas você pode dar a esses arquivos 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:

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:
  verbose:
---

# 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 nas segmentações e automações, os tipos de segmentação personalizada podem ser definidos no mesmo arquivo que o pipeline de entrega ou em um arquivo separado.

  • Definições de Automation

    É possível criar automatizações de implantação no mesmo arquivo que o pipeline de entrega e os destinos ou em um ou mais arquivos separados. Para simplificar, mostramos apenas um Automation aqui, mas você pode criar 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 definição do pipeline principal inclui uma lista de referências a destinos na ordem da 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, vai 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 entrega estiver suspenso, não será possível aprovar ou rejeitar uma um lançamento criado a partir desse pipeline.

O padrão é false.

serialPipeline

O início da definição de um pipeline de entrega de progressão serial. Isso 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 verificação de implantação no destino. Em caso negativo a estratégia de implantação for especificada, a estratégia 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. As seguintes estratégias são compatíveis:

  • standard:

    O aplicativo é implantado totalmente no destino especificado.

    Essa é a estratégia de implantação padrão. Se você omitir strategy, O Cloud Deploy usa a estratégia de implantação standard.

  • canary:

    Em uma implantação canário, você implanta uma nova versão do aplicativo progressivamente, substituindo a versão em execução por incrementos baseados em porcentagem (por exemplo, 25%, 50%, 75% e, em seguida, totalmente).

A estratégia de implantação é definida por meta. 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 ambiente de execução com suporte.

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, ou seja, haverá não haverá fase de verificação para os lançamentos resultantes.

Você pode omitir o elemento strategy para uma estratégia de implantação padrão.

Estratégia de implantação canário

As seções a seguir descrevem a configuração de uma estratégia de implantação canário para cada ambiente de execução compatível com o 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 do GKE Enterprise

O YAML a seguir mostra como configurar uma estratégia de implantação para um alvo do GKE ou do GKE Enterprise usando redes baseadas em serviços:

      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 GKE ou GKE Enterprise, usando 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 fazer com que o Cloud Deploy aguarde após a aplicação de mudanças de HTTPRoute, se observar esse atraso.

O YAML a seguir mostra como configurar um objeto personalizado ou automatizado de modo personalizado estratégia de implantação canário. A configuração específica do tempo de execução, na seção runtimeConfig, é omitida para o canário personalizado, mas incluída na configuração automática e personalizada do canário.

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.

Os parâmetros de implantação definidos em um pipeline de entrega usam rótulos para corresponder às metas:

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 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 jobs predeploy e postdeploy em qualquer estratégia. (standard, canary, por exemplo).

Para mais informações sobre como configurar e usar ganchos antes e depois da 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 precisa deles.

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 dos valores. Esses valores são atribuídos às chaves correspondentes na sua manifesto do aplicativo, 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: []

Essa propriedade é opcional e é usada para configurar um multi-target para ser usado na 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 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, 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 uma segmentação múltipla. Em vez disso, o cluster do GKE é configurado destino filho.

Consulte executionConfigs, neste artigo, para descrições das propriedades do ambiente de execução.

internalIp

Se o cluster do GKE especificado usa ou não um o endereço IP público. Esta propriedade é opcional. Por padrão, o Cloud Deploy usa o endereço IP disponível publicamente para o cluster. Se houver um IP privado 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. Os destinos filhos são configurados como destinos 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 ser hospedado.

  • location

    O local onde o serviço vai ficar. Por exemplo, us-central1

Omita a propriedade run ao configurar um [destinos múltiplos]. A localização do serviço do Cloud Run é configurado em vez destino filho correspondente.

Consulte executionConfigs, neste artigo, para descrições das propriedades do ambiente de execução.

Para destinos do GKE Enterprise

A configuração de destino para implantação em um cluster do GKE é semelhante a 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 reside.

  • /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

Omita a propriedade anthosCluster ao configurar um [destinos múltiplos]. O cluster do GKE Enterprise é configurado dentro da metade filho correspondente.

Para mais informações sobre como implantar em clusters do GKE, consulte Como implantar em clusters de usuários do Anthos.

Para segmentações personalizadas

A configuração para segmentações personalizadas é semelhante à todos os outros tipos de segmentação, exceto que não inclui uma estrofe gke nem uma estrofe run, nem uma estrofe de anthosCluster.

Em vez disso, os destinos personalizados incluem uma estrofe 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 ou DEPLOY ou ambos, além de PREDEPLOY, VERIFY ou POSTDEPLOY, 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 estrofe usages, o Cloud Deploy vai usar o ambiente de execução padrão para a 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 e DEPLOY, é necessário especificar um para VERIFY, PREDEPLOY OU POSTDEPLOY, se eles estiverem configurados no pipeline de entrega.VERIFY, PREDEPLOY e POSTDEPLOY podem estar na mesma usages que RENDER ou DEPLOY, ou em usages separadas.

    Não é possível especificar usages.VERIFY, usages.PREDEPLOY ou usages.POSTDEPLOY a menos que RENDER e DEPLOY sejam especificados no mesmo ambiente de execução personalizado ou em ambientes separados.

  • workerPool

    Configuração para o pool de workers. Isso leva caminho de recurso que identifica o pool de workers do Cloud Build a ser usado para para esse 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 workerPools (um para RENDER e outro para DEPLOY). 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 para esta operação (RENDER ou DEPLOY) para esse destino.

  • artifactStorage

    O bucket do Cloud Storage a ser usado para essa operação (RENDER ou DEPLOY) para esse 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, isso leva 3600 segundos (1 hora).
    Exemplo: executionTimeout: "5000s"

  • verbose

    Opcional. Se true, os níveis de detalhamento são definidos como debug para as seguintes ferramentas:

Sintaxe alternativa compatível

A configuração do executionConfigs descrita neste documento é nova. O sintaxe anterior ainda é suportada:

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 as automações e destinos padrão, as definições de CustomTargetType podem ser incluídas na definição do pipeline de entrega ou em 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 em skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    É o nome da ação de implantação personalizada. Esse valor é o customAction.name definido em skaffold.yaml.

  • Para includeSkaffoldModules, consulte Usar configurações remotas do Skaffold.

Definições de automação

Esta seção descreve os campos usados para definir os recursos de automatização do Cloud Deploy.

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 a automação no Cloud Deploy, consulte a documentação de automação.

O YAML a seguir mostra como configurar uma automação. Observe que os detalhes de uma regra de automação são diferentes por 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 durante a criação deles. Ou seja, não é possível compartilhar uma automação em mais de um pipeline de entrega.

  • [PURPOSE]

    É um nome descritivo para essa automação. Normalmente, isso seria a ação que é automatizada. Por exemplo, my-app-pipeline/promote

  • labels e annotations são os rótulos ou anotações que você quer associar a essa automação.

  • [DESCRIPTION]

    É uma descrição opcional para esta automação.

  • suspended

    true ou false, indicando se essa automação está ativa ou suspensa. Se definido como true, 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 realizar a automação. Por exemplo, se a automação usar o promoteReleaseRule, essa conta de serviço vai realizar a promoção de lançamento e, portanto, vai exigir as permissões necessárias para promover um lançamento.

    É necessário um valor 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 que uma operação está sendo automatizada, por exemplo, clouddeploy.releases.promote para promover uma versão ou clouddeploy.rollouts.advance para avançar o lançamento fase de testes.

  • [TARGET_ID]

    É o ID do destino em que esta automação é usada. Embora um está vinculada a um pipeline de entrega, ela só é executada no destino.

    Defina 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, advanceRolloutRule ou repairRolloutRule. É possível incluir mais de uma regra em uma automação, incluindo mais de uma da mesma RULE_TYPE. Por exemplo, é possível ter mais de uma regra promoteReleaseRule na mesma automação. Saiba mais

  • [RULE_NAME]

    Um nome para a regra. Esse nome precisa ser exclusivo no pipeline de entrega. Um valor é necessário 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ítica (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 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 um 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 como true desativa esta política.

  • [PIPELINE_ID]

    É o ID do pipeline de entrega que você quer que esta política afete. É possível usar * para denotar todos os pipelines. Esse ID é igual ao metadata.name no pipeline de entrega.

  • [TARGET_ID]

    É o ID do destino que você quer que a política afete. Você pode usar * para para indicar todos os destinos. Esse ID é igual ao metadata.name no destino.

  • [LABEL_KEY]:[LABEL_VALUE]

    É um par de chave-valor que precisa ser correspondente a um par de chave-valor definido no pipeline de envio ou no destino. Isso seleciona todos os pipelines ou destinos que têm a mesma rótulo e valor. É possível especificar labels em vez ou além de id.

  • [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 para a regra de política específica que você está criar. 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ítica

Esta seção descreve como configurar cada regra de política de implantação.

rolloutRestriction

A regra rolloutRestriction impede que o Cloud Deploy realize certas operações em lançamentos durante a janela de tempo ou janelas especificadas, para os pipelines de entrega e os destinos indicados por 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. Precisa ser exclusivo na política de implantação.

  • ACTIONS

    Opcional: ações de lançamento a serem restringidas 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

      Não é possível cancelar os lançamentos.

    • CREATE

      Não é possível criar lançamentos.

    • IGNORE_JOB

      Os jobs não podem ser ignorados.

    • RETRY_JOB

      Não é possível fazer novas tentativas dos jobs.

    • 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 do Cloud Deploy.

    Você pode especificar um ou ambos os valores. O padrão, se você especificar nada, são os dois.

  • TIMEZONE

    O fuso horário, em 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 no dia, use 00:00. Este campo é obrigatório.

  • END_DATE_TIME

    Para oneTimeWindows, a data e a hora que marcam o fim do período de restrição, no formato "yyyy-mm-dd hh:mm". Para o fim do dia, use 24:00: Este campo é obrigatório.

  • DAY_OF_WEEK

    Para weeklyWindows, o dia da semana, SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY ou SATURDAY. Se você deixar esse campo em branco, ele vai corresponder a todos os dias da semana.

  • START_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 dia, use 00: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, use 24:00.

A seguir