Usar ambientes de execução do Cloud Deploy

Um ambiente de execução do Cloud Deploy é o ambiente no qual o Cloud Deploy executa as respetivas operações de renderização, pré-implementação, implementação, validação e pós-implementação. O ambiente de execução é composto pelos seguintes componentes:

  • O conjunto de trabalhadores do Cloud Build (predefinido ou privado) no qual o Cloud Deploy executa as operações de renderização, pré-implementação, implementação, validação e pós-implementação

  • A conta de serviço (predefinida ou alternativa) que chama o Cloud Deploy para realizar estas ações

  • A localização de armazenamento (predefinida ou alternativa) dos manifestos renderizados no Cloud Storage

  • O limite de tempo do Cloud Build para operações (predefinido ou personalizado)

Este artigo descreve o ambiente de execução predefinido, as contas de serviço e o armazenamento do Cloud Deploy, bem como o motivo e a forma como pode alterar estas predefinições.

Predefinições

Seguem-se as predefinições que o Cloud Deploy usa para executar, para executar a renderização e a implementação, e para armazenar recursos, como manifestos renderizados:

  • Conjunto de trabalhadores predefinido

    Por predefinição, o Cloud Deploy é executado no conjunto de trabalhadores do Cloud Build predefinido. No entanto, pode configurar o Cloud Deploy para usar um pool de trabalhadores privado do Cloud Build.

    Para mais detalhes sobre os worker pools, consulte o artigo Vista geral dos pools predefinidos e dos pools privados do Cloud Build.

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

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

  • Localização de armazenamento predefinida do Cloud Deploy

    Este valor é o contentor do Cloud Storage onde o Cloud Deploy armazena os seus manifestos renderizados. Por predefinição, o Cloud Deploy cria um contentor do Cloud Storage na mesma região que os recursos do Cloud Deploy, com o seguinte formato:

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

  • Predefinição do limite de tempo do Cloud Build

    Por predefinição, o Cloud Build tem um limite de tempo de 1 hora nas operações que realiza para o Cloud Deploy. Pode alterar esse limite de tempo na especificação do ambiente de execução na configuração de destino.

  • Nível de detalhe predefinido para o Skaffold, a CLI gcloud e o kubectl

    Por predefinição, os níveis de registo destas ferramentas estão definidos para as respetivas predefinições, normalmente warn ou o equivalente. Pode alterar esta definição para debug ou o equivalente.

As secções que se seguem descrevem as circunstâncias em que deve alterar qualquer um destes valores e incluem links para instruções sobre como o fazer.

Acerca dos grupos de trabalhadores do Cloud Build

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

  • O pool predefinido do Cloud Build

    O conjunto de trabalhadores predefinido é um ambiente seguro e alojado com acesso à Internet pública. As operações de renderização, implementação, pré-implementação, pós-implementação e validação são executadas nesse conjunto, isoladas de outras cargas de trabalho.

  • Uma piscina privada

    Os pools de trabalhadores privados são pools privados e dedicados que podem ser mais personalizados do que o pool de trabalhadores predefinido. Essa personalização pode incluir a capacidade de aceder a recursos numa rede privada. Tal como o conjunto de trabalhadores predefinido, os conjuntos de trabalhadores privados são alojados e totalmente geridos pelo Cloud Build. Estes pools podem ser aumentados ou reduzidos até zero, sem infraestrutura para configurar, atualizar ou dimensionar.

    A vista geral das pools privadas do Cloud Build descreve as pools de trabalhadores predefinidas e as pools de trabalhadores privadas de forma mais detalhada, incluindo uma tabela que compara as respetivas funcionalidades.

Alterar o ambiente de execução do Cloud Deploy

Pode alterar o ambiente de execução da implementação na nuvem nas seguintes circunstâncias:

  • Quer implementar num cluster privado do Google Kubernetes Engine

  • Quer que as operações de renderização, implementação, pré-implementação, pós-implementação ou verificação, ou uma combinação das cinco, sejam realizadas num ambiente isolado de outras organizações.

  • Quer que estas operações sejam realizadas num ambiente que não esteja ligado à Internet pública.

  • Quer ambientes separados para renderização e implementação.

  • Quer usar uma conta de serviço dedicada com autorizações mais específicas para a sua utilização do que as autorizações disponíveis na conta de serviço predefinida.

  • Quiser armazenar manifestos renderizados numa localização diferente do contentor do Cloud Storage predefinido.

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

Alterar do conjunto predefinido para um conjunto privado

Configura os conjuntos de trabalhadores por destino, para que o conjunto seja usado para RENDER, DEPLOY, PREDEPLOY, POSTDEPLOY ou VERIFY (ou uma combinação dos cinco) apenas para esse destino.

Para usar o grupo de trabalhadores predefinido para operações de renderização e implementação, não tem de fazer nada.

Segue-se uma configuração de destino de exemplo que especifica um conjunto de trabalhadores privado para DEPLOY e o conjunto de trabalhadores predefinido 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 privados para alvos, consulte a documentação de configuração do pipeline de entrega.

Alterar da conta de serviço de execução predefinida para uma personalizada

Tal como acontece com o conjunto de trabalhadores, pode especificar uma conta de serviço alternativa a usar para a renderização ou a implementação (ou ambas) por destino. Para tal, 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 tem de incluir a função clouddeploy.jobRunner, conforme descrito no documento Contas de serviço do Cloud Deploy.

Consulte o artigo Definições de alvos para ver mais detalhes sobre esta configuração.

Alterar a localização de armazenamento

Para alterar o contentor de armazenamento da predefinição do Cloud Deploy, adicione a seguinte linha à definição do destino na secção workerPool:

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

Esta configuração altera o local onde os manifestos renderizados são armazenados, mas não afeta o local onde a origem da renderização é armazenada.

Alterar o nível de registo do Skaffold, da CLI gcloud e do kubectl

Para alterar o nível de registo do Skaffold, da CLI gcloud e do kubectl, dos respetivos valores predefinidos para debug (ou o equivalente), defina verbose como true nas configurações de execução. Segue-se um exemplo:

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

Usar o Cloud Deploy num perímetro dos VPC Service Controls

O Cloud Deploy suporta os VPC Service Controls.

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

Limitações

  • Tem de usar um conjunto de trabalhadores privado do Cloud Build para o ambiente de execução do destino e não o conjunto de trabalhadores predefinido.

  • O projeto que contém o conjunto de trabalhadores e o projeto que contém os seus recursos do Cloud Deploy têm de permanecer no mesmo perímetro de segurança do VPC Service Controls.

  • Qualquer cluster do GKE que implementar no perímetro do VPC Service Controls tem de ser um cluster privado.

    Para configurar um pool privado para um cluster privado, consulte este tutorial.

O que se segue?