Visão geral do processo de build

Quando você implanta o código-fonte da função do Cloud Run, essa origem é armazenada em um bucket do Cloud Storage. Em seguida, o Cloud Build cria automaticamente seu código em uma imagem de contêiner e a envia para um registro de imagens. As funções do Cloud Run acessam essa imagem quando precisam gerar o contêiner para executar sua função. Se a função ainda usa o Container Registry, mude para o Artifact Registry o mais rápido possível.

O processo de criação da imagem é totalmente automático e você não precisa intervir nele. Todos os recursos usados no processo de compilação são executados no próprio projeto do usuário.

Executar o processo de compilação dentro do projeto significa que:

• você tem acesso direto a todos os registros do build;

• não há uma cota de tempo de compilação predefinida, embora o Cloud Build tenha uma cota de simultaneidade padrão própria;

• É possível ver a imagem do contêiner atual e a imagem do contêiner implantada anteriormente, que são armazenadas no Artifact Registry.

• O Cloud Storage é usado diretamente no projeto, e o diretório de código-fonte das funções é armazenado em um bucket dentro do projeto. Observações:

  • Se você estiver usando a criptografia padrão, esse bucket será chamado de gcf-sources-PROJECT_NUMBER-REGION.
  • Se você estiver protegendo seus dados com CMEK, o bucket será chamado de gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.
  • O bucket não tem período de armazenamento.

Características do processo de compilação

O processo de compilação tem as seguintes características:

• A API Cloud Build precisa estar ativada no projeto.

  Para ativar a API manualmente, clique no link acima, selecione seu projeto no menu suspenso e siga as instruções para ativar a interface.

• Como todo o processo de compilação ocorre dentro do contexto do projeto, este está sujeito aos preços dos recursos incluídos:

  • Para preços do Cloud Build, consulte a página Preços. Esse processo usa o tamanho padrão da instância do Cloud Build, já que essas instâncias são pré-montadas e ficam disponíveis mais rapidamente. O Cloud Build oferece um nível gratuito: consulte o documento de preços para mais detalhes.

  • Para preços do Cloud Storage, consulte a página Preços. O Cloud Storage oferece um nível gratuito. Veja mais detalhes no documento de preços.

  • Para preços do Artifact Registry, consulte a página Preços.

  • Para preços do Container Registry (descontinuado), consulte a página Preços.

• Como o processo de compilação está sujeito ao faturamento, o projeto precisa ter uma Conta de faturamento do Cloud anexada a ele.

Ver os registros de imagem do build

Um dos principais benefícios de ter o processo de imagem do build no projeto de usuário é o acesso aos registros do build. Use a CLI gcloud ou o console do Google Cloud para acessar os registros, que estão disponíveis no Cloud Logging.

Registro de imagens

As funções do Cloud Run usam o Artifact Registry para armazenar as imagens criadas com o código-fonte da função. As imagens são armazenadas em um repositório chamado REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts localizado no mesmo projeto em que a função é criada.

Para especificar um repositório autogerenciado do Artifact Registry, execute o seguinte comando:

gcloud functions deploy FUNCTION \
  --docker-registry=artifact-registry \
  --docker-repository=REPOSITORY \
  [FLAGS...]

Mudar para o Artifact Registry

As funções podem publicar imagens no Artifact Registry mudando as configurações do repositório:

gcloud beta functions deploy FUNCTION \
  --docker-registry=artifact-registry \
  [FLAGS...]

Para informações detalhadas sobre preços, consulte Preços das funções do Cloud Run.

Proteger o build com pools particulares

Para permitir que suas funções usem dependências (por exemplo, pacotes npm), o Cloud Build tem, por padrão, acesso ilimitado à Internet durante o processo de criação. Se você tiver configurado um perímetro de VPC Service Controls (VPC SC) e quiser limitar o acesso da compilação apenas às dependências armazenadas dentro do perímetro, poderá usar o recurso Pools de workers particulares do Cloud Build.

Em geral, siga estas etapas para configurar seu pool privado:

1. Crie seu pool de workers privados. Consulte Como criar e gerenciar pools particulares.

2. Configure o perímetro do VPC Service Controls. Consulte Como usar o VPC Service Controls.

3. Se o pool de workers privados estiver em um projeto diferente da função, você precisará conceder a conta de serviço Agente de serviço (service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com) das funções do Cloud Run cloudbuild.workerPoolUser para que o serviço do Cloud Build possa acessar o pool de workers.

   gcloud projects add-iam-policy-binding PRIVATE_POOL_PROJECT_ID \
       --member serviceAccount:service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
       --role roles/cloudbuild.workerPoolUser

   em que FUNCTION_PROJECT_NUMBER é o número do projeto em que a função é executada e PRIVATE_POOL_PROJECT_ID é o id do projeto em que o worker pool está localizado. Consulte Como executar versões em um pool particular para mais informações.

4. Implante a função para criar usando um pool particular:

gcloud functions deploy FUNCTION_NAME \
  --runtime RUNTIME \
  --build-worker-pool PRIVATE_POOL_NAME
  [FLAGS...]

gcloud functions deploy FUNCTION_NAME \
  --runtime RUNTIME \
  --clear-build-worker-pool
  [FLAGS...]

Proteger o build com uma conta de serviço personalizada

As funções do Cloud Run usam o código-fonte e o enviam ao Cloud Build para ser conteinerizado. A função conteinerizada é armazenada no Artifact Registry e implantada no Cloud Run como um serviço. Por padrão, o Cloud Build atribui uma conta de serviço para atuar como principal ao executar o build. A partir de julho de 2024, os novos projetos em uma organização vão usar a conta de serviço padrão do Compute Engine como a principal para executar um build. Para mais detalhes, consulte Mudança na conta de serviço padrão do Cloud Build. Por motivos de segurança, a conta de serviço padrão do Compute Engine não tem permissões suficientes para executar o build.

Para projetos do Google Cloud criados antes de julho de 2024, o Cloud Build usa a conta de serviço legada do Cloud Build. Essa conta de serviço foi projetada para ajudar os usuários a executar uma ampla variedade de casos de uso que podem ser muito permissivos para as necessidades do seu projeto. Se você quiser mover seus projetos atuais para fora dessa conta de serviço, siga as etapas abaixo para aumentar a segurança do ambiente de build de funções:

1. Impeça que a conta de serviço legada do Cloud Build seja usada para o build.
2. Impeça que a conta de serviço de computação padrão seja usada para o build.
3. Configure uma nova conta de serviço com permissões de escopo adequado para serem usadas no build.
4. Use a conta de serviço configurada para o build.

Impedir que a conta de serviço legada do Cloud Build seja usada para build

É possível verificar se o projeto está usando a conta de serviço herdada do Cloud Build inspecionando os detalhes do build da função. A conta de serviço de build padrão tem o seguinte formato:

PROJECT_NUMBER@cloudbuild.gserviceaccount.com.

É possível desativar o uso dessa conta de serviço definindo a restrição de política da organização cloudbuild.useBuildServiceAccount como Not Enforced. Como alternativa, remover todas as permissões de função vai limitar a capacidade de acessar os recursos do Google Cloud.

Impedir que a conta de serviço de computação padrão seja usada para build

A conta de serviço padrão do Compute tem o formato PROJECT_NUMBER-compute@developer.gserviceaccount.com. Para desativar o padrão usado para o build, defina a política da organização cloudbuild.useComputeServiceAccount como Not Enforced. Outra opção é desativar essa conta de serviço para que ela não seja usada para acessar recursos do Google Cloud.

Fornecer uma conta de serviço para criar funções

Como parte da configuração de uma função, uma conta de serviço do build pode ser especificada ao implantar a função. Quando a conta de serviço legada do Cloud Build e a conta de serviço de computação padrão não podem ser usadas para build, é necessário especificar uma conta de serviço de build para implantar uma função.

Consulte Conta de serviço personalizada para o Cloud Build para saber como configurar e usar uma conta de serviço de build para sua função.