Implementar imagens de contentores no Cloud Run

Esta página descreve como implementar imagens de contentores num novo serviço do Cloud Run ou numa nova revisão de um serviço do Cloud Run existente.

A imagem do contentor é importada pelo Cloud Run quando implementada. O Cloud Run mantém esta cópia da imagem do contentor enquanto for usada por uma revisão de publicação. As imagens de contentores não são extraídas do respetivo repositório de contentores quando é iniciada uma nova instância do Cloud Run.

Para ver um exemplo passo a passo da implementação de um novo serviço, consulte o Início rápido de implementação de um contentor de exemplo.

Antes de começar

Se estiver ao abrigo de uma política da organização de restrição de domínio que restringe as invocações não autenticadas para o seu projeto, tem de aceder ao serviço implementado conforme descrito em Testar serviços privados.

Funções necessárias

Para receber as autorizações de que precisa para implementar serviços do Cloud Run, peça ao seu administrador que lhe conceda as seguintes funções da IAM:

• Programador do Cloud Run (roles/run.developer) no serviço Cloud Run
• Utilizador da conta de serviço (roles/iam.serviceAccountUser) na identidade do serviço
• Leitor do Artifact Registry (roles/artifactregistry.reader) no repositório do Artifact Registry da imagem de contentor implementada
• Se estiver a usar uma conta de serviço entre projetos para implementar um serviço: Criador de tokens de contas de serviço (roles/iam.serviceAccountTokenCreator) na identidade do serviço

Para ver uma lista de funções e autorizações de IAM associadas ao Cloud Run, consulte os artigos Funções de IAM do Cloud Run e Autorizações de IAM do Cloud Run. Se o seu serviço do Cloud Run interage com Google Cloud APIs, como as bibliotecas cliente da Google Cloud, consulte o guia de configuração da identidade do serviço. Para mais informações sobre a atribuição de funções, consulte as autorizações de implementação e faça a gestão do acesso.

Imagens e registos de contentores suportados

Pode usar diretamente imagens de contentores armazenadas no Artifact Registry ou no Docker Hub. A Google recomenda a utilização do Artifact Registry. As imagens do Docker Hub são armazenadas em cache durante, no máximo, uma hora.

Pode usar imagens de contentores de outros registos públicos ou privados (como o JFrog Artifactory, o Nexus ou o GitHub Container Registry) configurando um repositório remoto do Artifact Registry.

Só deve considerar o Docker Hub para implementar imagens de contentores populares, como imagens oficiais do Docker ou imagens de OSS patrocinadas pelo Docker. Para uma maior disponibilidade, a Google recomenda a implementação destas imagens do Docker Hub através de um repositório remoto do Artifact Registry.

O Cloud Run não suporta camadas de imagens de contentores com mais de 9,9 GB quando implementa a partir do Docker Hub ou de um repositório remoto do Artifact Registry com um registo externo.

Implementar um novo serviço

Pode especificar uma imagem de contentor com uma etiqueta (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 implementação num serviço pela primeira vez cria a respetiva primeira revisão. Tenha em atenção que as revisões são imutáveis. Se fizer a implementação a partir de uma etiqueta de imagem de contentor, esta é resolvida para um resumo, e a revisão publica sempre este resumo específico.

Clique no separador para ver instruções sobre como usar a ferramenta da sua escolha.

Consola

Para implementar uma imagem de contentor:

1. Na Google Cloud consola, aceda à página do Cloud Run:

   Aceda ao Cloud Run

2. Selecione Serviços no menu e clique em Implementar contentor para apresentar o formulário Criar serviço.

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

      1. Se quiser implementar manualmente um contentor, selecione Implementar uma revisão a partir de uma imagem de contentor existente e especifique a imagem de contentor.

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

   2. Introduza o nome do serviço necessário. Os nomes dos serviços têm de ter 49 carateres ou menos e têm de ser exclusivos por região e projeto. Não é possível alterar posteriormente o nome do serviço, que é visível publicamente.

   3. Selecione a região onde quer que o seu serviço esteja localizado. O seletor de regiões indica o nível de preços, a disponibilidade de mapeamentos de domínios e realça as regiões com o impacto de carbono mais baixo.

   4. Defina a faturação conforme necessário.

   5. Em Escala do serviço, se usar a escala automática predefinida do Cloud Run, especifique opcionalmente o número mínimo de instâncias. Se usar o dimensionamento manual, especifique o número de instâncias para o serviço.

   6. Defina as definições de Ingress no formulário conforme necessário.

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

      • Se estiver a criar uma API ou um Website público, selecione Permitir acesso público. Se selecionar esta opção, atribui a função IAM Invoker ao identificador especial allUser. Pode usar o IAM para editar esta definição mais tarde, depois de criar o serviço.
      • Se quiser um serviço seguro protegido por autenticação, selecione Exigir autenticação.

3. Clique em Recipientes, volumes, rede, segurança para definir outras definições opcionais nos separadores adequados:

   • Concorrência
   • Configuração do contentor
   • Limites da CPU
   • Limites de memória
   • Limite de tempo do pedido
   • Segredos
   • Variáveis de ambiente
   • Ambiente de execução
   • HTTP/2
   • Contas de serviço
   • Ligações do Cloud SQL
   • Ligação VPC

4. Quando terminar de configurar o serviço, clique em Criar para implementar a imagem no Cloud Run e aguarde que a implementação termine.

5. Clique no link do URL apresentado para abrir o ponto final exclusivo e estável do serviço implementado.

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 implementar uma imagem de contentor:

   1. Execute o seguinte comando:

      gcloud run deploy SERVICE --image IMAGE_URL

      Substitua o seguinte:

      • SERVICE: o nome do serviço para o qual quer fazer a implementação. Os nomes dos serviços têm de ter 49 carateres ou menos e têm de ser exclusivos por região e projeto. Se o serviço ainda não existir, este comando cria o serviço durante a implementação. Pode omitir este parâmetro por completo, mas é-lhe pedido o nome do serviço se o omitir.
      • IMAGE_URL: uma referência à imagem do contentor, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se usar o Artifact Registry, o repositório REPO_NAMEtem de já estar criado. O URL segue o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG . Tenha em atenção que, se não fornecer a flag --image , o comando de implementação tenta implementar a partir do código fonte.

      Se estiver a criar uma API ou um Website públicos, permita o acesso público ao seu serviço através do sinalizador --allow-unauthenticated. Isto atribui a função de IAM Cloud Run Invoker a allUsers. Também pode especificar --no-allow-unauthenticated para não permitir o acesso público. Se omitir qualquer uma destas flags, é-lhe pedido que confirme quando o comando deploy é executado.

   2. Aguarde até que a implementação esteja concluída. Após a conclusão com êxito, é apresentada uma mensagem de êxito juntamente com o URL do serviço implementado.

   Tenha em atenção que, para fazer a implementação numa localização diferente da que definiu através das propriedades run/region gcloud, use:

   gcloud run deploy SERVICE --region REGION

YAML

Pode armazenar a especificação do serviço num ficheiro YAML e, em seguida, implementá-lo através da CLI gcloud.

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

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

   Substitua o seguinte:

   • SERVICE: o nome do seu serviço do Cloud Run. Os nomes dos serviços têm de ter 49 carateres ou menos e têm de ser exclusivos por região e projeto.
   • IMAGE: o URL da imagem do contentor.

   Também pode especificar mais configurações, como variáveis de ambiente ou limites de memória.

2. Implemente o novo serviço através do seguinte comando:

   gcloud run services replace service.yaml

3. Opcionalmente, torne o seu serviço público se quiser permitir o acesso não autenticado ao serviço.

Cloud Code

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

Terraform

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

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


  provider "google" {
    project = "PROJECT-ID"
  }

  resource "google_cloud_run_v2_service" "default" {
    name     = "SERVICE"
    location = "REGION"
    client   = "terraform"

    template {
      containers {
        image = "IMAGE_URL"
      }
    }
  }

  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"
  }

Substitua o seguinte:

