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 paradebug
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 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
Saiba mais sobre a configuração de destino do Cloud Deploy.
Leia sobre pools particulares do Cloud Build.
Leia sobre como o Cloud Build usa o VPC Service Controls.
Saiba como o Cloud Deploy usa contas de serviço.
Acessar clusters particulares do GKE com pools particulares do Cloud Build.