Referência do esquema de configuração

O ficheiro ou os ficheiros de configuração da implementação na nuvem definem o pipeline de entrega, os destinos para implementação e a progressão desses destinos.

O ficheiro de configuração do pipeline de fornecimento pode incluir definições de destino, ou estas podem estar num ficheiro ou ficheiros separados. Por convenção, um ficheiro que contenha a configuração do pipeline de entrega e as configurações de destino é denominado clouddeploy.yaml, e uma configuração do pipeline sem destinos é denominada delivery-pipeline.yaml. No entanto, pode atribuir a estes ficheiros o nome que quiser. Outras definições de recursos, como automatizações e políticas de implementação, também podem estar no mesmo ficheiro que uma definição de destino ou pipeline de entrega.

O que vai para onde

O Cloud Deploy usa dois ficheiros de configuração principais:

Podem ser ficheiros separados ou a pipeline de entrega e os alvos podem ser configurados no mesmo ficheiro.

Estrutura de um ficheiro de configuração do pipeline de entrega

Segue-se a estrutura de uma configuração do pipeline de fornecimento, incluindo propriedades para definições de destino. Algumas propriedades de destino não estão incluídas aqui. Consulte as 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:
       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:
 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]
  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]

Este YAML tem três componentes principais:

  • O pipeline de fornecimento principal e a progressão

    O ficheiro de configuração pode incluir qualquer número de definições de pipelines.

  • As definições de objetivos

    Para simplificar, apenas é apresentado um alvo neste exemplo, mas pode haver qualquer número de alvos. Além disso, os alvos podem ser definidos num ou vários ficheiros separados.

  • Definições de tipos de alvos personalizados

    As segmentações personalizadas requerem uma definição de tipo de segmentação personalizada. Tal como acontece com os alvos e as automatizações, os tipos de alvos personalizados podem ser definidos no mesmo ficheiro que o pipeline de fornecimento ou num ficheiro separado.

  • Definições de automatização

    Pode criar quaisquer automatizações de implementação no mesmo ficheiro que a sua pipeline de entrega e segmentações, ou num ficheiro ou ficheiros separados. Para simplificar, aqui é apresentado apenas um Automation, mas pode criar quantos quiser.

Estes componentes são definidos no resto 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 alvos por ordem da sequência de implementação. Ou seja, o primeiro alvo indicado é o primeiro alvo de implementação. Depois de implementar nesse destino, a promoção do lançamento é implementada no destino seguinte na lista.

Seguem-se as propriedades de configuração de um pipeline de fornecimento, não incluindo as definições de destino.

metadata.name

O campo name aceita uma string que tem de ser exclusiva por projeto e localização.

metadata.annotations e metadata.labels

A configuração do pipeline de fornecimento pode incluir anotações e etiquetas. As anotações e as etiquetas são armazenadas com o recurso do pipeline de entrega depois de o pipeline ter sido registado.

Para mais informações, consulte o artigo Usar etiquetas e anotações com o Cloud Deploy.

description

Uma string arbitrária que descreve este pipeline de envio. Esta descrição é apresentada nos detalhes do pipeline de fornecimento na Google Cloud consola.

suspended

Um valor booleano que, se for true, suspende o pipeline de fornecimento, de modo que não pode ser usado para criar, promover, reverter nem voltar a implementar lançamentos. Além disso, se o pipeline de envio estiver suspenso, não pode aprovar nem rejeitar uma implementação criada a partir desse pipeline.

A predefinição é false.

serialPipeline

O início da definição de um pipeline de fornecimento de progressão em série. Esta stanza é obrigatória.

stages

Uma lista de todos os destinos para os quais este pipeline de implementação está configurado para implementação.

A lista tem de estar na ordem da sequência de entrega pretendida. Por exemplo, se tiver alvos denominados dev, staging e production, liste-os por essa ordem para que a primeira implementação seja para dev e a implementação final seja para production.

Preencha cada campo stages.targetId com o valor do campo metadata.name na definição do alvo correspondente. Além disso, em targetId, inclua profiles:

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

targetId

Identifica o alvo específico a usar para esta fase do pipeline de fornecimento. O valor é a propriedade metadata.name da definição do alvo.

strategy.standard.verify definido como true ativa a validação da implementação no destino. Se não for especificada nenhuma estratégia de implementação, é usada a estratégia de implementação standard, com a validação definida como false.

profiles

Recebe uma lista de zero ou mais nomes de perfis do Skaffold, de skaffold.yaml. O Cloud Deploy usa o perfil com skaffold render quando cria a versão. Os perfis do Skaffold permitem-lhe variar a configuração entre destinos enquanto usa um único ficheiro de configuração.

strategy

Inclui propriedades para especificar uma estratégia de implementação. As seguintes estratégias são suportadas:

  • standard:

    A aplicação é implementada totalmente no destino especificado.

    Esta é a estratégia de implementação predefinida. Se omitir strategy, o Cloud Deploy usa a estratégia de implementação standard.

  • canary:

    Numa implementação canária, implementa uma nova versão da sua aplicação progressivamente, substituindo a versão já em execução por incrementos baseados em percentagens (por exemplo, 25%, depois 50%, depois 75% e, por fim, totalmente).

A estratégia de implementação é definida por alvo. Por exemplo, pode ter uma estratégia de teste para o alvo prod, mas uma estratégia padrão (sem strategy especificado) para os outros alvos.

Para mais informações, consulte o artigo Use uma estratégia de implementação.

Configuração do strategy

Esta secção mostra os elementos de configuração para strategy, para cada tempo de execução suportado.

Estratégia de implementação padrão

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

strategy:
  standard:
    verify: true|false

A propriedade verify é opcional. A predefinição é false, o que significa que não vai haver uma fase de validação para as implementações resultantes.

Pode omitir o elemento strategy para uma estratégia de implementação padrão.

Estratégia de implementação de teste

As secções seguintes descrevem a configuração de uma estratégia de implementação canary para cada tempo de execução suportado pelo Cloud Deploy.

Para destinos do Cloud Run
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false
Para alvos do GKE e GKE Enterprise

O YAML seguinte mostra como configurar uma estratégia de implementação para um destino do GKE ou GKE Enterprise, usando a rede baseada em serviços:

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

O YAML seguinte mostra como configurar uma estratégia de implementação para um destino do GKE ou GKE Enterprise, 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: true | false

Repare neste exemplo routeUpdateWaitTime. Isto está incluído porque a API Gateway divide o tráfego através de um recurso HTTPRoute e, por vezes, existe um atraso na propagação das alterações feitas ao HTTPRoute. Nestes casos, os pedidos podem ser ignorados porque o tráfego está a ser enviado para recursos que não estão disponíveis. Pode usar routeUpdateWaitTime para fazer com que o Cloud Deploy aguarde após aplicar alterações HTTPRoute, se observar este atraso.

O YAML seguinte mostra como configurar uma estratégia de implementação canary personalizada (para redes de serviços, API Gateway ou Cloud Run) ou uma estratégia de implementação canary automatizada personalizada (para redes de serviços, API Gateway ou Cloud Run). A configuração específica do tempo de execução, na secção runtimeConfig, é omitida para o lançamento canary personalizado, mas incluída na configuração 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: true | false
           - …
           - name: "stable"
             percent: 100
             profiles: [ "LAST_PROFILE_NAME" ]
             verify: true|false

verify

Booleano opcional que indica se a validação da implementação é suportada para este destino. A predefinição é false.

A ativação da validação da implementação também requer uma secção verify no skaffold.yaml. Se não fornecer esta propriedade, a tarefa de validação falha.

deployParameters

Permite-lhe especificar pares de chave-valor para transmitir valores a manifestos para alvos com correspondência de etiquetas quando usar parâmetros de implementação.

Também pode incluir esta opção em alvos.

Implemente parâmetros definidos numa pipeline de entrega. Use etiquetas para corresponder a alvos:

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

Neste exemplo, são fornecidos dois valores para a chave e, para cada valor, existe uma etiqueta. O valor é aplicado ao manifesto para qualquer destino que tenha uma etiqueta correspondente.

Empregos de predeploy e postdeploy

Estes permitem-lhe fazer referência a ações personalizadas (definidas separadamente, em skaffold.yaml) a executar antes da tarefa de implementação (predeploy) e após a tarefa de validação, se estiver presente (postdeploy). Se não existir uma tarefa de validação, a tarefa postdeploy é executada após a tarefa de implementação.

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

serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]

Onde ACTION_NAME é o nome configurado em skaffold.yaml para customActions.name.

Pode configurar tarefas predeploy e postdeploy em qualquer estratégia (por exemplo, standard e canary).

Para mais informações sobre a configuração e a utilização de hooks de pré-implementação e pós-implementação, consulte o artigo Execute hooks antes e depois da implementação.

Definições de alvos

