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:
Na Google Cloud consola, aceda à página do Cloud Run:
Selecione Serviços no menu e clique em Implementar contentor para apresentar o formulário Criar serviço.
No formulário, selecione a opção de implementação:
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.
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.
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.
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.
Defina a faturação conforme necessário.
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.
Defina as definições de Ingress no formulário conforme necessário.
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.
- 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
Clique em Recipientes, volumes, rede, segurança para definir outras definições opcionais nos separadores adequados:
Quando terminar de configurar o serviço, clique em Criar para implementar a imagem no Cloud Run e aguarde que a implementação termine.
Clique no link do URL apresentado para abrir o ponto final exclusivo e estável do serviço implementado.
gcloud
-
In the Google Cloud console, 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.
Para implementar uma imagem de contentor:
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 formatoLOCATION-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 aallUsers
. 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 comandodeploy
é executado.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
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.
Implemente o novo serviço através do seguinte comando:
gcloud run services replace service.yaml
Opcionalmente, torne o seu serviço público se quiser permitir o acesso não autenticado ao serviço.
- 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 formatoLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
- 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 formatoLOCATION-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.
YAML
Pode armazenar a especificação do serviço num ficheiro YAML
e, em seguida, implementá-lo através da CLI gcloud.
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 recursogoogle_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:
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:
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:
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 CO2
europe-north2
(Estocolmo)Baixo CO2
europe-southwest1
(Madrid)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
(Telavive)northamerica-south1
(México)us-central1
(Iowa)Baixo CO2
us-east1
(Carolina do Sul)us-east4
(Virgínia do Norte)us-east5
(Columbus)us-south1
(Dallas)Baixo CO2
us-west1
(Oregão)Baixo CO2
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 CO2
europe-west12
(Turim)europe-west2
(Londres, Reino Unido)Baixo CO2
europe-west3
(Frankfurt, Alemanha)europe-west6
(Zurique, Suíça)Baixo CO2
me-central1
(Doha)me-central2
(Dammam)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 já criou um serviço do Cloud Run, pode ver a região no painel de controlo do Cloud Run na Google Cloud consola.
Implementar uma nova revisão de um serviço existente
Pode implementar uma nova revisão através da Google Cloud consola, da gcloud
linha 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:
Na Google Cloud consola, aceda à página do Cloud Run:
Localize o serviço que quer atualizar na lista de serviços e clique para abrir os detalhes desse serviço.
Clique em Editar e implementar nova revisão para apresentar o formulário de implementação de revisões.
Se necessário, indique o URL da nova imagem do contentor que quer implementar.
Configure o contentor conforme necessário.
Defina a faturação conforme necessário.
Em Capacidade, especifique os limites de memória e os limites de CPU.
Especifique o tempo limite do pedido e a simultaneidade, conforme necessário.
Especifique o ambiente de execução conforme necessário.
Em Ajuste de escala automático, especifique o número de instâncias mínimo e máximo.
Use os outros separadores, conforme necessário, para configurar opcionalmente:
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.
Clique em Implementar e aguarde até que a implementação esteja concluída.
gcloud
-
In the Google Cloud console, 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.
Para implementar uma imagem de contentor:
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 formatoLOCATION-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.
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.
Faça uma alteração ao ficheiro de configuração.
Aplique a configuração do Terraform:
terraform apply
Confirme que quer aplicar as ações descritas introduzindo
yes
.- 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 formatoLOCATION-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.
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.
Bibliotecas cliente
Para implementar uma nova revisão a partir do código:
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:
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 CO2
europe-north2
(Estocolmo)Baixo CO2
europe-southwest1
(Madrid)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
(Telavive)northamerica-south1
(México)us-central1
(Iowa)Baixo CO2
us-east1
(Carolina do Sul)us-east4
(Virgínia do Norte)us-east5
(Columbus)us-south1
(Dallas)Baixo CO2
us-west1
(Oregão)Baixo CO2
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 CO2
europe-west12
(Turim)europe-west2
(Londres, Reino Unido)Baixo CO2
europe-west3
(Frankfurt, Alemanha)europe-west6
(Zurique, Suíça)Baixo CO2
me-central1
(Doha)me-central2
(Dammam)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 já criou um serviço do Cloud Run, pode ver a região no painel de controlo do Cloud Run na Google Cloud consola.
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:
Na Google Cloud consola, abra o projeto do seu serviço do Cloud Run.
Selecione Incluir concessões de funções fornecidas pela Google.
Copie o email do agente do serviço do Cloud Run. Tem o sufixo @serverless-robot-prod.iam.gserviceaccount.com
Abra o projeto proprietário do registo de contentores que quer usar.
Clique em Adicionar para adicionar um novo principal.
No campo Novos membros, cole o email da conta de serviço que copiou anteriormente.
No menu pendente Selecionar uma função, clique em Artifact Registry -> Artifact Registry Reader.
Implemente a imagem do contentor no projeto que contém o seu serviço do Cloud Run.
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
Na Google Cloud consola, aceda à página do 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.
Para um novo serviço:
- Indique o nome do serviço e o URL da imagem do contentor de entrada que quer implementar.
- Clique em Recipientes, volumes, trabalhar em rede, segurança
No cartão Editar contentor, configure o contentor de entrada conforme necessário.
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.
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.
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
-
In the Google Cloud console, 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.
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
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.
- 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.
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:
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 recursogoogle_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:
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: