Como criar imagens do Cloud Functions

Visão geral

Quando você implanta o código-fonte da função no Cloud Functions, essa origem é armazenada em um bucket do Cloud Storage. Em seguida, o Cloud Build cria o código automaticamente em uma imagem de contêiner e envia essa imagem para o Container Registry. O Cloud Functions acessa essa imagem quando precisa executar o contêiner para executar a função.

O processo de criação da imagem é totalmente automático e você não precisa intervir nele. No entanto, há uma pequena diferença entre o processo para os ambientes de execução mais antigos do Node.js 8 e do Go 1.11 e o processo atual para todos os outros ambientes de execução: Java 11, Python 3.7, Python 3.8, Node.js 10 e Go 1.13.

Ambientes de execução do Node.js 8 e do Go 1.11

Nos ambientes de execução mais antigos, o processo de compilação não ocorre no projeto do usuário, mas em um projeto relacionado chamado de locatário. A execução do build em um projeto de locatário resolveu alguns problemas associados a esses ambientes de execução, mas também gerou alguns novos problemas:

  • Como a versão não ocorre no seu projeto, você não tem acesso aos registros do build para classificar qualquer problema que possa encontrar.

  • Esse processo requer uma cota interna de tempo de compilação diária que, em algumas circunstâncias bastante comuns, pode ser esgotada. Isso pode limitar a capacidade de implantar qualquer código-fonte novo até que a cota seja renovada.

  • Você não tem acesso ao Container Registry, onde a imagem do contêiner da função está armazenada. Portanto, não é possível ver as imagens disponíveis.

Ambientes de execução mais recentes

Para ambientes de execução mais recentes que não foram mencionados acima, como Java 11+, Python 3.7+, Node.js 10+ e Go 1.13+, todos os recursos usados no processo de criação agora são executados no próprio projeto do usuário, e não no projeto de locatário. Agora esse é o processo padrão.

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 Container Registry;

  • como o Cloud Storage é usado diretamente no projeto, o diretório de código-fonte das funções fica visível em um bucket chamado gcf-sources-<PROJECT_NUMBER>-<REGION>.

Características do processo padrão

Como resultado dessa alteração, todos os ambientes de execução que usam o processo padrão terão as seguintes características:

  • A API Cloud Build precisa estar ativada no projeto.

    Para ativar a API manualmente, clique no link acima, selecione o projeto no menu suspenso e clique em Continuar.

  • 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 Container Registry, 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.

Como acessar 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 Cloud para acessar os registros, que estão disponíveis no Cloud Logging.

gcloud

  1. Implante a função usando o comando gcloud functions deploy.

  2. O URL dos registros é mostrado como parte da resposta na janela do terminal. Exemplo:

    Deploying function (may take a while - up to 2 minutes)...⠹
    **For Cloud Build Stackdriver Logs**, visit:
    https://console.cloud.google.com/logs/viewer?project=&advancedFilter=resource.type%
    3Dbuild%0Aresource.labels.build_id%3D38d5b662-2315-45dd-8aa2-
    380d50d4f5e8%0AlogName%3Dprojects%2F%
    2Flogs%2Fcloudbuild
    Deploying function (may take a while - up to 2 minutes)...done.
    

Console do Cloud

  1. Na tela Funções, clique no Nome da função em que você tem interesse. A página Detalhes da função é aberta.

  2. Role a página para baixo até ver a seção Criação de contêiner. Se o build não tiver erros, você verá um link que pode ser acessado para exibir o registro do build. Se o build tiver erros, como você verá abaixo, a seção Criação de contêiner os mostrará in-line. Clique em Saiba mais para exibir o registro do build diretamente.

    Captura de tela que mostra a saída da seção &quot;Criação de contêiner&quot;

  3. A tela Visualizador de registros é aberta. Clique na entrada em que você tem interesse.

  4. A entrada de registro do build completa é aberta, mostrando o arquivo afetado, uma descrição do erro (nesse caso, uma chave ausente em pom.xml e a linha e coluna do erro).

    Captura de tela que mostra a entrada de registro do build

Como proteger seu 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) do Cloud Functions 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

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

    em que FUNCTION_NAME é o nome da função, RUNTIME é o ambiente de execução que você está usando e PRIVATE_POOL_NAME é o nome do seu pool.

    Para interromper o uso de um determinado pool particular e usar o pool padrão do Cloud Build, use a sinalização --clear-build-worker-pool ao reimplantar.

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

    em que FUNCTION_NAME é o nome da função e RUNTIME é o ambiente de execução que você está usando.

    Console do Cloud

    Na seção Create function, na seção Runtime, build and connections settings, selecione a guia Build e insira o PRIVATE_POOL_NAME na caixa de texto Build worker pools Selected environment, em que PRIVATE_POOL_NAME é o nome do seu pool.

    Captura de tela do Console do Cloud