O ficheiro de definição do pipeline de entrega pode conter definições de alvos ou pode especificar alvos num ficheiro separado. Pode repetir os nomes dos alvos num projeto, mas têm de ser exclusivos numa pipeline de entrega.

Pode reutilizar alvos em várias condutas de entrega. No entanto, só pode fazer referência a um alvo uma vez a partir da progressão de um único pipeline de entrega.

Consulte também: definições de tipo de alvo personalizado

Para alvos do GKE

O YAML seguinte mostra como configurar um destino que é implementado num 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]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

metadata.name

O nome desta segmentação. Este nome tem de ser globalmente exclusivo.

metadata.annotations e metadata.labels

A configuração de destino suporta anotações do Kubernetes e etiquetas, mas o Cloud Deploy não as requer.

As anotações e as etiquetas são armazenadas com o recurso de destino. Para mais informações, consulte o artigo Usar etiquetas e anotações com o Cloud Deploy.

description

Este campo aceita uma string arbitrária que descreve a utilização deste alvo.

deployParameters

Pode incluir parâmetros de implementação em qualquer destino, juntamente com valores. Esses valores são atribuídos às chaves correspondentes no seu manifesto após a renderização.

A secção deployParameters aceita pares de chave-valor, conforme mostrado:

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

Se definir parâmetros de implementação num multi-alvo, o valor é atribuído ao manifesto de todos os alvos secundários desse multi-alvo.

multiTarget.targetIds: []

Esta propriedade é opcional e é usada para configurar um alvo múltiplo a usar para a implementação paralela.

O valor é uma lista separada por vírgulas de alvos secundários. Os alvos secundários são configurados como alvos normais e não incluem esta propriedade multiTarget.

requireApproval

Se a promoção para este destino requer aprovação manual. Pode ser true ou false.

Esta propriedade é opcional. A predefinição é false.

Quando configura a implementação paralela, pode exigir a aprovação apenas na segmentação múltipla e não nas segmentações secundárias.

gke

Apenas para clusters do GKE, o caminho do recurso que identifica o cluster onde a sua aplicação vai ser implementada:

gke:
  cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

  • project_name

    O Google Cloud projeto no qual o cluster está incluído.

  • location

    A localização onde o cluster reside. Por exemplo, us-central1. O cluster também pode ser zonal (us-central1-c).

  • cluster_name

    O nome do cluster, tal como aparece na sua lista de clusters na Google Cloud consola.

Segue-se um exemplo:

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

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

Consulte executionConfigs neste documento para ver descrições das propriedades do ambiente de execução. Consulte o artigo Implemente um HTTPRoute num cluster diferente para obter informações sobre a implementação do HTTPRoute num cluster alternativo que não seja o cluster de destino.

dnsEndpoint

Quando definido como true, o Cloud Deploy estabelece ligação ao cluster do GKE através do ponto final de DNS em vez do ponto final predefinido, que pode ser um IP público, um IP privado ou o ponto final de DNS, consoante a configuração do cluster.

Não é possível usar esta opção ao mesmo tempo que a opção internalIp.

internalIp

Quando definido como true, o Cloud Deploy liga-se ao cluster do GKE através do endereço IP privado em vez do ponto final predefinido, que pode ser um IP público, um IP privado ou o ponto final DNS, consoante a configuração do cluster.

Não é possível usar esta opção ao mesmo tempo que a opção dnsEndpoint. Uma vez que a configuração de rede para dnsEndpoint é muito mais simples, recomendamos que a use em alternativa.

proxyUrl

Se aceder aos clusters através de um proxy HTTP, indique a propriedade proxyUrl aqui. O valor é o URL do proxy, que é transmitido para o kubectl quando se liga ao cluster.

Para destinos do Cloud Run

O YAML seguinte mostra como configurar um destino que é implementado num 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 desta segmentação. Este nome tem de ser exclusivo por região.

metadata.annotations e metadata.labels

A configuração de destino suporta anotações e etiquetas, mas o Cloud Deploy não as requer.

As anotações e as etiquetas são armazenadas com o recurso de destino. Para mais informações, consulte o artigo Usar etiquetas e anotações com o Cloud Deploy.

description

Este campo aceita uma string arbitrária que descreve a utilização deste alvo.

multiTarget.targetIds: []

Esta propriedade é opcional e é usada para configurar um alvo múltiplo a usar para a implementação paralela.

O valor é uma lista separada por vírgulas de alvos secundários. Os alvos secundários são configurados como alvos normais e não incluem esta propriedade multiTarget.

requireApproval

Se a promoção para este destino requer aprovação manual. Pode ser true ou false.

Esta propriedade é opcional. A predefinição é false.

Quando configura a implementação paralela, pode exigir a aprovação apenas na segmentação múltipla e não nas segmentações secundárias.

run

Apenas para serviços do Cloud Run, a localização onde o serviço vai ser criado:

run:
  location: projects/[project_name]/locations/[location]

  • project_name

    O Google Cloud projeto no qual o serviço vai estar disponível.

  • location

    A localização onde o serviço está disponível. Por exemplo, us-central1.

Omita a propriedade run quando configurar um [multi-target]. Em alternativa, a localização do serviço do Cloud Run é configurada no destino filho correspondente.

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

Para destinos do GKE Enterprise

A configuração do alvo para implementação num cluster do GKE é semelhante à configuração de um alvo para um alvo do GKE, exceto que a propriedade é anthosCluster.membership, em vez de gke.cluster, o caminho do recurso é diferente e os métodos de ligaçã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 Google Cloud projeto no qual o cluster do GKE Enterprise está incluído.

  • /location/global/

    A localização onde o cluster está registado. global, em todos os casos.

  • membership_name

    O nome da associação do cluster do GKE Enterprise.

Segue-se um exemplo:

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

Omita a propriedade anthosCluster quando configurar um [multi-target]. Em alternativa, o cluster do GKE Enterprise é configurado no destino filho correspondente.

Para mais informações sobre a implementação em clusters do GKE, consulte o artigo Implementação em clusters de utilizadores do Anthos.

Para segmentações personalizadas

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

Em alternativa, as segmentações personalizadas incluem uma secção customTarget:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Onde CUSTOM_TARGET_TYPE_NAME é o nome que usou na definição do tipo de segmentação personalizada.

Segue-se 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 predefinido para este alvo.

  • usages

    RENDER ou DEPLOY ou ambos, além de PREDEPLOY, VERIFY ou POSTDEPLOY se a validação ou os hooks de implementação estiverem ativados no destino. Estes indicam qual dessas operações deve ser realizada para este destino usando este ambiente de execução. Para indicar que um ambiente de execução personalizado deve ser usado para o gancho de pré-implementação, a renderização, a implementação, o gancho de pós-implementação e a validação, configurá-lo-ia da seguinte forma:

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

    Se a validação estiver ativada na fase do pipeline, e não especificar VERIFY numa secção usages, o Cloud Deploy usa o ambiente de execução predefinido para a validação. Os hooks de pré-implementação e pós-implementação funcionam da mesma forma.

    No entanto, se existir um ambiente de execução personalizado para RENDER e DEPLOY, tem de especificar um para VERIFY, PREDEPLOY OU POSTDEPLOY se estiverem configurados no pipeline de entrega.VERIFY, PREDEPLOY e POSTDEPLOY podem estar no mesmo usages que RENDER ou DEPLOY, ou em usages separados.

    Não pode especificar usages.VERIFY, usages.PREDEPLOY nem usages.POSTDEPLOY, a menos que RENDER e DEPLOY sejam especificados nos mesmos ambientes de execução personalizados ou em ambientes separados.

  • workerPool

    Configuração a usar para o conjunto de trabalhadores. Este comando usa um caminho de recurso que identifica o worker pool do Cloud Build a usar para este destino. Por exemplo:

    projects/p123/locations/us-central1/workerPools/wp123.

    Para usar o pool do Cloud Build predefinido, omita esta propriedade.

    Um determinado destino pode ter dois workerPools (um para RENDER e outro para DEPLOY). Quando configurar o conjunto predefinido, pode especificar uma conta de serviço ou uma localização de armazenamento alternativa, ou ambas.

  • serviceAccount

    O nome da conta de serviço a usar para esta operação (RENDER ou DEPLOY) para este destino.

  • artifactStorage

    O contentor do Cloud Storage a usar para esta operação (RENDER ou DEPLOY) para este destino, em vez do contentor predefinido.

  • executionTimeout

    Opcional. Define o limite de tempo, em segundos, para as operações que o Cloud Build realiza para o Cloud Deploy. Por predefinição, este valor é de 3600 segundos (1 hora).
    Exemplo: executionTimeout: "5000s"

  • verbose

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

    • O Skaffold --verbosity está definido como debug. A predefinição do Skaffold é warn.

    • kubectl --v está definido como 4, que é debug. O valor predefinido do kubectl é 2.

    • A CLI do Google Cloud --verbosity está definida como debug. A predefinição é warning.

