Este guia descreve como o Cloud Run processa implantações, divididas em três áreas:
- Tipos de implantação: o que você traz para o Cloud Run, como código-fonte ou imagens de contêiner.
- Recursos do Cloud Run: o que sua implantação executa no Cloud Run (serviço, job, pool de workers ou instância).
- Métodos de implantação: como você executa a implantação, por exemplo, usando o console Google Cloud , a CLI gcloud, o YAML ou o Terraform.
Tipos de implantação
O Cloud Run oferece várias opções de implantação. Após a implantação, todas as implantações, execuções ou criações são executadas como instâncias de contêiner em sandbox na infraestrutura totalmente gerenciada e altamente escalonável do Cloud Run. A tabela a seguir mostra as opções de implantação compatíveis com cada tipo de recurso:
| Opção de implantação | Serviços | Jobs | Pools de workers | Instâncias |
|---|---|---|---|---|
| Implantar imagens de contêiner | Com suporte | Compatível | Compatível | Com suporte |
| Implantar a partir do código-fonte | Com suporte | Compatível | Com suporte | — |
| Implantar funções1 | Com suporte | — | — | — |
| Implantação contínua do git | Com suporte | — | — | — |
1 As funções são uma versão especializada da implantação de origem para código de propósito único e orientado a eventos.
Implantar imagens de contêiner
É possível implantar qualquer imagem de contêiner que siga o contrato de ambiente de execução de contêiner do Cloud Run em um serviço, job, pool de workers ou instância do Cloud Run.
Implantar a partir do código-fonte
Para sua conveniência, o Cloud Run permite criar e implantar o código-fonte com um único comando. Consulte Como implantar serviços do código-fonte, Como executar jobs do código-fonte e Como implantar pools de workers do código-fonte para mais detalhes.
Ao implantar do código-fonte, o Cloud Build transforma o código em uma
imagem de contêiner armazenada no Artifact Registry. É possível implantar código-fonte que inclui
um Dockerfile ou que usa um dos ambientes de execução de linguagem
compatíveis.
Funções
É possível implantar funções com uma única finalidade que respondem a eventos emitidos pelos serviços e pela infraestrutura em nuvem. O Cloud Run aciona sua função quando um evento monitorado é disparado.
Uma implantação de funções é um tipo especial de implantação de código-fonte, em que você só precisa fornecer o código da função. É possível escrever funções do Cloud Run usando várias linguagens de programação compatíveis.
A implantação de uma função cria um serviço do Cloud Run.
Implantação contínua de código-fonte do git
O Cloud Run ajuda a configurar a implantação contínua do
Git. Assim como nas implantações de
origem, é possível implantar código-fonte que
inclui um Dockerfile ou que foi gravado em um dos ambientes de execução de
linguagem compatíveis.
A implantação contínua do Git está disponível para serviços do Cloud Run. É possível configurá-los manualmente no Cloud Build para jobs do Cloud Run.
Recursos do Cloud Run
As seções a seguir descrevem os recursos do Cloud Run em mais detalhes.
Comparação de recursos do Cloud Run
| Recurso | Serviços | Jobs | Pools de worker | Instâncias |
|---|---|---|---|---|
| Caso de uso principal | Orientado por solicitações (sites, APIs, microsserviços) | Orientado a tarefas (scripts, processamento de dados, migrações) | Orientado a eventos/extração (consumidores do Kafka/PubSub) | Singleton gerenciado (cargas de trabalho de agentes, necessidades específicas de computação) |
| Gatilho | Solicitações HTTP/gRPC, Eventarc | Modos de execução: padrão (imediato), atrasado. Acionadores: execução manual, usando o Scheduler, usando o Workflows |
Sempre ativo OU escalonado automaticamente usando trabalho em segundo plano baseado em pull | Nenhum |
| Escalonamento | Automático/manual: escalona para zero ou com base em solicitações | Automático: escalona para N tarefas independentes que são executadas em sequência ou em paralelo. | Automático/manual: número fixo de instâncias usando escalonamento manual ou escalonamento automático integrado com base na utilização da CPU ou no backlog de mensagens do Pub/Sub (escalonamento automático baseado no KEDA usando o escalonador automático externo) | Nenhum: sem escalonamento automático, gerenciamento individual |
| Lifecycle | Temporário, reduz a escala vertical quando inativo | Dura até 7 dias (curta duração) | Escolha entre processos em segundo plano sempre ativos OU instâncias temporárias com escalonamento automático. | De longa duração (podem ser executados por dias/semanas) e reiniciados automaticamente por tempo indeterminado |
| Endereçamento | URL de serviço estável (com balanceamento de carga) | Nenhum endpoint público. URL interno para gatilhos (por exemplo, programador) |
Sem endpoint público. Acesso de entrada baseado em IP da VPC direta e privada |
URL individual por instância |
| Tráfego de entrada | HTTP/gRPC público/interno | Nenhum | Entrada L4 baseada em IP com VPC direta | URL público/interno por instância |
| Faturamento | Baseado em solicitações ou em instâncias | Duração por execução | Duração por instância | Duração por instância |
Serviços do Cloud Run
Um serviço é o tipo de recurso principal no Cloud Run, representando uma carga de trabalho orientada por solicitações que escalona automaticamente as instâncias de contêiner para processar o tráfego da Web, solicitações HTTP ou eventos recebidos. Cada serviço está localizado em uma região específica doGoogle Cloud . Para oferecer redundância e failover, o Cloud Run replica automaticamente serviços em várias zonas de uma região. Um determinado Google Cloud projeto pode executar muitos serviços em diferentes regiões.
Cada serviço expõe um endpoint exclusivo. Por padrão, o Cloud Run escalona automaticamente para processar as solicitações recebidas. Se necessário, você pode mudar o comportamento de escalonamento para escalonamento manual. É possível implantar um serviço de um contêiner, repositório ou código-fonte.
O diagrama a seguir mostra o modelo de recursos do Cloud Run para serviços:
O diagrama mostra um projeto Google Cloud com três serviços do Cloud Run (Serviço A, Serviço B e Serviço C), cada um com várias revisões:
- O serviço A está recebendo várias solicitações, então o Cloud Run iniciou várias instâncias para processar a carga. Cada uma dessas instâncias executa apenas um contêiner (o contêiner do aplicativo).
- O serviço B não tem solicitações, então está inativo, e o Cloud Run não está executando nenhuma instância.
- O serviço C tem solicitações e foi escalonado para lidar com a carga criando várias instâncias. Nesse caso, cada uma dessas instâncias executa um conjunto de vários contêineres. Em cada conjunto, apenas o contêiner de entrada recebe a solicitação, mas os outros contêineres ajudam a atender a ela.
Revisões de serviço do Cloud Run
Cada implantação em um serviço cria uma revisão. Uma revisão consiste em uma ou mais imagens de contêiner, além de configurações, como variáveis de ambiente, limites de memória ou valor de simultaneidade de solicitação.
Não é possível modificar uma revisão depois da criação. Por exemplo, quando você implanta uma imagem do contêiner em um novo serviço, o Cloud Run cria a primeira revisão. Se você implantar uma imagem de contêiner diferente no mesmo serviço, o Cloud Run vai criar uma segunda revisão. Se você definir uma variável de ambiente depois, o Cloud Run vai criar uma terceira revisão. Com o tempo, o Cloud Run remove as revisões não utilizadas.
O Cloud Run encaminha automaticamente as solicitações o quanto antes para a revisão de serviço íntegra mais recente.
Instâncias de serviço do Cloud Run
O Cloud Run escalona automaticamente cada revisão de serviço que recebe solicitações para o número de instâncias necessárias para lidar com todas elas. As instâncias podem receber muitas solicitações ao mesmo tempo. Com a configuração de simultaneidade de solicitações, é possível definir o número máximo de solicitações que podem ser enviadas em paralelo a cada instância de uma revisão.
Jobs do Cloud Run
Cada job está localizado em uma região Google Cloud específica e consiste em uma ou mais tarefas que executam um ou mais contêineres até a conclusão. As tarefas de job são independentes e podem ser executadas em paralelo em uma determinada execução de job.
Execuções de job do Cloud Run
Quando você executa um job, o Cloud Run cria uma execução de job e inicia todas as tarefas. Todas as tarefas em uma execução de job precisam ser concluídas com êxito para que a execução seja bem-sucedida. É possível definir tempos limite em tarefas e especificar o número de novas tentativas em caso de falha de tarefas.
Se uma tarefa exceder o número máximo de novas tentativas, o Cloud Run vai marcar essa tarefa e o job como falha. Por padrão, as tarefas são executadas em paralelo até um máximo de 100, mas você pode especificar um máximo menor se algum dos recursos de apoio, como um banco de dados, exigir.
Tarefas de job do Cloud Run
Cada execução de job executa várias tarefas em paralelo, e cada tarefa
executa uma instância. O Cloud Run tenta executar automaticamente
todas as tarefas com falha novamente, dependendo da configuração do job para maxRetries.
Pools de workers do Cloud Run
Os pools de workers são um recurso do Cloud Run projetado especificamente para cargas de trabalho sem solicitação, como filas de extração. Os pools de workers não têm os seguintes recursos:
- Nenhum endpoint/URL
- Não há necessidade de o contêiner implantado detectar solicitações em uma porta.
- Sem escalonamento automático
Assim como um serviço do Cloud Run, a implantação ou atualização de um pool de workers cria uma nova revisão.
É possível escalonar manualmente as instâncias do pool de trabalhadores conforme necessário para processar as cargas de trabalho. Também é possível escalonar automaticamente pools de trabalhadores com métricas externas, o que processa o escalonamento de cargas de trabalho impulsionadas por fontes como assinaturas do Pub/Sub, consultas do Prometheus ou filas do Kafka.
Quando conectada a uma rede de nuvem privada virtual (VPC), cada instância de pool de workers recebe um endereço IP na rede VPC e pode enviar e receber tráfego para e dessa VPC.
Instâncias do Cloud Run
Uma instância do Cloud Run representa um ambiente de execução independente e singleton. Ao contrário de um serviço, que escalona instâncias de contêiner automaticamente ou manualmente para lidar com o tráfego, uma instância do Cloud Run é um recurso de nível superior com capacidade de endereçamento de URL direto e operações de ciclo de vida próprias.
Cada instância do Cloud Run inclui os seguintes recursos:
- Endpoint de URL dedicado: atribui um URL de entrada estável por padrão. Você pode desativar o URL padrão para permitir apenas o tráfego dos outros caminhos de entrada da instância.
- Políticas de reinicialização: oferecem suporte a condições de reinicialização (
always,on-failure,never) para recuperar automaticamente o processo do contêiner em caso de falhas. - Alocação compartilhada de CPU: executada em um modelo de CPU compartilhada em que a CPU é totalmente alocada com base em um orçamento de burst e limitada a um limite de recursos de linha de base de 6,25% fora desse orçamento.