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 arquivo ou arquivos separados. Por convenção, um arquivo que contém a configuração do pipeline de entrega e a configuração do 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:

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 seguir, confira a estrutura de uma configuração de pipeline de entrega, incluindo propriedades para definições de destino. Algumas propriedades de destino não estão incluídas aqui. Consulte Definições de destino para todas as propriedades de configuraçã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:
       predeploy:
         tasks: []
       verify:
         tasks: []
       analysis:
       postdeploy:
         tasks: []
   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:
 dnsEndpoint:
 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 | ANALYSIS]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
tasks:
  render:
  deploy:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]:
  id:
  [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 tipos de segmentações personalizadas

    Segmentações personalizadas exigem uma definição de tipo de segmentação personalizada. Assim como os destinos e as automações, os tipos de destino personalizados podem ser definidos no mesmo arquivo que o pipeline de entrega ou em um arquivo separado.

  • Definições de Automation

    É 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 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 será 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. Essa descrição é mostrada nos detalhes do pipeline de entrega no console Google Cloud .

suspended

Um booleano que, se true, suspende o pipeline de entrega para que não possa ser usado 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 um lançamento criado com base nele.

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 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 usará a estratégia de implantação standard.

  • canary:

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

A estratégia de implantação é definida por destino. Por exemplo, você pode ter uma estratégia de canário para sua meta prod, mas uma estratégia padrão (sem strategy especificado) para as outras metas.

Para mais informações, consulte Usar uma estratégia de implantação.

Configuração strategy

Esta seção mostra os elementos de configuração para strategy em cada ambiente de execução compatível.

Estratégia de implantação padrão

A estratégia padrão inclui apenas os seguintes elementos:

strategy:
  standard:
    verify:
      tasks: []
    analysis:

A propriedade verify permite referenciar uma ou mais tarefas a serem executadas para verificar sua implantação. Se configuradas, as tarefas de verificação serão executadas em sequência, imediatamente após o job "deploy".

A propriedade verify é opcional. Se não for especificado, não haverá um job de verificação nos rollouts resultantes.

A estância analysis é opcional e pode ser usada com a análise do Cloud Deploy.

É possível 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:
        tasks: []
      analysis:

Para destinos do Cloud Run, AutomaticTrafficControl precisa ser true, a menos que você esteja configurando um canário personalizado.

Para destinos de clusters anexados do GKE e do GKE

O YAML a seguir mostra como configurar uma estratégia de implantação para uma meta que implanta no GKE ou em clusters anexados do GKE, usando rede baseada em serviços:

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify:
            tasks: []

O YAML a seguir mostra como configurar uma estratégia de implantação para uma meta que implanta no GKE ou em clusters anexados do GKE usando a API Gateway:

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
              routeDestinations:
                destinationIds: ["KEY"]
                propagateService: [true|false]
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify:
            tasks: []

Observe neste exemplo routeUpdateWaitTime. Isso é 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 depois de aplicar as mudanças de HTTPRoute, se você observar esse atraso.

O YAML a seguir mostra como configurar uma estratégia de implantação canário personalizada (para rede de serviços, API de gateway ou Cloud Run) ou uma estratégia de implantação canário personalizada e automatizada (para rede de serviços, API de gateway ou Cloud Run). A configuração específica do ambiente de execução, na seção runtimeConfig, é omitida para o canary personalizado, mas incluída na configuração de canary automatizada e automatizada personalizada.

Configuração personalizada do Canary

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:
          tasks: []
      - …
      - name: "stable"
        percent: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        analysis: [ANALYSIS_CONFIGS]
        verify:
          tasks: []

verify

A estrofe verify pode ser incluída em strategy.standard, strategy.canary.canaryDeployment ou em cada fase de strategy.canary.customCanaryDeployment. Ele é usado para ativar a verificação de implantação de um destino. Essa parte é opcional. Se for omitida, nenhuma verificação será realizada para o lançamento ou a fase de teste canário.

É possível configurar o verify de duas maneiras:

  • Defina verify: true.

    Se fizer isso, você também precisará configurar uma seção verify no skaffold.yaml, conforme descrito em Configurar o Skaffold para verificação.

  • Configure o verify usando uma ou mais tarefas para execução na verificação:

    verify:
  tasks: [VERIFY_TASKS]

analysis

A análise de implantação, que pode ser usada para executar uma ou mais verificações em relação aos alertas do Google Cloud Observability, é configurada em uma seção strategy. Consulte Definições de análise para mais detalhes sobre a configuração.

deployParameters

Permite especificar pares de chave-valor para transmitir valores aos manifestos de destinos correspondentes por rótulo ao usar parâmetros de implantação.

Você também pode incluir isso em metas.

Os parâmetros de implantação definidos em um pipeline de entrega usam 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 de predeploy e postdeploy

Os hooks de pré-implantação e pós-implantação são jobs que são executados antes ou depois do job de implantação em um lançamento. É possível definir hooks de pré-implantação e pós-implantação de duas maneiras:

Os jobs de pré-implantação são executados imediatamente antes do job de implantação em um lançamento. Os jobs de pós-implantação são executados depois de todos os outros jobs no lançamento, incluindo verificação e análise, se aplicável.

Os hooks de implantação são configurados em strategy.standard ou strategy.canary da seguinte maneira:

  • Como usar o tasks

    serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          tasks: [PREDEPLOY_TASKS]
        postdeploy:
          tasks: [POSTDEPLOY_TASKS]

    Em que:

    • PREDEPLOY_TASKS são uma ou mais tarefas que você quer executar no hook de pré-implantação.

    • POSTDEPLOY_TASKS são uma ou mais tarefas que você quer executar no hook postdeploy.

  • Como usar o actions (e o Skaffold)

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

Para mais informações sobre como configurar e usar hooks pré e pós-implantação, consulte Executar hooks 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 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 uma meta que implanta 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]
      dnsEndpoint:
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           dnsEndpoint: [true|false]
           internalIp: [true|false]
           proxyUrl:

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY | ANALYSIS]
       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 é compatível com 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 seção deployParameters usa pares de chave-valor, conforme mostrado:

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

Se você definir parâmetros de implantação em um multi-target, o valor será atribuído ao manifesto de todos os destinos filhos desse multi-target.

multiTarget.targetIds: []

Essa propriedade é opcional e usada para configurar um multi-target a ser usado para implantação paralela.

O valor é uma lista separada por vírgulas de metas secundárias. Os destinos secundários são configurados como destinos normais e não incluem a 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 apenas no destino múltiplo, não nos 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 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, conforme exibido em sua lista de clusters no consoleGoogle Cloud .

Veja um exemplo:

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

Omita a propriedade gke ao configurar um multi-target. Em vez disso, o cluster do GKE é configurado no destino filho correspondente.

Consulte executionConfigs, neste documento, para descrições das propriedades do ambiente de execução. Consulte Implantar um HTTPRoute em um cluster diferente para informações sobre como implantar o HTTPRoute em um cluster alternativo que não seja o de destino.

associatedEntities.[KEY]

Em uma configuração canário, você usa esse nome para fazer referência às entidades de routeDestinations. Saiba mais.

dnsEndpoint

Quando definido como true, o Cloud Deploy se conecta ao cluster do GKE usando o endpoint DNS em vez do endpoint padrão, que pode ser um IP público, um IP particular ou o endpoint DNS, dependendo da configuração do cluster.

Essa opção não pode ser usada ao mesmo tempo que a opção internalIp.

internalIp

Quando definido como true, o Cloud Deploy se conecta ao cluster do GKE usando o endereço IP particular em vez do endpoint padrão, que pode ser um IP público, um IP particular ou o endpoint DNS, dependendo da configuração do cluster.