• PROJECT-ID: o Google Cloud ID do projeto
• REGION: a Google Cloud região
• SERVICE: o nome do seu serviço do Cloud Run. Os nomes dos serviços têm de ter 49 carateres ou menos e têm de ser exclusivos por região e projeto.
• IMAGE_URL: uma referência à imagem do contentor, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se usar o Artifact Registry, o repositório REPO_NAMEtem de já estar criado. O URL segue o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

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

Bibliotecas cliente

Para implementar um novo serviço a partir de código:

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

API REST

Para implementar um novo serviço, envie um pedido HTTP POST para o ponto final service da API Admin do Cloud Run.

Por exemplo, usar 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 o seguinte:

• ACCESS_TOKEN: um token de acesso válido para uma conta que tenha as autorizações de IAM para implementar serviços. Por exemplo, se tiver sessão iniciada no gcloud, pode obter um token de acesso através de gcloud auth print-access-token. A partir de uma instância de contentor do Cloud Run, pode obter um token de acesso através do servidor de metadados da instância de contentor.
• IMAGE_URL: uma referência à imagem do contentor, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se usar o Artifact Registry, o repositório REPO_NAMEtem de já estar criado. O URL segue o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
• SERVICE: o nome do serviço para o qual quer implementar. Os nomes dos serviços têm de ter 49 carateres ou menos e têm de ser exclusivos por região e projeto.
• REGION: a Google Cloud região do serviço.
• PROJECT-ID: o Google Cloud ID do projeto.

Localizações do Cloud Run

O Cloud Run é regional, o que significa que a infraestrutura que executa os seus serviços do Cloud Run está localizada numa região específica e é gerida pela Google para estar disponível de forma redundante em todas as zonas dessa região.

O cumprimento dos requisitos de latência, disponibilidade ou durabilidade são fatores principais para selecionar a região onde os seus serviços do Cloud Run são executados. Geralmente, pode selecionar a região mais próxima dos seus utilizadores, mas deve considerar a localização dos outros Google Cloudprodutos usados pelo seu serviço do Cloud Run. A utilização Google Cloud de produtos em conjunto em várias localizações pode afetar a latência do seu serviço, bem como o custo.

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

Sujeito aos preços de Nível 1

• asia-east1 (Taiwan)
• asia-northeast1 (Tóquio)
• asia-northeast2 (Osaca)
• asia-south1 (Mumbai, Índia)
• europe-north1 (Finlândia) Baixo CO₂
• europe-north2 (Estocolmo) Baixo CO₂
• europe-southwest1 (Madrid) 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 (Telavive)
• northamerica-south1 (México)
• us-central1 (Iowa) Baixo CO₂
• us-east1 (Carolina do Sul)
• us-east4 (Virgínia do Norte)
• us-east5 (Columbus)
• us-south1 (Dallas) Baixo CO₂
• us-west1 (Oregão) Baixo CO₂

Sujeito aos preços de Nível 2

• africa-south1 (Joanesburgo)
• asia-east2 (Hong Kong)
• asia-northeast3 (Seul, Coreia do Sul)
• asia-southeast1 (Singapura)
• asia-southeast2 (Jacarta)
• asia-south2 (Deli, Í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)
• europe-west6 (Zurique, Suíça) Baixo CO₂
• me-central1 (Doha)
• me-central2 (Dammam)
• 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 já criou um serviço do Cloud Run, pode ver a região no painel de controlo do Cloud Run na Google Cloud consola.

OK

Implementar uma nova revisão de um serviço existente

Pode implementar uma nova revisão através da Google Cloud consola, da gcloudlinha de comando ou de um ficheiro de configuração YAML.

Tenha em atenção que a alteração de quaisquer definições de configuração resulta na criação de uma nova revisão, mesmo que não haja alterações à imagem do contentor. Cada revisão criada é imutável.

A imagem do contentor é importada pelo Cloud Run quando implementada. O Cloud Run mantém esta cópia da imagem do contentor enquanto for usada por uma revisão de publicação.

