Como usar os ambientes de execução do Cloud Deploy

Um ambiente de execução do Cloud Deploy é o ambiente em que o Cloud Deploy executa as operações de renderização, pré-implantação, implantação, verificação e pós-implantação. O ambiente de execução consiste nos seguintes componentes:

  • O pool de workers do Cloud Build (padrão ou particular) em que o Cloud Deploy executa operações de renderização, pré-implantação, implantação, verificação e pós-implantação.

  • A conta de serviço (padrão ou alternativa) que chama o Cloud Deploy para realizar essas ações.

  • O local de armazenamento (padrão ou alternativo) para manifestos renderizados no Cloud Storage.

  • O tempo limite do Cloud Build para operações (padrão ou personalizado)

Este artigo descreve o ambiente de execução padrão, as contas de serviço e o armazenamento do Cloud Deploy, além de por que e como você pode alterar esses padrões.

Padrões

Confira a seguir os padrões que o Cloud Deploy usa para executar, para renderizar e implantar, e para armazenar recursos, como manifestos renderizados:

  • Pool de workers padrão

    Por padrão, o Cloud Deploy é executado no pool de workers padrão do Cloud Build. No entanto, é possível configurar o Cloud Deploy para usar um pool de workers particulares do Cloud Build.

    Para mais detalhes sobre pools de workers, consulte a Visão geral dos pools padrão e particulares do Cloud Build.

  • Conta de serviço de execução padrão

    Por padrão, o Cloud Deploy usa a conta de serviço padrão do Compute Engine.

  • Local de armazenamento padrão do Cloud Deploy

    Esse valor é o bucket do Cloud Storage em que o Cloud Deploy armazena os manifestos renderizados. Por padrão, o Cloud Deploy cria um bucket do Cloud Storage na mesma região dos recursos do Cloud Deploy, da seguinte forma:

    <location>.deploy-artifacts.<project ID>.appspot.com

  • Tempo limite padrão do Cloud Build

    Por padrão, o Cloud Build tem um tempo limite de 1 hora nas operações que executa para o Cloud Deploy. É possível mudar esse tempo limite na especificação do ambiente de execução na configuração do destino.

  • Detalhamento padrão para Skaffold, CLI gcloud e kubectl

    Por padrão, os níveis de registro dessas ferramentas são definidos como os respectivos padrões, normalmente warn ou o equivalente. Você pode mudar isso para debug ou o equivalente.

As seções a seguir descrevem as circunstâncias em que você alteraria qualquer um desses valores, além de links para instruções sobre como fazer isso.

Sobre os pools de workers do Cloud Build

O ambiente de execução do Cloud Deploy pode usar um dos seguintes:

  • O pool padrão do Cloud Build

    O pool de workers padrão é um ambiente seguro e hospedado com acesso à Internet pública. As operações de renderização, implantação, pré-implantação, pós-implantação e verificação são executadas nesse pool, isoladas de outras cargas de trabalho.

  • Um pool particular

    Os pools de workers particulares são privados e dedicados, e podem ser personalizados além do pool de workers padrão. Essa personalização pode permitir o acesso a recursos em uma rede privada. Assim como o pool de workers padrão, os pools de workers particulares são hospedados e totalmente gerenciados pelo Cloud Build. Esses pools podem ser escalonar verticalmente ou reduzir escala vertical a zero, sem infraestrutura para configurar, fazer upgrade ou escalonamento.

    A visão geral dos pools de workers particulares do Cloud Build descreve com mais detalhes os pools de workers padrão e os particulares, incluindo uma tabela de comparação dos respectivos recursos.

Como mudar o ambiente de execução do Cloud Deploy

É possível mudar o ambiente de execução do Cloud Deploy nas seguintes circunstâncias:

  • Você quer implantar em um cluster privado do Google Kubernetes Engine.

  • Você quer que as operações de renderização, implantação, pré-implantação, pós-implantação ou verificação, ou uma combinação das cinco, sejam realizadas em um ambiente isolado de outras organizações.

  • Você quer executar essas operações em um ambiente que não esteja conectado à Internet pública.

  • Você quer ambientes separados para renderizar e implantar.

  • Você quer usar uma conta de serviço dedicada com permissões mais específicas do que as permissões disponíveis na conta de serviço padrão.

  • Você quer armazenar manifestos renderizados em um local diferente do bucket padrão do Cloud Storage.

A configuração das três partes do ambiente de execução (pool de workers, conta de serviço e armazenamento) é feita por destino na configuração YAML de cada destino.

Como mudar do pool padrão para um pool particular

Você configura os pools de workers por destino. Dessa maneira, o pool é usado para RENDER, DEPLOY, PREDEPLOY, POSTDEPLOY ou VERIFY (ou uma combinação dos cinco) apenas para esse destino.

Para usar o pool de workers padrão para operações de renderização e implantação, não é necessário fazer nada.

Confira a seguir um exemplo de configuração de destino que especifica um pool de workers particular para DEPLOY e o pool de workers padrão para RENDER, PREDEPLOY, POSTDEPLOY e VERIFY:

executionConfigs:
- usages:
  - DEPLOY
  privatePool:
    workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
- usages:
  - RENDER
  - PREDEPLOY
  - VERIFY
  - POSTDEPLOY

Para mais informações sobre como configurar pools particulares para destinos, consulte Documentação de configuração do pipeline de entrega.

Como alterar do padrão para a conta de serviço de execução personalizada

Assim como no pool de workers, é possível especificar uma conta de serviço alternativa para renderização ou implantação (ou ambas) por destino. Para fazer isso, adicione a seguinte linha à configuração de destino, após o elemento workerPool:

serviceAccount: "[name]@[project_name].iam.gserviceaccount.com"

A conta de serviço especificada precisa incluir o papel clouddeploy.jobRunner, conforme descrito no documento Contas de serviço do Cloud Deploy.

Consulte Definições de destino para mais detalhes sobre essa configuração.

Como alterar o local de armazenamento

Para alterar o bucket de armazenamento do padrão do Cloud Deploy, adicione a seguinte linha à definição de destino na estrofe workerPool:

artifactStorage: "gs://[bucket_name]/[dir]"

Essa configuração muda onde os manifestos renderizados são armazenados, mas não afeta o local em que a origem da renderização é armazenada.

Como mudar o nível de registro do Skaffold, da CLI gcloud e do kubectl

Para mudar o nível de registro do Skaffold, da CLI gcloud e do kubectl dos respectivos padrões para debug (ou o equivalente), defina verbose como true nas configurações de execução. Veja um exemplo:

executionConfigs:
- usages:
  - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose: true

Como usar o Cloud Deploy em um perímetro do VPC Service Controls

O Cloud Deploy é compatível com o VPC Service Controls.

Siga o guia de início rápido do VPC Service Controls para configurar um perímetro de serviço.

Limitações

  • Use um pool de workers particular do Cloud Build para o ambiente de execução do destino, e não o pool de workers padrão.

  • O projeto que contém o pool de workers e o projeto que contém os recursos do Cloud Deploy precisam permanecer no mesmo perímetro de segurança do VPC Service Controls.

  • Qualquer cluster do GKE implantado no perímetro do VPC Service Controls precisa ser um cluster particular.

    Para configurar um pool privado de um cluster particular, consulte este tutorial.

A seguir