Essa opção não pode ser usada ao mesmo tempo que a opção dnsEndpoint. Como a configuração de rede para dnsEndpoint é muito mais simples, recomendamos usar essa opção.

proxyUrl

Se você acessar clusters por um proxy HTTP, forneça a propriedade proxyUrl aqui. O valor é o URL do proxy, que é transmitido ao kubectl ao se conectar ao cluster.

Para destinos do Cloud Run

O YAML a seguir mostra como configurar um destino que implanta 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 | ANALYSIS]
       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 é compatível com 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: []

Essa propriedade é opcional e usada para configurar um multi-target a ser usado para implantação paralela.

O valor é uma lista separada por vírgulas de metas secundárias. Os destinos secundários são configurados como destinos normais e não incluem a 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 apenas no destino múltiplo, não nos destinos filhos.

run

Somente 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 Google Cloud em que o serviço vai ficar.

  • location

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

Omita a propriedade run ao configurar um [multi-target]. O local do serviço do Cloud Run é configurado no destino filho correspondente.

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

Para destinos de clusters anexados do GKE

A configuração de destino para implantação em clusters anexados do GKE é semelhante à configuração de um destino para um destino do GKE, exceto que a propriedade é anthosCluster.membership, em vez de gke.cluster, o caminho do recurso é diferente, e métodos de conexão específicos (dnsEndpoint ou internalIp) não são aplicáveis.

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

  • project_name

    O projeto Google Cloud em que o cluster reside.

  • /location/global/

    O local em que o cluster está registrado. global, em todos os casos.

  • membership_name

    O nome da assinatura do cluster.

Veja um exemplo:

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

Omita a propriedade anthosCluster ao configurar um [multi-target]. Em vez disso, o cluster é configurado no destino filho correspondente.

Para mais informações sobre como fazer implantações em clusters anexados do GKE, consulte Fazer implantações em clusters anexados do GKE.

Para segmentações personalizadas

A configuração para destinos personalizados é semelhante a todos os outros tipos de destino, exceto que não inclui uma seção gke, run ou 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 usado na definição de tipo de destino personalizado.

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. Elas indicam quais dessas operações serão executadas para esse destino usando esse ambiente de execução. Para indicar que um ambiente de execução personalizado precisa ser usado para hook de pré-implantação, renderização, implantação, hook de pós-implantação e verificação, configure-o da seguinte maneira:

    usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY
- ANALYSIS

    Se a verificação estiver ativada na etapa do pipeline e você não especificar VERIFY em uma seção usages, o Cloud Deploy 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, você precisa especificar um para VERIFY, PREDEPLOY, POSTDEPLOY ou ANALYSIS se eles estiverem configurados no pipeline de entrega.VERIFY, PREDEPLOY, POSTDEPLOY e ANALYSIS podem estar no mesmo usages que RENDER ou DEPLOY, ou em usages separados.

    Não é possível especificar usages.VERIFY, usages.PREDEPLOY, usages.POSTDEPLOY ou usages.ANALYSIS, 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 a ser usado. Isso usa um caminho de recurso que identifica o pool de workers do Cloud Build a ser usado 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, é possível especificar uma conta de serviço ou um local de armazenamento alternativo ou ambos.

  • serviceAccount

    O nome da conta de serviço a ser usada nesta operação (RENDER ou DEPLOY) para este 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 realiza para o Cloud Deploy. Por padrão, esse valor é de 3600 segundos (1 hora).
    Exemplo: executionTimeout: "5000s"

  • verbose

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

Sintaxe alternativa aceita

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

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

Ao configurar uma estrofe executionConfigs para um destino múltiplo, cada destino filho pode herdar esse ambiente de execução do destino múltiplo.

Definições de tipos de segmentações personalizadas

Esta seção descreve os campos usados para definir tipos de destino personalizados.

Assim como com destinos e automações padrão, as definições de CustomTargetType podem ser incluídas 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ê dá a essa definição de tipo de segmentação personalizada. Esse nome é referenciado na definição de segmentação para qualquer segmentação que use o tipo 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 Automation