Clique no separador para ver instruções sobre como usar a ferramenta da sua escolha.

Consola

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

1. Na Google Cloud consola, aceda à página do Cloud Run:

   Aceda ao Cloud Run

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

3. Clique em Editar e implementar nova revisão para apresentar o formulário de implementação de revisões.

   1. Se necessário, indique o URL da nova imagem do contentor que quer implementar.

   2. Configure o contentor conforme necessário.

   3. Defina a faturação conforme necessário.

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

   5. Especifique o tempo limite do pedido e a simultaneidade, conforme necessário.

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

   7. Em Ajuste de escala automático, especifique o número de instâncias mínimo e máximo.

   8. Use os outros separadores, conforme necessário, para configurar opcionalmente:

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

4. Para enviar todo o tráfego para a nova revisão, selecione Publicar esta revisão imediatamente. Para implementar gradualmente uma nova revisão, desmarque essa caixa de verificação. Isto resulta numa implementação em que não é enviado tráfego para a nova revisão. Siga as instruções para implementações graduais após a implementação.

5. Clique em Implementar e aguarde até que a implementação esteja concluída.

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 implementar uma imagem de contentor:

   1. Execute o comando:

      gcloud run deploy SERVICE --image IMAGE_URL

      Substitua o seguinte:

      • SERVICE: o nome do serviço para o qual está a fazer a implementação. Pode omitir este parâmetro por completo, mas é-lhe pedido o nome do serviço se o omitir.
      • IMAGE_URL: uma referência à imagem do contentor, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se usar o Artifact Registry, o repositório REPO_NAMEtem de já estar criado. O URL segue 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 quiser fornecer o seu próprio sufixo de revisão, use o parâmetro --revision-suffix da CLI gcloud.

   2. Aguarde até que a implementação esteja concluída. Após a conclusão com êxito, é apresentada uma mensagem de êxito juntamente com o URL do serviço implementado.

YAML

Aviso: as instruções seguintes substituem a configuração do serviço existente pela especificada no ficheiro YAML. Assim, se usar YAML para fazer alterações de revisão, deve evitar usar também a Google Cloud consola ou a CLI gcloud para fazer alterações de configuração, uma vez que estas podem ser substituídas quando usa YAML.

Se precisar de transferir ou ver a configuração de um serviço existente, use o seguinte comando para guardar os resultados num ficheiro YAML:

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

A partir de um ficheiro YAML de configuração do serviço, modifique os atributos filhos spec.template conforme necessário para atualizar as definições de revisão e, em seguida, implemente a nova revisão:

gcloud run services replace service.yaml

Cloud Code

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

Terraform

Certifique-se de que configurou o Terraform conforme descrito no exemplo Implementar um novo serviço.

1. Faça uma alteração ao ficheiro de configuração.

2. Aplique a configuração do Terraform:

   terraform apply

   Confirme que quer aplicar as ações descritas introduzindo yes.

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

Bibliotecas cliente

Para implementar uma nova revisão a partir do código:

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

API REST

Para implementar uma nova revisão, envie um pedido HTTP PATCH para o ponto final da service API Cloud Run Admin.

Por exemplo, usar 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 o seguinte:

• ACCESS_TOKEN: um token de acesso válido para uma conta que tenha as autorizações de IAM para implementar revisões. Por exemplo, se tiver sessão iniciada no gcloud, pode obter um token de acesso através de gcloud auth print-access-token. A partir de uma instância de contentor do Cloud Run, pode obter um token de acesso através do servidor de metadados da instância de contentor.
• IMAGE_URL: uma referência à imagem do contentor, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se usar o Artifact Registry, o repositório REPO_NAMEtem de já estar criado. O URL segue o formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
• SERVICE: o nome do serviço para o qual está a fazer a implementação.
• REGION: a Google Cloud região do serviço.
• PROJECT-ID: o Google Cloud ID do projeto.

Localizações do Cloud Run

O Cloud Run é regional, o que significa que a infraestrutura que executa os seus serviços do Cloud Run está localizada numa região específica e é gerida pela Google para estar disponível de forma redundante em todas as zonas dessa região.

O cumprimento dos requisitos de latência, disponibilidade ou durabilidade são fatores principais para selecionar a região onde os seus serviços do Cloud Run são executados. Geralmente, pode selecionar a região mais próxima dos seus utilizadores, mas deve considerar a localização dos outros Google Cloudprodutos usados pelo seu serviço do Cloud Run. A utilização Google Cloud de produtos em conjunto em várias localizações pode afetar a latência do seu serviço, bem como o custo.

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

Sujeito aos preços de Nível 1

• asia-east1 (Taiwan)
• asia-northeast1 (Tóquio)
• asia-northeast2 (Osaca)
• asia-south1 (Mumbai, Índia)
• europe-north1 (Finlândia) Baixo CO₂
• europe-north2 (Estocolmo) Baixo CO₂
• europe-southwest1 (Madrid) 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 (Telavive)
• northamerica-south1 (México)
• us-central1 (Iowa) Baixo CO₂
• us-east1 (Carolina do Sul)
• us-east4 (Virgínia do Norte)
• us-east5 (Columbus)
• us-south1 (Dallas) Baixo CO₂
• us-west1 (Oregão) Baixo CO₂

Sujeito aos preços de Nível 2

• africa-south1 (Joanesburgo)
• asia-east2 (Hong Kong)
• asia-northeast3 (Seul, Coreia do Sul)
• asia-southeast1 (Singapura)
• asia-southeast2 (Jacarta)
• asia-south2 (Deli, Í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)
• europe-west6 (Zurique, Suíça) Baixo CO₂
• me-central1 (Doha)
• me-central2 (Dammam)
• 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 já criou um serviço do Cloud Run, pode ver a região no painel de controlo do Cloud Run na Google Cloud consola.

OK

Implementar imagens de outros Google Cloud projetos

Para implementar imagens de outros Google Cloud projetos, o administrador ou o utilizador tem de conceder à conta de implementação e ao agente de serviço do Cloud Run as funções de IAM necessárias.

Para ver as funções necessárias para a conta de implementação, consulte as funções necessárias.

Para conceder ao agente do serviço do Cloud Run as funções necessárias, consulte as seguintes instruções:

1. Na Google Cloud consola, abra o projeto do seu serviço do Cloud Run.

   Aceda à página IAM

2. Selecione Incluir concessões de funções fornecidas pela Google.

3. Copie o email do agente do serviço do Cloud Run. Tem o sufixo @serverless-robot-prod.iam.gserviceaccount.com

4. Abra o projeto proprietário do registo de contentores que quer usar.

   Aceda à página IAM

5. Clique em Adicionar para adicionar um novo principal.

6. No campo Novos membros, cole o email da conta de serviço que copiou anteriormente.

7. No menu pendente Selecionar uma função, clique em Artifact Registry -> Artifact Registry Reader.

8. Implemente a imagem do contentor no projeto que contém o seu serviço do Cloud Run.

   Nota: para uma segurança mais forte, conceda acesso ao repositório do Artifact Registry que contém as suas imagens de contentores.

Implementar imagens de outros registos

Para implementar imagens de contentores 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-lhe:

• Implementar qualquer imagem de contentor pública, por exemplo, o registo de contentores do GitHub (ghcr.io).
• Implemente imagens de contentores a partir de repositórios privados que exijam autenticação, por exemplo, o JFrog Artifactory ou o Nexus.

Em alternativa, se não for possível usar um repositório remoto do Artifact Registry, pode extrair e enviar temporariamente imagens de contentores para o Artifact Registry usando o docker push para as implementar no Cloud Run. A imagem do contentor é importada pelo Cloud Run quando é implementada. Por isso, após a implementação, pode eliminar a imagem do Artifact Registry.

Implementar vários contentores num serviço (sidecars)

Numa implementação do Cloud Run com sidecars, existe um contentor de entrada que processa todos os pedidos HTTPS recebidos na PORTA do contentor que especificar, e existem um ou mais contentores sidecar. Os sidecars não podem ouvir os pedidos HTTP recebidos na porta do contentor de entrada, mas podem comunicar entre si e com o contentor de entrada através de uma porta localhost. A porta localhost usada varia consoante os contentores que estiver a usar.

