Como implantar imagens de contêiner no Cloud Run

Nesta página, descrevemos como implantar imagens de contêiner em um novo serviço do Cloud Run ou em uma nova revisão de um serviço do Cloud Run.

A imagem do contêiner é importada pelo Cloud Run quando implantada. O Cloud Run mantém essa cópia da imagem do contêiner enquanto ela for usada por uma revisão de exibição. As imagens de contêiner não são extraídas do repositório de contêineres quando uma nova instância do Cloud Run é iniciada.

Para conferir um exemplo de instruções de implantação de um novo serviço, consulte o Guia de início rápido sobre como implantar um contêiner de amostra.

Antes de começar

Se você precisa seguir uma política da organização de restrição de domínio que restringe invocações não autenticadas para seu projeto, será necessário acessar o serviço implantado, conforme descrito em Como testar serviços particulares.

Funções exigidas

Para receber as permissões necessárias para implantar os serviços do Cloud Run, peça ao administrador para conceder a você os seguintes papéis do IAM:

• Desenvolvedor do Cloud Run (roles/run.developer) no serviço Cloud Run
• Usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço
• Leitor do Artifact Registry (roles/artifactregistry.reader) no repositório do Artifact Registry da imagem do contêiner implantada (se aplicável)

Para uma lista de papéis e permissões do IAM associados ao Cloud Run, consulte Papéis do IAM do Cloud Run e Permissões do IAM do Cloud Run. Se o serviço do Cloud Run interage com as APIs do Google Cloud, como as bibliotecas de cliente do Cloud, consulte o guia de configuração de identidade de serviço. Para mais informações sobre como conceder papéis, consulte permissões de implantação e gerenciar acesso.

Registros e imagens de contêiner compatíveis

É possível usar diretamente imagens de contêiner armazenadas no Artifact Registry ou no Docker Hub (em inglês). O Google recomenda o uso do Artifact Registry.

É possível usar imagens de contêiner de outros registros públicos ou privados (como JFrog Artifactory, Nexus ou GitHub Container Registry), configurando um repositório remoto do Artifact Registry.

Considere apenas o Docker Hub para implantar imagens de contêiner conhecidas, como Imagens oficiais do Docker ou Imagens do OSS patrocinadas pelo Docker. Para maior disponibilidade, o Google recomenda implantar essas imagens do Docker Hub usando um repositório remoto do Artifact Registry.

Como implantar um novo serviço

É possível especificar uma imagem de contêiner com uma tag (por exemplo, us-docker.pkg.dev/my-project/container/my-image:latest) ou com um resumo exato (por exemplo, us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...).

A implantação de um serviço pela primeira vez cria a primeira revisão dele. Observe que as revisões são imutáveis. Se você implantar a partir de uma tag de imagem de contêiner, ela será resolvida para um resumo, e a revisão sempre exibirá esse resumo específico.

Clique na guia para ver instruções usando a ferramenta de sua preferência.

Console

Para implantar uma imagem de contêiner:

1. No console do Google Cloud, acesse a página do Cloud Run:

   Acessar o Cloud Run

2. Clique em Implantar contêiner e selecione Serviço para exibir o formulário Criar serviço.

   1. No formulário, selecione a opção de implantação:

      1. Se você quiser implantar um contêiner manualmente, selecione Implantar uma revisão de uma imagem de contêiner atual e especifique a imagem.

      2. Se você quiser automatizar a implantação contínua, selecione Implantar continuamente novas revisões de um repositório de origem e siga as instruções para implantações contínuas.

   2. Insira o nome do serviço necessário. Os nomes dos serviços precisam ter 49 caracteres ou menos e ser exclusivos por região e projeto. Não é possível alterar o nome de um serviço depois e ele fica visível publicamente.

   3. Selecione a região em que você quer que o serviço esteja localizado. O seletor de região indica o nível de preço, a disponibilidade de mapeamentos de domínio e destaca regiões com o impacto de carbono mais baixo.

   4. Defina a alocação e os preços de CPU conforme necessário.

   5. Em Escalonamento automático, especifique as instâncias mínima e máxima.

   6. Defina as configurações de Entrada no formato conforme necessário.

   7. Em Autenticação, configure o seguinte:

      • Se você estiver criando uma API ou um site público, selecione Permitir invocações não autenticadas. A seleção atribui o papel de chamador do IAM ao identificador especial allUser. É possível usar o IAM para editar essa configuração depois de criar o serviço.
      • Se você quiser que um serviço seguro seja protegido por autenticação, selecione Exigir autenticação.

