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, renderiza, pré-implanta, implanta, verifica 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 a renderização, operações de 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 para o Cloud Deploy, além de explicar por que e como você pode alterá-los padrão.

Padrões

A seguir estão os padrões que o Cloud Deploy usa para executar, para 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 Cloud Build padrão pool de workers. 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 Compute Engine padrão conta de serviço.

  • 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 como os 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 que executa para o Cloud Deploy. É possível alterar esse tempo limite na a especificação do ambiente de execução 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. 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 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 ao 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 pools particulares e dedicados que podem ser mais personalizados do que o worker padrão piscina. Essa personalização pode incluir a capacidade de acessar recursos de uma uma rede privada virtual. 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 reduzir escala vertical a zero, sem necessidade de configuração, 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 alterar o ambiente de execução do Cloud Deploy

É possível alterar o ambiente de execução do Cloud Deploy na 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 que essas operações sejam realizadas em um ambiente que não está à 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) somente 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 worker particular. pool de workers 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 o linha a seguir à definição do 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 alterar o nível de registro do Skaffold, CLI gcloud e kubectl, de seus respectivos padrões como 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 particular do Cloud Build para o ambiente de execução, e não no pool de workers padrão.

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

  • 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