No diagrama seguinte, o contentor de entrada está a comunicar com o sidecar através de localhost:5000.

Pode implementar até 10 contentores por instância, incluindo o contentor de entrada. Todos os contentores numa instância partilham o mesmo espaço de nomes de rede e também podem partilhar ficheiros através de um volume partilhado na memória, conforme mostrado no diagrama.

Pode implementar vários contentores no ambiente de execução de primeira ou segunda geração.

Se usar a faturação baseada em pedidos (a predefinição do Cloud Run), os sidecars recebem CPU apenas nestes cenários:

• A instância está a processar, pelo menos, um pedido.
• O contentor de entrada está a ser iniciado.

Se o seu sidecar tiver de usar a CPU fora do processamento de pedidos (por exemplo, para a recolha de métricas), configure a definição de faturação para a faturação baseada em instâncias para o seu serviço. Para mais informações, consulte o artigo Definições de faturação (serviços).

Se usar a faturação baseada em pedidos, configure uma sondagem de arranque para garantir que o sidecar não tem restrições de CPU no arranque.

Pode exigir que todas as implementações usem um sidecar específico criando políticas de organização personalizadas.

Exemplos de utilização

Os exemplos de utilização de sidecars num serviço do Cloud Run incluem:

• Monitorização, registo e rastreio de aplicações
• Usar o Nginx, o Envoy ou o Apache2 como um proxy à frente do contentor da aplicação
• Adicionar filtros de autenticação e autorização (por exemplo, Open Policy Agent)
• Executar proxies de ligação de saída, como o proxy Auth do AlloyDB

Implementar um serviço com contentores auxiliares

Pode implementar vários sidecars num serviço do Cloud Run através da Google Cloud consola, da Google Cloud CLI, de YAML ou do Terraform.

Clique no separador para ver instruções sobre como usar a ferramenta da sua escolha.

Consola

1. Na Google Cloud consola, aceda à página do Cloud Run:

   Aceda ao Cloud Run

   • Para implementar num serviço existente, localize-o na lista de serviços e clique em para abrir e, de seguida, clique em Editar e implementar uma nova revisão para apresentar o formulário de implementação de revisões.
   • Selecione Serviços no menu e clique em Implementar contentor para apresentar o formulário Criar serviço.

2. Para um novo serviço:

   1. Indique o nome do serviço e o URL da imagem do contentor de entrada que quer implementar.
   2. Clique em Recipientes, volumes, trabalhar em rede, segurança

3. No cartão Editar contentor, configure o contentor de entrada conforme necessário.

4. Clique em Adicionar contentor e configure um contentor sidecar que quer adicionar juntamente com o contentor de entrada. Se o sidecar depender de outro contentor no serviço, indique-o no menu pendente Ordem de arranque do contentor. Repita este passo para cada contentor auxiliar que está a implementar.

5. Para enviar todo o tráfego para a nova revisão, selecione Publicar esta revisão imediatamente. Para uma implementação gradual, desmarque essa caixa de verificação. Isto resulta numa implementação em que não é enviado tráfego para a nova revisão. Siga as instruções para implementações graduais após a implementação.