3. Clique em Contêiner(s), volumes, rede, segurança para definir outras configurações opcionais nas guias apropriadas:

   • Simultaneidade
   • Configuração do contêiner
   • Limites de CPU
   • Limites de memória
   • Tempo limite da solicitação
   • Secrets
   • Variáveis de ambiente
   • Ambiente de execução
   • HTTP/2
   • Contas de serviço
   • Conexões do Cloud SQL
   • Conexão VPC

4. Após concluir a configuração do serviço, clique em Criar para implantar a imagem no Cloud Run e aguarde a conclusão da implantação.

5. Clique no link do URL exibido para abrir o endpoint exclusivo e estável do serviço implantado.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Para implantar uma imagem de contêiner, realize as etapas a seguir:

   1. Execute este comando:

      gcloud run deploy SERVICE --image IMAGE_URL

      • Substitua SERVICE pelo nome do serviço em que você quer implantar. Os nomes dos serviços precisam ter 49 caracteres ou menos e ser exclusivos por região e projeto. Se o serviço ainda não existir, esse comando criará o serviço durante a implantação. É possível omitir esse parâmetro inteiramente, mas será solicitado o nome do serviço, se você omiti-lo.
      • IMAGE_URL por uma referência à imagem de contêiner, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest; Se você usa o Artifact Registry, o repositório REPO_NAME já precisará ter sido criado. O URL tem o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG Se você não fornecer a sinalização --image, o comando de implantação tentará implantar a partir do código-fonte.

      Se você estiver criando uma API ou um site públicos, permita invocações não autenticadas do serviço usando a sinalização --allow-unauthenticated. Isso atribui o papel do IAM de Chamador do Cloud Run a allUsers. Também é possível especificar --no-allow-unauthenticated para impedir invocações não autenticadas. Se você omitir qualquer uma dessas sinalizações, será solicitado a confirmar quando o comando deploy é executado.

   2. Aguarde a conclusão da implantação. Após a conclusão bem-sucedida, uma mensagem de sucesso é exibida com o URL do serviço implantado.

   Para implantar em um local diferente daquele que você definiu por meio das propriedades run/region gcloud, use:

   gcloud run deploy SERVICE --region REGION

YAML

É possível armazenar a especificação do serviço em um arquivo YAML e implantá-la usando a CLI gcloud.

1. Crie um novo arquivo service.yaml com o seguinte conteúdo:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE
   spec:
     template:
       spec:
         containers:
         - image: IMAGE

   Substituir

   • SERVICE pelo nome do serviço do Cloud Run; Os nomes dos serviços precisam ter 49 caracteres ou menos e ser exclusivos por região e projeto.
   • IMAGE pelo URL da imagem de contêiner.

   Também é possível definir outras configurações, como variáveis de ambiente ou limites de memória.

2. Implante o novo serviço usando o seguinte comando:

   gcloud run services replace service.yaml

3. Como opção, torne seu serviço público se você quiser permitir o acesso não autenticado ao serviço.

Cloud Code

Para implantar com o Cloud Code, leia os guias do IntelliJ e do Visual Studio Code.

Terraform

Se você usar o Terraform, defina seu serviço em uma configuração do Terraform usando o recurso google_cloud_run_v2_service do Provedor do Google Cloud Platform (todos em inglês).