Sintaxe alternativa suportada

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

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

Quando configura uma secção executionConfigs para um multi-alvo, cada alvo secundário pode herdar esse ambiente de execução desse multi-alvo.

Definições de tipos de alvos personalizados

Esta secção descreve os campos usados para definir tipos de alvos personalizados

Tal como acontece com as segmentações e as automatizações padrão, as definições CustomTargetType podem ser incluídas na definição do pipeline de entrega ou num ficheiro ou ficheiros separados.

O YAML seguinte mostra como configurar um tipo de alvo 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:

Onde:

  • [CUSTOM_TARGET_TYPE_NAME]

    É um nome arbitrário que atribui a esta definição de tipo de segmentação personalizada. Este nome é referenciado na definição do alvo para qualquer alvo que use o tipo de alvo personalizado que está a definir.

  • [RENDER_ACTION_NAME]

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

  • [DEPLOY_ACTION_NAME]

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

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

Definições de automatização

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

Tal como acontece com os alvos, as definições de Automation podem ser incluídas na definição do pipeline de entrega ou num ficheiro ou ficheiros separados.

Para mais informações sobre a automatização no Cloud Deploy, consulte a documentação de automatização.

O YAML seguinte mostra como configurar uma automatização. Tenha em atenção que os detalhes de uma regra de automatização são diferentes por regra. (A configuração dos tipos de regras de automatização disponíveis encontra-se no documento Usar regras de automatizaçã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]

Onde:

  • [PIPELINE_NAME]

    É igual ao valor metadata.name no pipeline de entrega que usa esta automatização. Todas as automatizações são exclusivas dos pipelines de envio para os quais foram criadas. Ou seja, não pode partilhar uma automatização em mais do que um pipeline de entrega.

  • [PURPOSE]

    É um nome descritivo adicional para esta automatização. Normalmente, esta seria a ação automatizada. Por exemplo, my-app-pipeline/promote.

  • labels e annotations são quaisquer etiquetas ou anotações que queira associar a esta automatização.

  • [DESCRIPTION]

    É uma descrição opcional desta automatização.

  • suspended

    true ou false, indicando se esta automatização está ativa ou suspensa. Se estiver definida como true, a automatização não é usada. Isto pode ser útil para testar uma automatização sem afetar o pipeline de publicação.

  • [SERVICE_ACCOUNT_ID]

    É o ID da conta de serviço usada para realizar a automatização. Por exemplo, se a automatização usar o promoteReleaseRule, esta conta de serviço realiza a promoção do lançamento e, por isso, requer as autorizações necessárias para promover um lançamento.

    É necessário um valor para esta propriedade. O Cloud Deploy não usa a conta de serviço predefinida para automatizações.

    Esta conta de serviço tem de ter as seguintes autorizações:

    • actAs para usar a identidade da conta de serviço de execução.

    • autorização para realizar a operação que está a ser automatizada, por exemplo, clouddeploy.releases.promote para promover um lançamento ou clouddeploy.rollouts.advance para avançar uma fase de implementação.

  • [TARGET_ID]

    É o ID do alvo para o qual esta automatização é usada. Embora uma automatização esteja associada a um pipeline de fornecimento, só é executada na segmentação ou nas segmentações especificadas.

    Pode definir esta opção como * para selecionar todos os alvos no pipeline de fornecimento.

  • [LABEL_KEY]:[LABEL_VALUE]

    É um par de chave-valor a fazer corresponder a um par de chave-valor definido no destino. Esta opção seleciona todos os alvos associados ao pipeline de fornecimento que têm a mesma etiqueta e valor.

  • [RULE_TYPE]

    É o nome da regra de automatização usada para esta automatização. Esta é promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule ou repairRolloutRule. Pode incluir mais do que uma regra numa automatização, incluindo mais do que uma do mesmo RULE_TYPE. Por exemplo, pode ter mais do que uma regra promoteReleaseRule na mesma automatização. Saiba mais.

  • [RULE_NAME]

    Um nome para a regra. Este nome tem de ser exclusivo no pipeline de fornecimento. É necessário um valor para esta propriedade.

  • [RULE-SPECIFIC_CONFIG]

    A configuração é diferente para cada tipo de automatização suportado. Essas configurações são apresentadas em Usar regras de automatização.

Implemente definições de políticas

Esta secção descreve os campos usados para definir as políticas de implementação.

