Visão geral das funções do Cloud Run

O ato de implantar uma função do Cloud Run coordena automaticamente os serviços do Google Cloud , incluindo o Cloud Storage, o Cloud Build e o Artifact Registry, para empacotar e executar seu código. Entender essas interações de serviço ajuda a configurar as permissões necessárias do Identity and Access Management, rastrear dependências de recursos e resolver problemas de implantação ou build.

Antes de começar

Conheça os conceitos de implantação de origem e do Cloud Run functions no guia Opções de implantação e modelo de recursos do Cloud Run.

Informações gerais da arquitetura

Quando você implanta o código-fonte da função no Cloud Run functions, ele é armazenado 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 do Artifact Registry. As funções do Cloud Run acessam essa imagem quando precisam gerar o contêiner para executar sua função.

No diagrama a seguir, a caixa do Cloud Run functions representa uma função implantada no Cloud Run usando a API Cloud Run Admin ou a API Cloud Functions. Normalmente, as funções mais recentes são implantadas usando a API Cloud Run Admin, e as mais antigas são implantadas usando a API Cloud Functions.

Figura 1. Um usuário prepara o código-fonte das funções e o implanta no Cloud Run.

Dependendo da API usada ao implantar uma função, ocorre o seguinte:

• Se você implantou sua função usando a API Cloud Run Admin, o seguinte vai acontecer:

  1. O upload do código-fonte é feito em um bucket do Cloud Storage que não tem período de armazenamento.

     1. Se você estiver usando a criptografia padrão, o nome do bucket será gerado automaticamente e chamado de run-sources-PROJECT_ID-REGION.
     2. Se você estiver protegendo seus dados com chaves de criptografia gerenciadas pelo cliente (CMEK), o nome do bucket não será gerado automaticamente, e você precisará fornecer um nome de bucket.

  2. O código-fonte é enviado ao Cloud Build, em que os buildpacks do Google Cloud e o Functions Framework criam uma imagem de contêiner. A conta de serviço do Cloud Build cria a imagem do contêiner. Por padrão, o Cloud Run usa o tipo de máquina e2-standard-2 fornecido pelo Cloud Build.

  3. Em seguida, a imagem do contêiner é enviada para o Artifact Registry por um bucket criado automaticamente chamado REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy.

  4. A imagem é implantada no Cloud Run como um serviço.

  5. É possível acionar ou invocar a função com o Eventarc, o Pub/Sub ou outros gatilhos HTTP.

• Se você implantou sua função usando a API Cloud Functions (v2), o seguinte vai acontecer:

  1. O upload do código-fonte é feito em um bucket do Cloud Storage que não tem período de armazenamento.

     O nome do bucket é gerado automaticamente e segue este formato:

     1. Se você estiver usando a criptografia padrão, esse bucket será chamado de gcf-v2-sources-PROJECT_NUMBER-REGION.
     2. Se você estiver protegendo seus dados com CMEK, o bucket será chamado de gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.

  2. O código-fonte é enviado ao Cloud Build, em que os buildpacks do Google Cloud e o Functions Framework criam uma imagem de contêiner. A conta de serviço do Cloud Build cria a imagem do contêiner. Por padrão, o Cloud Run usa o tipo de máquina e2-standard-2 fornecido pelo Cloud Build.

  3. Em seguida, a imagem do contêiner é enviada para o Artifact Registry por um bucket criado automaticamente chamado REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts.

  4. A imagem é implantada no Cloud Run como um serviço.

  5. É possível acionar ou invocar a função com o Eventarc, o Pub/Sub ou outros gatilhos HTTP.

A seguir

• Aprenda mais sobre os diferentes tipos de funções e as opções para acionar funções.
• Se você já criou funções com a API Cloud Functions, consulte o guia de comparação do Cloud Run functions para aprender mais sobre as diferenças entre as duas versões do Cloud Run functions.