1. Crie um novo arquivo main.tf com este conteúdo:

   provider "google" {
     project = "PROJECT-ID"
   }
   
   resource "google_cloud_run_v2_service" "default" {
     name     = "SERVICE"
     location = "REGION"
     client   = "terraform"
   
     template {
       containers {
         image = "IMAGE"
       }
     }
   }
   
   resource "google_cloud_run_v2_service_iam_member" "noauth" {
     location = google_cloud_run_v2_service.default.location
     name     = google_cloud_run_v2_service.default.name
     role     = "roles/run.invoker"
     member   = "allUsers"
   }
   

   Substituir

   • PROJECT-ID pelo ID do projeto do Google Cloud.
   • REGION pela região do Google Cloud.
   • SERVICE pelo nome do serviço do Cloud Run; Os nomes dos serviços precisam ter 49 caracteres ou menos e ser exclusivos por região e projeto.
   • IMAGE_URL por uma referência à imagem de contêiner. Por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se você usa o Artifact Registry, o repositório REPO_NAME já precisará ter sido criado. O URL tem o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

   Essa configuração permite acesso público (o equivalente a --allow-unauthenticated). Para tornar o serviço privado, remova a estrofe google_cloud_run_v2_service_iam_member.

2. Inicialize o Terraform:

   terraform init

3. Aplique a configuração do Terraform:

   terraform apply

   Confirme que você quer aplicar as ações descritas digitando yes.

Bibliotecas de cliente

Para criar um novo serviço usando código, siga estas etapas:

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• .NET

API REST

Para implantar um novo serviço, envie uma solicitação HTTP POST ao endpoint service da API Cloud Run Admin.

Por exemplo, usando curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X POST \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE

Substitua:

• ACCESS_TOKEN por um token de acesso válido para uma conta com as permissões do IAM para implantar serviços. Por exemplo, se você fez login no gcloud, é possível recuperar um token de acesso usando gcloud auth print-access-token. Em uma instância de contêiner do Cloud Run, é possível recuperar um token de acesso por meio do servidor de metadados da instância de contêiner.
• IMAGE_URL por uma referência à imagem de contêiner. Por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se você usa o Artifact Registry, o repositório REPO_NAME já precisará ter sido criado. O URL tem o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
• SERVICE pelo nome do serviço em que você quer implantar. Os nomes dos serviços precisam ter 49 caracteres ou menos e ser exclusivos por região e projeto.
• REGION pela região do Google Cloud do serviço.
• PROJECT-ID pelo ID do projeto do Google Cloud.

Locais do Cloud Run

O Cloud Run é regional, o que significa que a infraestrutura que executa seus serviços do Cloud Run está localizada em uma região específica e é gerenciada pelo Google para estar disponível de maneira redundante em todas as zonas da região.

Atender aos seus requisitos de latência, disponibilidade ou durabilidade são os principais fatores para selecionar a região em que seus serviços do Cloud Run são executados. Geralmente, é possível selecionar a região mais próxima de seus usuários, mas considere a localização dos outros produtos do Google Cloud usados pelo serviço do Cloud Run. O uso de produtos do Google Cloud em vários locais pode afetar a latência e o custo do serviço.

O Cloud Run está disponível nas regiões a seguir:

Sujeitas aos preços do nível 1

• asia-east1 (Taiwan)
• asia-northeast1 (Tóquio)
• asia-northeast2 (Osaka)
• asia-south1 (Mumbai, Índia)
• europe-north1 (Finlândia) Baixo CO₂
• europe-southwest1 (Madri) Baixo CO₂
• europe-west1 (Bélgica) Baixo CO₂
• europe-west4 (Países Baixos) Baixo CO₂
• europe-west8 (Milão)
• europe-west9 (Paris) Baixo CO₂
• me-west1 (Tel Aviv)
• us-central1 (Iowa) Baixo CO₂
• us-east1 (Carolina do Sul)
• us-east4 (Norte da Virgínia)
• us-east5 (Columbus)
• us-south1 (Dallas) Baixo CO₂
• us-west1 (Oregon) Baixo CO₂

Sujeitas aos preços do nível 2