Tal como acontece com outros recursos do Cloud Deploy, pode incluir DeployPolicy definições na definição do pipeline de entrega ou num ficheiro separado.

O YAML seguinte mostra como configurar uma política de implementaçã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]

Onde:

  • [DESCRIPTION]

    É um texto opcional que descreve esta política.

  • [POLICY_NAME]

    Um nome para a política. Este campo recebe uma string que tem de ser exclusiva por projeto e localização. Tem de ser letras minúsculas, números e hífenes, com o primeiro caráter a ser uma letra, o último caráter a ser uma letra ou um número e um máximo de 63 carateres. Este nome é usado como nome a apresentar na Google Cloud consola.

  • [ANNOTATIONS] e [LABELS]

    As políticas podem incluir anotações e etiquetas, que fazem parte do recurso de política depois de ser criado. Para mais informações, consulte o artigo Usar anotações e etiquetas com o Cloud Deploy.

  • suspended: [true | false]

    Se definir suspended como true, esta política é desativada.

  • [PIPELINE_ID]

    É o ID do pipeline de entrega que quer que esta política afete. Pode usar * para denotar todos os pipelines. Este ID é o mesmo que o da propriedade metadata.name no pipeline de envio.

  • [TARGET_ID]

    É o ID do alvo que quer que esta política afete. Pode usar * para denotar todos os alvos. Este ID é igual à propriedade metadata.name no destino.

  • [LABEL_KEY]:[LABEL_VALUE]

    É um par de chave-valor para fazer a correspondência com um par de chave-valor definido no pipeline de entrega ou no destino. Esta opção seleciona todos os pipelines ou alvos que têm a mesma etiqueta e valor. Pode especificar labels em vez de ou além de id.

  • [RULE_TYPE]

    É o tipo de regra de política específico que está a configurar. O único valor válido é rolloutRestriction.

  • [CONFIGS]

    É o conjunto de propriedades de configuração da regra de política específica que está a criar. A configuração das regras é descrita mais adiante nesta secção desta referência, para cada uma das regras disponíveis.

Implemente regras de políticas

Esta secção descreve como configurar cada regra da política de implementação.

rolloutRestriction

A regra rolloutRestriction impede que o Cloud Deploy execute determinadas operações em implementações durante o período ou os períodos especificados, para os pipelines de entrega e os destinos indicados pelo selectors para a política de implementação.

O YAML seguinte 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]

Onde:

  • RULE_ID

    Um identificador para esta regra. Este campo é obrigatório. Tem de consistir em letras minúsculas, números e hífenes, com o primeiro caráter a ser uma letra, o último caráter a ser uma letra ou um número, e um máximo de 63 carateres. Tem de ser único na política de implementação.

  • ACTIONS

    Opcional: implemente ações a serem restritas como parte da política. Se estiver vazio, todas as ações são restritas. Os valores válidos são:

    • ADVANCE

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

    • APPROVE

      Não é possível aprovar a promoção de implementação.

    • CANCEL

      Não é possível cancelar implementações.

    • CREATE

      Não é possível criar implementações.

    • IGNORE_JOB

      Não é possível ignorar tarefas.

    • RETRY_JOB

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

    • ROLLBACK

      Não é possível reverter as implementações.

    • TERMINATE_JOBRUN

      Não é possível terminar as execuções de tarefas

  • INVOKERS

    A especificação de invocadores filtra a aplicação de políticas consoante a ação que está a ser restringida tenha sido invocada por um utilizador ou por uma automatização de implementação. Os valores válidos são:

    • USER

      A ação é orientada pelo utilizador. Por exemplo, criar uma implementação manualmente através de um comando da CLI gcloud.

    • DEPLOY_AUTOMATION

      Uma ação automatizada pelo Cloud Deploy.

    Pode especificar um ou ambos os valores. A predefinição, se não especificar nada, é ambas.

  • TIMEZONE

    O fuso horário, no formato IANA, no qual está a expressar o intervalo de tempo. Por exemplo, America/New_York. Este campo é 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 da janela de restrição, no formato "yyyy-mm-dd hh:mm". Para o final 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 deixar este campo em branco, corresponde a todos os dias da semana

  • START_TIME

    Para weeklyWindows, a hora de início no dia da semana especificado. Se incluir uma hora de início, tem de incluir uma hora de fim. Para o início do dia, use 00:00.

  • END_TIME

    Para weeklyWindows, a hora de fim no dia da semana especificado. Se incluir uma hora de início, tem de incluir uma hora de fim. Para o final do dia, use 24:00.

O que se segue?