Esta seção descreve os campos usados para definir os recursos de automaçã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. Os detalhes de uma regra de automação variam de acordo com a regra. A configuração dos tipos de regras de automação disponíveis 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]:
    id:[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 para os quais foram criadas. Ou seja, não é possível compartilhar uma automação em mais de um pipeline de entrega.

  • [PURPOSE]

    É qualquer outro nome descritivo para essa automação. Normalmente, essa é a ação automatizada. Por exemplo, my-app-pipeline/promote

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

  • [DESCRIPTION]

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

  • suspended

    true ou false, indicando se a automação está ativa ou suspensa. Se definido como true, a automação não 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 do lançamento e, portanto, vai precisar das permissões necessárias para promover um lançamento.

    É necessário informar 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:

    • Permissão 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 ou clouddeploy.rollouts.advance para avançar uma fase de lançamento.

  • [TARGET_ID]

    É o ID da meta para a qual essa automação é usada. Embora uma automação esteja vinculada a um pipeline de entrega, ela só é executada no destino especificado ou nos destinos especificados.

    Defina como * para selecionar todos os destinos no pipeline de entrega.

  • [LABEL_KEY]:[LABEL_VALUE]

    É um par de chave-valor para corresponder 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. Pode ser promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule ou repairRolloutRule. É possível incluir mais de uma regra em uma automação, inclusive mais de uma do mesmo 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. Ele precisa ser exclusivo no recurso de automação. É necessário informar 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 Usar regras de automação.

Implantar definições de política

Esta seção descreve os campos usados para definir políticas de implantação.

Assim como 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 esta política.

  • [POLICY_NAME]

    Um nome para a política. Esse campo usa uma string que precisa ser exclusiva por projeto e local. Ele precisa ter letras minúsculas, números e hífens, com o primeiro caractere sendo uma letra, o último sendo 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 como true desativa essa 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 propriedade metadata.name no pipeline de entrega.

  • [TARGET_ID]

    É o ID do destino que você quer que essa política afete. É possível usar * para denotar todos os destinos. Esse ID é o mesmo da propriedade metadata.name no destino.

  • [LABEL_KEY]:[LABEL_VALUE]

    É um par de chave-valor para corresponder a um par de chave-valor definido no pipeline de entrega ou destino. Isso seleciona todos os pipelines ou destinos que têm o mesmo rótulo e valor. É possível especificar labels em vez de id ou além dele.

  • [RULE_TYPE]

    É o tipo de regra de política específica 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 é descrita mais adiante nesta seção desta referência, para cada uma das regras disponíveis.

Implantar regras de política

Nesta seção, descrevemos como configurar cada regra de política de implantação.

rolloutRestriction

A regra rolloutRestriction impede que o Cloud Deploy execute determinadas operações em lançamentos durante o período ou períodos especificados, para os pipelines de entrega e destinos indicados pelo selectors na 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 essa regra. Obrigatório. Ele precisa conter letras minúsculas, números e hifens. O primeiro caractere precisa ser uma letra, o último, uma letra ou um número, e o máximo de caracteres é 63. 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

      Não é possível avançar as fases de lançamento.

    • 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

      Não é possível ignorar jobs.

    • RETRY_JOB

      Não é possível tentar novamente os jobs.

    • ROLLBACK

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

    • TERMINATE_JOBRUN

      Não é possível encerrar as execuções de jobs

  • INVOKERS

    Especificar invocadores vai filtrar a aplicação da política dependendo se a ação restrita foi invocada por um usuário ou por uma automação de implantação. Os valores válidos são:

    • USER

      A ação é iniciada pelo usuário. Por exemplo, criar um lançamento manual usando um comando da CLI gcloud.

    • DEPLOY_AUTOMATION

      Uma ação automatizada do Cloud Deploy.

    É possível especificar um ou os dois valores. O padrão, se você não especificar nada, é ambos.

  • TIMEZONE

    O fuso horário, no formato IANA, em que você está expressando o período. Por exemplo, America/New_York. Obrigatório.

  • START_DATE_TIME

    Para oneTimeWindows, a data e a hora que marcam o início do período de restrição, no formato "yyyy-mm-dd hh:mm". Para o início do 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 um horário de início, também precisará incluir um horário de término. Para o início do dia, use 00:00.

  • END_TIME

    Para weeklyWindows, o horário de término no dia da semana especificado. Se você incluir um horário de início, também precisará incluir um horário de término. Para o fim do dia, use 24:00.

Definições de análise

Uma seção analysis permite configurar um job de análise para executar uma ou mais verificações em alertas do Google Cloud Observability ou dados semelhantes de outros provedores de monitoramento, a fim de realizar ações com base nesses alertas.

A seção analysis varia de acordo com a configuração para o Google Cloud Observability ou para um provedor diferente usando a análise personalizada.

analysis para o Google Cloud Observability

A estrofe analysis pode ser usada diretamente em uma configuração de estratégia de implantação (strategy.standard.analysis, para uma estratégia padrão). Se você quiser configurar a análise por fase, use um teste canário personalizado (strategy.canary.customCanaryDepolyment.phaseConfigs.phaseId.analysis).

analysis:
  duration: DURATION
  googleCloud:
    alertPolicyChecks:
    - id: CHECK_ID
      alertPolicies:
      - ALERT_POLICY_NAME
      labels:
        LABEL_KEY: LABEL_VALUE

Estas são as propriedades de configuração para analysis ao usar o Google Cloud Observability:

  • Você pode ter qualquer número de alertPolicyChecks.

  • DURATION é o tempo, em segundos, minutos ou horas, para executar a análise. Depois desse período, a análise não será mais afetada pelos alertas do Google Cloud Observability. Por exemplo, 200s.

    CHECK_ID é um ID exclusivo para a verificação da política de alertas. Isso é mostrado nos resultados da análise para cada verificação.

  • ALERT_POLICY_NAME é o nome da política de alertas criada no Google Cloud Observability.

  • LABEL_KEY é um nome de rótulo para qualquer rótulo que sua verificação use para corresponder à política de alertas do Google Cloud Observability.

  • LABEL_VALUE é o valor a ser correspondido para cada rótulo.

Personalizado analysis

Um job de análise que usa verificações personalizadas (em relação a dados de um provedor de monitoramento que não seja o Google Cloud Observability). Uma verificação personalizada usa uma tarefa para especificar o contêiner que inclui o comportamento personalizado e os comandos a serem executados nesse contêiner.

A configuração de uma análise personalizada é a seguinte:

analysis:
  duration: DURATION
  customChecks:
  - id: CHECK_ID
    frequency: FREQUENCY
    task:
      type: container
      image: IMAGE_NAME
      command: [COMMAND]
      args: [ARGS]
      env:
        [VAR: VALUE]

  • DURATION é o tempo, em segundos, minutos ou horas, para executar a análise. Depois desse período, a análise não será mais afetada pela telemetria recebida do seu sistema de monitoramento. Por exemplo, 200s.

  • CHECK_ID é um ID exclusivo que você fornece para a verificação da política de alertas. Isso é mostrado nos resultados da análise para cada verificação.

  • FREQUENCY especifica a frequência, em segundos, minutos ou horas, com que a verificação é executada. Por exemplo, 300s.

  • IMAGE_NAME é o caminho para a imagem do contêiner em um repositório de imagens.

  • COMMAND é o ponto de entrada a ser executado nesse contêiner. "/bin/sh" é um comando típico para especificar aqui, para invocar um shell, e você incluiria o comando ou os comandos a serem executados nesse shell nos argumentos.

  • ARGS é uma lista de argumentos a serem fornecidos ao comando. Se o COMMAND for "/bin/sh", um dos argumentos será "-c", e outro será todo o comando que você quer executar no shell que está invocando.

    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.