• africa-south1 (Johannesburgo)
• asia-east2 (Hong Kong)
• asia-northeast3 (Seul, Coreia do Sul)
• asia-southeast1 (Singapura)
• asia-southeast2 (Jacarta)
• asia-south2 (Déli, Índia)
• australia-southeast1 (Sydney)
• australia-southeast2 (Melbourne)
• europe-central2 (Varsóvia, Polônia)
• europe-west10 (Berlim) Baixo CO₂
• europe-west12 (Turim)
• europe-west2 (Londres, Reino Unido) Baixo CO₂
• europe-west3 (Frankfurt, Alemanha) Baixo CO₂
• europe-west6 (Zurique, Suíça) Baixo CO₂
• me-central1 (Doha)
• me-central2 (Damã)
• northamerica-northeast1 (Montreal) Baixo CO₂
• northamerica-northeast2 (Toronto) Baixo CO₂
• southamerica-east1 (São Paulo, Brasil) Baixo CO₂
• southamerica-west1 (Santiago, Chile) Baixo CO₂
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

Se você já criou um serviço do Cloud Run, é possível visualizar a região no painel do Cloud Run no console do Google Cloud.

OK

Como implantar uma nova revisão de um serviço atual

É possível implantar uma nova revisão usando o Console do Google Cloud, a linha de comando gcloud ou um arquivo de configuração YAML.

A alteração de qualquer configuração resulta na criação de uma nova revisão, mesmo que não haja alterações na imagem do contêiner. Cada revisão criada é imutável.

A imagem do contêiner é importada pelo Cloud Run quando implantada. O Cloud Run mantém essa cópia da imagem do contêiner enquanto ela for usada por uma revisão de exibição.

Clique na guia para ver instruções usando a ferramenta de sua preferência.

Console

Para implantar uma nova revisão de um serviço existente:

1. No console do Google Cloud, acesse a página do Cloud Run:

   Acessar o Cloud Run

2. Localize o serviço que você quer atualizar na lista de serviços e clique nele para abrir os detalhes.

3. Clique em Editar e implantar nova revisão para exibir o formulário de implantação da revisão.

   1. Se necessário, forneça o URL para a nova imagem do contêiner que você quer implantar.

   2. Configure o contêiner conforme necessário.

   3. Defina a alocação e os preços de CPU conforme necessário.

   4. Em Capacidade, especifique limites de memória e limites de CPU.

   5. Especifique o tempo limite da solicitação e a simultaneidade conforme necessário.

   6. Especifique o ambiente de execução conforme necessário.

   7. Em Escalonamento automático, especifique as instâncias mínima e máxima.

   8. Use as outras guias conforme necessário para configurar opcionalmente:

      • Secrets
      • Variáveis de ambiente
      • HTTP/2
      • Contas de serviço
      • Conexões do Cloud SQL
      • Conexão VPC

4. Para enviar todo o tráfego para a nova revisão, selecione Veicular esta revisão imediatamente. Para lançar uma nova revisão gradualmente, desmarque essa caixa de seleção. Isso resulta em uma implantação em que nenhum tráfego é enviado para a nova revisão. Siga as instruções para os lançamentos graduais após a implantação.

5. Clique em Implantar e aguarde a conclusão da implantação.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Para implantar uma imagem de contêiner, realize as etapas a seguir:

   1. Execute o comando:

      gcloud run deploy SERVICE --image IMAGE_URL

      • Substitua SERVICE pelo nome do serviço que você está implantando. É possível omitir esse parâmetro inteiramente, mas será solicitado o nome do serviço, se você omiti-lo.
      • IMAGE_URL por uma referência à imagem de contêiner, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest; Se você usa o Artifact Registry, o repositório REPO_NAME já precisará ter sido criado. O URL tem o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

      O sufixo de revisão é atribuído automaticamente para novas revisões. Se você quiser fornecer seu próprio sufixo de revisão, use o parâmetro de CLI gcloud revision-suffix.

   2. Aguarde a conclusão da implantação. Após a conclusão bem-sucedida, uma mensagem de sucesso é exibida com o URL do serviço implantado.

YAML

Cuidado: as instruções a seguir substituem a configuração de serviço existente pela especificada no arquivo YAML. Portanto, se você usa o YAML para fazer alterações de revisão, evite também usar o console do Google Cloud ou a linha de comando para fazer alterações de configuração porque elas podem ser substituídas quando você usa o YAML.

Se você precisar fazer o download ou visualizar a configuração de um serviço existente, use o seguinte comando para salvar os resultados em um arquivo YAML:

gcloud run services describe SERVICE --format export > service.yaml

Em um arquivo YAML de configurações de serviço, modifique qualquer atributo filho spec.template conforme necessário para atualizar as configurações de revisão. Em seguida, implante a nova revisão:

gcloud run services replace service.yaml

Cloud Code

Para implantar uma nova revisão de um serviço existente com o Cloud Code, leia os guias do IntelliJ e do Visual Studio Code.

Terraform

Configure o Terraform conforme descrito no exemplo Como implantar um novo serviço.

1. Faça uma alteração no arquivo de configuração.

2. Aplique a configuração do Terraform:

   terraform apply

   Confirme que você quer aplicar as ações descritas digitando yes.

   Observação: a menos que uma alteração de configuração seja necessária, nenhuma nova revisão será criada.

Bibliotecas de cliente

Para implantar uma nova revisão do código:

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• .NET

API REST

Para implantar uma nova revisão, envie uma solicitação HTTP PATCH para o endpoint service da API Cloud Run Admin.

Por exemplo, usando curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X PATCH \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE

Substitua:

• ACCESS_TOKEN por um token de acesso válido para uma conta com as permissões do IAM para implantar revisões. Por exemplo, se você fez login no gcloud, é possível recuperar um token de acesso usando gcloud auth print-access-token. Em uma instância de contêiner do Cloud Run, é possível recuperar um token de acesso por meio do servidor de metadados da instância de contêiner.
• IMAGE_URL por uma referência à imagem de contêiner. Por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se você usa o Artifact Registry, o repositório REPO_NAME já precisará ter sido criado. O URL tem o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
• SERVICE pelo nome do serviço que você está implantando.
• REGION pela região do Google Cloud do serviço.
• PROJECT-ID pelo ID do projeto do Google Cloud.

Locais do Cloud Run

O Cloud Run é regional, o que significa que a infraestrutura que executa seus serviços do Cloud Run está localizada em uma região específica e é gerenciada pelo Google para estar disponível de maneira redundante em todas as zonas da região.

Atender aos seus requisitos de latência, disponibilidade ou durabilidade são os principais fatores para selecionar a região em que seus serviços do Cloud Run são executados. Geralmente, é possível selecionar a região mais próxima de seus usuários, mas considere a localização dos outros produtos do Google Cloud usados pelo serviço do Cloud Run. O uso de produtos do Google Cloud em vários locais pode afetar a latência e o custo do serviço.

O Cloud Run está disponível nas regiões a seguir:

Sujeitas aos preços do nível 1

• asia-east1 (Taiwan)
• asia-northeast1 (Tóquio)
• asia-northeast2 (Osaka)
• asia-south1 (Mumbai, Índia)
• europe-north1 (Finlândia) Baixo CO₂
• europe-southwest1 (Madri) Baixo CO₂
• europe-west1 (Bélgica) Baixo CO₂
• europe-west4 (Países Baixos) Baixo CO₂
• europe-west8 (Milão)
• europe-west9 (Paris) Baixo CO₂
• me-west1 (Tel Aviv)
• us-central1 (Iowa) Baixo CO₂
• us-east1 (Carolina do Sul)
• us-east4 (Norte da Virgínia)
• us-east5 (Columbus)
• us-south1 (Dallas) Baixo CO₂
• us-west1 (Oregon) Baixo CO₂

Sujeitas aos preços do nível 2

• africa-south1 (Johannesburgo)
• asia-east2 (Hong Kong)
• asia-northeast3 (Seul, Coreia do Sul)
• asia-southeast1 (Singapura)
• asia-southeast2 (Jacarta)
• asia-south2 (Déli, Índia)
• australia-southeast1 (Sydney)
• australia-southeast2 (Melbourne)
• europe-central2 (Varsóvia, Polônia)
• europe-west10 (Berlim) Baixo CO₂
• europe-west12 (Turim)
• europe-west2 (Londres, Reino Unido) Baixo CO₂
• europe-west3 (Frankfurt, Alemanha) Baixo CO₂
• europe-west6 (Zurique, Suíça) Baixo CO₂
• me-central1 (Doha)
• me-central2 (Damã)
• northamerica-northeast1 (Montreal) Baixo CO₂
• northamerica-northeast2 (Toronto) Baixo CO₂
• southamerica-east1 (São Paulo, Brasil) Baixo CO₂
• southamerica-west1 (Santiago, Chile) Baixo CO₂
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

