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.
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
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, realize as etapas a seguir:
Clique em Criar serviço para exibir o formulário Criar serviço.
No formulário, selecione a opção de implantação:
Se você quiser implantar um contêiner manualmente, selecione Implantar uma revisão de uma imagem de contêiner atual e especifique a imagem.
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.
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.
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.
Defina a alocação e os preços de CPU conforme necessário.
Em Escalonamento automático, especifique as instâncias mínima e máxima.
Defina as configurações de Entrada no formato conforme necessário.
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.
- 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
Clique em Contêiner(s), volumes, rede, segurança para definir outras configurações opcionais nas guias apropriadas:
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.
Clique no link do URL exibido para abrir o endpoint exclusivo e estável do serviço implantado.
gcloud
-
No Console do Google Cloud, ative o Cloud Shell.
Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.
Para implantar uma imagem de contêiner, realize as etapas a seguir:
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 formatoLOCATION-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 aallUsers
. 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 comandodeploy
é executado.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.
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.
Implante o novo serviço usando o seguinte comando:
gcloud run services replace service.yaml
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).
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" }
Substitua:
- 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 formatoLOCATION-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 estrofegoogle_cloud_run_v2_service_iam_member
.Inicialize o Terraform:
terraform init
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:
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 formatoLOCATION-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)europe-north1
(Finlândia)Baixo CO2
europe-southwest1
(Madri)Baixo CO2
europe-west1
(Bélgica)Baixo CO2
europe-west4
(Países Baixos)Baixo CO2
europe-west8
(Milão)europe-west9
(Paris)Baixo CO2
me-west1
(Tel Aviv)us-central1
(Iowa)Baixo CO2
us-east1
(Carolina do Sul)us-east4
(Norte da Virgínia)us-east5
(Columbus)us-south1
(Dallas)Baixo CO2
us-west1
(Oregon)Baixo CO2
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-south1
(Mumbai, Índia)asia-south2
(Déli, Índia)australia-southeast1
(Sydney)australia-southeast2
(Melbourne)europe-central2
(Varsóvia, Polônia)europe-west10
(Berlim)Baixo CO2
europe-west12
(Turim)europe-west2
(Londres, Reino Unido)Baixo CO2
europe-west3
(Frankfurt, Alemanha)Baixo CO2
europe-west6
(Zurique, Suíça)Baixo CO2
me-central1
(Doha)me-central2
(Damã)northamerica-northeast1
(Montreal)Baixo CO2
northamerica-northeast2
(Toronto)Baixo CO2
southamerica-east1
(São Paulo, Brasil)Baixo CO2
southamerica-west1
(Santiago, Chile)Baixo CO2
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.
Durante a implantação, o agente de serviço do Cloud Run precisa acessar o contêiner implantado, que é o caso por padrão.
Cada serviço tem um URL exclusivo e permanente que não muda ao longo do tempo à medida que você implanta novas revisões nele.
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.
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 atual, realize as etapas a seguir:
Localize o serviço que você quer atualizar na lista de serviços e clique nele para abrir os detalhes.
Clique em Editar e implantar nova revisão para exibir o formulário de implantação da revisão.
Se necessário, forneça o URL para a nova imagem do contêiner que você quer implantar.
Configure o contêiner conforme necessário.
Defina a alocação e os preços de CPU conforme necessário.
Em Capacidade, especifique limites de memória e limites de CPU.
Especifique o tempo limite da solicitação e a simultaneidade conforme necessário.
Especifique o ambiente de execução conforme necessário.
Em Escalonamento automático, especifique as instâncias mínima e máxima.
Use as outras guias conforme necessário para configurar opcionalmente:
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.
Clique em Implantar e aguarde a conclusão da implantação.
gcloud
-
No Console do Google Cloud, ative o Cloud Shell.
Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.
Para implantar uma imagem de contêiner, realize as etapas a seguir:
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 formatoLOCATION-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.
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
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.
Faça uma alteração no arquivo de configuração.
Aplique a configuração do Terraform:
terraform apply
Confirme que você quer aplicar as ações descritas digitando
yes
.
Bibliotecas de cliente
Para implantar uma nova revisão do código:
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 formatoLOCATION-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)europe-north1
(Finlândia)Baixo CO2
europe-southwest1
(Madri)Baixo CO2
europe-west1
(Bélgica)Baixo CO2
europe-west4
(Países Baixos)Baixo CO2
europe-west8
(Milão)europe-west9
(Paris)Baixo CO2
me-west1
(Tel Aviv)us-central1
(Iowa)Baixo CO2
us-east1
(Carolina do Sul)us-east4
(Norte da Virgínia)us-east5
(Columbus)us-south1
(Dallas)Baixo CO2
us-west1
(Oregon)Baixo CO2
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-south1
(Mumbai, Índia)asia-south2
(Déli, Índia)australia-southeast1
(Sydney)australia-southeast2
(Melbourne)europe-central2
(Varsóvia, Polônia)europe-west10
(Berlim)Baixo CO2
europe-west12
(Turim)europe-west2
(Londres, Reino Unido)Baixo CO2
europe-west3
(Frankfurt, Alemanha)Baixo CO2
europe-west6
(Zurique, Suíça)Baixo CO2
me-central1
(Doha)me-central2
(Damã)northamerica-northeast1
(Montreal)Baixo CO2
northamerica-northeast2
(Toronto)Baixo CO2
southamerica-east1
(São Paulo, Brasil)Baixo CO2
southamerica-west1
(Santiago, Chile)Baixo CO2
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.
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:
No console do Google Cloud, abra o projeto do serviço do Cloud Run.
Selecione Incluir concessões de papel fornecidas pelo Google.
Copie o e-mail do agente de serviço do Cloud Run. Ele tem o sufixo @serverless-robot-prod.iam.gserviceaccount.com
Abra o projeto com o registro do contêiner que você quer usar.
Clique em Adicionar para adicionar um novo principal.
No campo Novos principais, cole o e-mail da conta de serviço que você copiou anteriormente.
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.
Implante a imagem do contêiner no projeto que contém o serviço do Cloud Run.
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 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 de volumes compartilhados 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.
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
-
- Para implantar em um serviço atual, 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.
- Para implantar em um novo serviço, clique em Criar serviço.
Para um novo serviço,
- Forneça o nome do serviço e o URL para a imagem do contêiner de entrada que você quer implantar.
- Clique em Contêiner(s), volumes, rede, segurança
No card Editar contêiner, configure o contêiner de entrada conforme necessário.
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.
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.
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.
-
No Console do Google Cloud, ative o Cloud Shell.
Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.
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
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_NAME 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:
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: