Como usar 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) dos manifestos renderizados no Cloud Storage.

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

Neste artigo, descrevemos o ambiente de execução padrão, as contas de serviço e o armazenamento do Cloud Deploy, além de explicar por que e como alterar esses padrões.

Padrões

Veja a seguir os padrões que o Cloud Deploy usa para executar, executar renderização e implantação e 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 seus manifestos renderizados. Por padrão, o Cloud Deploy cria um bucket do Cloud Storage, na mesma região dos recursos do Cloud Deploy, no seguinte formato:

    <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 uma hora nas operações executadas no Cloud Deploy. É possível alterar esse tempo limite na especificação do ambiente de execução na configuração de destino.

  • Nível de detalhes padrão para Skaffold, CLI gcloud e kubectl

    Por padrão, os níveis de registro dessas ferramentas são definidos com os respectivos padrões, geralmente warn ou equivalente. É possível mudar 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 uma das seguintes opções:

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

    Os pools de workers privados são privados, dedicados, que podem ser personalizados mais do que o pool de workers padrão. Essa personalização pode incluir a capacidade de acessar 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 verticalmente para zero, sem necessidade de configuração, upgrade ou escalonamento vertical.

    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 alterar o ambiente de execução do Cloud Deploy

É possível alterar 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 operações de renderização, implantação, pré-implantação, pós-implantação ou verificação, ou uma combinação dos cinco, sejam executadas em um ambiente isolado de outras organizações.

  • Você quer que essas operações sejam realizadas 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

Configure pools de workers por destino para que o pool seja 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.

Veja 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.

Alteração do nível de registro do Skaffold, CLI gcloud e kubectl

Para alterar o nível de registro do Skaffold, CLI gcloud e kubectl, dos respectivos padrões para debug (ou 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 oferece suporte ao 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 privados do Cloud Build para o ambiente de execução do destino, e não para o pool de workers padrão.

  • O projeto que contém o pool de workers e o 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