6. Clique em Criar para um novo serviço ou em Implementar para um serviço existente. Em seguida, aguarde que a implementação termine.

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 implementar vários contentores num 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 o seguinte:

   • SERVICE: o nome do serviço para o qual está a fazer a implementação. Pode omitir este parâmetro por completo, mas é-lhe pedido o nome do serviço se o omitir.
   • INGRESS_CONTAINER_NAME: um nome para o contentor que recebe pedidos, por exemplo, app.
   • INGRESS_IMAGE: uma referência à imagem do contentor que deve receber pedidos, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
   • CONTAINER_PORT: a porta onde o contentor de entrada ouve os pedidos recebidos. Ao contrário de um serviço de contentor único, para um serviço que contenha sidecars, não existe uma porta predefinida para o contentor de entrada. Tem de configurar explicitamente a porta do contentor para o contentor de entrada e apenas um contentor pode ter a porta exposta.
   • SIDECAR_CONTAINER_NAME: um nome para o contentor auxiliar, por exemplo, sidecar.
   • SIDECAR_IMAGE: uma referência à imagem do contentor auxiliar

   Se quiser configurar cada contentor no comando de implementação, forneça a configuração de cada contentor 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: quando usa a flag --container, tem de especificar todas as flags que não sejam ao nível do contentor antes das flags ao nível do contentor. Caso contrário, o comando de implementação falha com uma mensagem de erro nesse sentido. Por exemplo, no comando "gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G", a flag --execution-environment tem de ser transmitida antes da flag --container.

3. Aguarde até que a implementação esteja concluída. Após a conclusão com êxito, é apresentada uma mensagem de êxito juntamente com o URL do serviço implementado.

YAML

Estas instruções mostram um ficheiro YAML básico para o seu serviço do Cloud Run com sidecars. Crie um ficheiro com o nome service.yaml e adicione o seguinte:

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
      

Substitua o seguinte:

• SERVICE: o nome do seu serviço do Cloud Run. Os nomes dos serviços têm de ter 49 carateres ou menos.
• CONTAINER_PORT: a porta onde o contentor de entrada ouve os pedidos recebidos. Ao contrário de um serviço de contentor único, para um serviço que contenha sidecars, não existe uma porta predefinida para o contentor de entrada. Tem de configurar explicitamente a porta do contentor para o contentor de entrada e apenas um contentor pode ter a porta exposta.
• INGRESS_IMAGE: uma referência à imagem do contentor que deve receber pedidos, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
• SIDECAR_IMAGE: uma referência à imagem do contentor auxiliar. Pode especificar vários sidecars adicionando mais elementos ao conjunto containers no YAML.

Depois de atualizar o YAML para incluir os contentores de entrada e auxiliares, implemente-o no Cloud Run através do comando:

gcloud run services replace service.yaml

Terraform

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

Adicione o seguinte a um recurso google_cloud_run_v2_service na sua 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 onde o contentor de entrada ouve os pedidos recebidos. Ao contrário de um serviço de contentor único, para um serviço que contenha sidecars, não existe uma porta predefinida para o contentor de entrada. Tem de configurar explicitamente a porta do contentor para o contentor de entrada e apenas um contentor pode ter a porta exposta.

Funcionalidades notáveis disponíveis para implementações com sidecars

Pode especificar a ordem de início do contentor numa implementação com vários contentores, se tiver dependências que exijam que alguns contentores sejam iniciados antes de outros contentores na implementação.

Se tiver contentores que dependam de outros contentores, tem de usar verificações de estado na sua implementação. Se usar verificações de estado, o Cloud Run segue a ordem de início do contentor e inspeciona o estado de cada contentor, garantindo que cada um é aprovado com êxito antes de o Cloud Run iniciar o contentor seguinte na ordem. Se não usar verificações de saúde, os contentores saudáveis são iniciados mesmo que os contentores dos quais dependem não estejam em execução.

Vários contentores numa única instância podem aceder a um volume na memória partilhado, que é acessível a cada contentor através de pontos de montagem que cria.

O que se segue?

Depois de implementar um novo serviço, pode fazer o seguinte:

• Implementações graduais, reversão de revisões e migração de tráfego
• Veja registos de serviço
• Monitorize o desempenho dos serviços
• Defina limites de memória
• Defina variáveis de ambiente
• Altere a simultaneidade do serviço
• Faça a gestão do serviço
• Faça a gestão das revisões de serviços
• Exemplo de sidecar do OpenTelemetry do Cloud Run
• Implemente apenas imagens fidedignas com a autorização binária (pré-visualização)

Pode automatizar as compilações e as implementações dos seus serviços do Cloud Run através dos acionadores do Cloud Build:

• Configure a implementação contínua

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

• Implemente uma app no Cloud Run através do Cloud Deploy