Se você já criou um serviço do Cloud Run, é possível visualizar a região no painel do Cloud Run no console do Google Cloud.

OK

Como implantar imagens de outros projetos do Google Cloud

É possível implantar imagens de contêiner de outros projetos do Google Cloud se você definir as permissões corretas do IAM:

1. No console do Google Cloud, abra o projeto do serviço do Cloud Run.

   Acessar a página do IAM

2. Selecione Incluir concessões de papel fornecidas pelo Google.

3. Copie o e-mail do agente de serviço do Cloud Run. Ele tem o sufixo @serverless-robot-prod.iam.gserviceaccount.com.

4. Abra o projeto com o registro do contêiner que você quer usar.

   Acessar a página do IAM

5. Clique em Adicionar para adicionar um novo principal.

6. No campo Novos principais, cole o e-mail da conta de serviço que você copiou anteriormente.

7. No menu suspenso Selecionar um papel, se você estiver usando o Container Registry, selecione o papel Armazenamento -> Leitor de objetos do Storage. Se você estiver usando o Artifact Registry, selecione o papel Artifact Registry -> Artifact Registry Reader.

8. Implante a imagem do contêiner no projeto que contém o serviço do Cloud Run.

   Observação :para aumentar a segurança, conceda acesso apenas ao bucket do Cloud Storage ou ao repositório do Artifact Registry que contém as imagens de contêiner.

Como implantar imagens de outros registros

Para implantar imagens de contêiner públicas ou privadas que não estejam armazenadas no Artifact Registry ou no Docker Hub, configure um repositório remoto do Artifact Registry.

Os repositórios remotos do Artifact Registry permitem:

• Implante qualquer imagem de contêiner pública, por exemplo, o Container Registry do GitHub (ghcr.io).
• Implante imagens de contêiner de repositórios privados que exigem autenticação, por exemplo, JFrog Artifactory ou Nexus.

Como alternativa, se não for possível usar um repositório remoto do Artifact Registry, é possível extrair e enviar imagens de contêiner temporariamente para o Artifact Registry usando docker push para implantá-las no Cloud Run. A imagem do contêiner é importada pelo Cloud Run quando implantada, de modo que, depois da implantação, é possível excluir a imagem do Artifact Registry.

Como implantar vários contêineres a um serviço (arquivos secundários)

Em uma implantação do Cloud Run com arquivos secundários, há um contêiner de entrada que processa todas as solicitações HTTPS de entrada na porta do contêiner especificada, e há um ou mais contêineres de arquivo secundário. Os arquivos secundários não podem detectar as solicitações HTTP de entrada na porta do contêiner de entrada, mas podem se comunicar entre si e com o contêiner de entrada usando uma porta localhost. A porta do localhost usada varia de acordo com os contêineres usados.

No diagrama a seguir, o contêiner de entrada se comunica com o arquivo secundário usando localhost:5000.

É possível implantar até 10 contêineres por instância, incluindo o contêiner de entrada. Todos os contêineres em uma instância compartilham o mesmo namespace de rede e também podem compartilhar arquivos por meio do volume compartilhado na memória, conforme mostrado no diagrama.

É possível implantar vários contêineres no ambiente de execução de primeira ou segunda geração.

Por padrão, os sidecars só são alocados com CPU quando a instância está processando pelo menos uma solicitação. Se você precisar que seu arquivo secundário possa usar a CPU fora processamento de solicitações (por exemplo, para coleta de métricas), configure seu serviço para ter a CPU sempre alocada. Para mais informações, consulte Alocação de CPU (serviços).

Você pode exigir que todas as implantações usem um sidecar específico criando políticas de organização personalizadas.

Casos de uso

Os casos de uso de arquivos secundários em um serviço do Cloud Run incluem:

• Monitoramento, geração de registros e rastreamento de aplicativos
• Como usar o Nginx, Envoy ou Apache2 como proxy na frente do contêiner do aplicativo
• Adicionar filtros de autenticação e autorização (por exemplo, Open Policy Agent)
• Como executar proxies de conexão de saída, como o proxy do Alloy DB Auth

Como implantar um serviço com contêineres de arquivos secundários

É possível implantar vários arquivos secundários em um serviço do Cloud Run usando o console do Google Cloud, a CLI do Google Cloud, o YAML ou o Terraform.

Clique na guia para ver instruções usando a ferramenta de sua preferência.

Console

1. No console do Google Cloud, acesse a página do Cloud Run:

   Acessar o Cloud Run

   • Para implantar em um serviço existente, localize-o na lista de serviços e clique para abri-lo. Em seguida, clique em EDITAR E IMPLANTAR NOVA REVISÃO para exibir o formulário de implantação de revisão.
   • Clique em Implantar contêiner e selecione Serviço para exibir o formulário Criar serviço.

2. Para um novo serviço,

   1. Forneça o nome do serviço e o URL para a imagem do contêiner de entrada que você quer implantar.
   2. Clique em Contêiner(s), volumes, rede, segurança

3. No card Editar contêiner, configure o contêiner de entrada conforme necessário.

4. Clique em Adicionar contêiner e configure o contêiner de arquivo secundário que você quer adicionar com o contêiner de entrada. Se o arquivo secundário depender de outro contêiner no serviço, indique isso no menu suspenso Ordem de inicialização do contêiner. Repita essa etapa para cada contêiner de arquivo secundário que estiver implantando.

5. Para enviar todo o tráfego para a nova revisão, selecione Veicular esta revisão imediatamente. Para um lançamento gradual, desmarque essa caixa de seleção. Isso resulta em uma implantação em que nenhum tráfego é enviado para a nova revisão. Siga as instruções para os lançamentos graduais após a implantação.

6. Clique em Criar para um novo serviço ou Implantar para um serviço atual e aguarde a conclusão da implantação.

gcloud

Os parâmetros container na Google Cloud CLI estão em pré-lançamento.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Para implantar vários contêineres em um serviço, execute o seguinte comando:

   gcloud run deploy SERVICE \
    --container INGRESS_CONTAINER_NAME \
    --image='INGRESS_IMAGE' \
    --port='CONTAINER_PORT' \
    --container SIDECAR_CONTAINER_NAME \
    --image='SIDECAR_IMAGE'

   Substitua:

   • SERVICE pelo nome do serviço que você está implantando. É possível omitir esse parâmetro inteiramente, mas será solicitado o nome do serviço, se você omiti-lo.
   • INGRESS_CONTAINER_NAME por um nome para o contêiner que recebe solicitações, por exemplo, app.
   • INGRESS_IMAGE por uma referência à imagem de contêiner que vai receber solicitações, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
   • CONTAINER_PORT pela porta em que o contêiner de entrada detecta solicitações recebidas. Ao contrário de um serviço de contêiner único, para um serviço com arquivos secundários, não há uma porta padrão para o contêiner de entrada. É necessário configurar explicitamente a porta do contêiner para o contêiner de entrada, e apenas um contêiner pode expor a porta.
   • SIDECAR_CONTAINER_NAME por um nome para o contêiner do arquivo secundário, por exemplo, sidecar.
   • SIDECAR_IMAGE por uma referência à imagem de contêiner de arquivo secundário

   Se você quiser configurar cada contêiner no comando de implantação, forneça a configuração de cada contêiner após os parâmetros container, por exemplo:

   gcloud run deploy SERVICE \
     --container CONTAINER_1_NAME \
     --image='INGRESS_IMAGE' \
     --set-env-vars=KEY=VALUE \
     --port='CONTAINER_PORT' \
     --container SIDECAR_CONTAINER_NAME \
     --image='SIDECAR_IMAGE' \
     --set-env-vars=KEY_N=VALUE_N

   Importante: ao usar a flag --container, é necessário especificar todas as flags que não estejam no nível do contêiner antes das flags no nível do contêiner. Caso contrário, o implantar falha com uma mensagem de erro. Por exemplo, no comando "gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G", a flag --execution-environment precisa ser transmitida antes da flag --container.

3. Aguarde a conclusão da implantação. Após a conclusão bem-sucedida, uma mensagem de sucesso é exibida com o URL do serviço implantado.

YAML

Estas instruções mostram um arquivo YAML básico para o serviço do Cloud Run com arquivos secundários. Crie um arquivo chamado service.yaml e adicione o seguinte a ele:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE
      

Substituir

• SERVICE pelo nome do serviço do Cloud Run; Os nomes dos serviços precisam ter 49 caracteres ou menos.
• CONTAINER_PORT pela porta em que o contêiner de entrada detecta solicitações recebidas. Ao contrário de um serviço de contêiner único, para um serviço com arquivos secundários, não há uma porta padrão para o contêiner de entrada. É necessário configurar explicitamente a porta do contêiner para o contêiner de entrada, e apenas um contêiner pode expor a porta.
• INGRESS_IMAGE por uma referência à imagem de contêiner que vai receber solicitações, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
• SIDECAR_IMAGE por uma referência à imagem de contêiner de arquivo secundário. É possível especificar vários arquivos secundários adicionando mais elementos containers à matriz no YAML.

Depois de atualizar o YAML para incluir os contêineres de entrada e de arquivo secundário, implante no Cloud Run usando o comando:

gcloud run services replace service.yaml

Terraform

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

Adicione o seguinte a um recurso google_cloud_run_v2_service na configuração do Terraform.

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  ingress = "INGRESS_TRAFFIC_ALL"
  template {
    containers {
      name = "INGRESS_CONTAINER_NAME"
      ports {
        container_port = CONTAINER_PORT
      }
      image = "INGRESS_IMAGE"
      depends_on = ["SIDECAR_CONTAINER_NAME"]
    }
    containers {
      name = "SIDECAR_CONTAINER_NAME"
      image = "SIDECAR_IMAGE"
      }
    }
  }

O CONTAINER_PORT representa a porta em que o contêiner de entrada detecta solicitações recebidas. Ao contrário de um serviço de contêiner único, para um serviço com arquivos secundários, não há uma porta padrão para o contêiner de entrada. É necessário configurar explicitamente a porta do contêiner para o contêiner de entrada, e apenas um contêiner pode expor a porta.

Recursos importantes disponíveis para implantações com arquivos secundários

É possível especificar a ordem de inicialização do contêiner em uma implantação com vários contêineres se você tiver dependências que exigem que alguns contêineres sejam iniciados antes de outros na implantação.

Se você tiver contêineres que dependam de outros contêineres, use verificações de integridade na implantação. Se você usar verificações de integridade, o Cloud Run seguirá a ordem de inicialização do contêiner e inspecionará a integridade de cada contêiner, garantindo que cada um seja aprovado com sucesso antes que o Cloud Run inicie o próximo contêiner no pedido. Se você não usar verificações de integridade, os contêineres íntegros serão iniciados mesmo que os contêineres de que dependem não estejam em execução.

Vários contêineres em uma única instância podem acessar um volume na memória compartilhado, acessível a cada contêiner por meio dos pontos de montagem criados.

A seguir

Depois de implantar um novo serviço, é possível realizar estas ações:

• Reversões, lançamentos graduais e migração de tráfego
• Visualizar registros de serviço
• Monitorar o desempenho do serviço
• Definir limites de memória
• Definir as variáveis de ambiente
• Alterar a simultaneidade do serviço
• Gerenciar o serviço
• Gerenciar revisões de serviço
• Exemplo de arquivo secundário do Cloud Run OpenTelemetry
• Implantar somente imagens confiáveis com a autorização binária (Visualizar)

Automatize as compilações e as implantações dos serviços do Cloud Run usando os gatilhos do Cloud Build:

• Configurar implantação contínua

Também é possível usar o Cloud Deploy para configurar um pipeline de entrega contínua que implanta serviços do Cloud Run em vários ambientes:

• Implantar um app no Cloud Run usando o Cloud Deploy