O Cloud Run é uma plataforma de aplicativos totalmente gerenciada para executar seu código, função ou contêiner na infraestrutura altamente escalonável do Google.
Você pode implantar um código escrito em qualquer linguagem de programação no Cloud Run se puder criar uma imagem de contêiner com base nele. Na verdade, a criação de imagens de contêiner é opcional. Se você usa Go, Node.js, Python, Java, .NET, Ruby ou um framework compatível, é possível usar a opção de implantação baseada em origem que cria o contêiner para você aproveitando as práticas recomendadas para a linguagem que está sendo usada.
O Google criou o Cloud Run para funcionar bem com outros serviços do Google Cloud Google Cloud. Assim, você pode criar aplicativos completos.
Em resumo, o Cloud Run permite que os desenvolvedores passem mais tempo escrevendo o código e quase sem tempo operando, configurando e escalonando o serviço do Cloud Run. Não é necessário criar um cluster ou gerenciar a infraestrutura para ser produtivo com o Cloud Run.
Serviços, jobs, pools de workers e instâncias: quatro maneiras de executar o código
No Cloud Run, o código pode ser executado como um serviço, job, pool de workers ou instância. Todos esses tipos de recursos executam instâncias de contêiner em sandbox no mesmo ambiente de execução e podem ser integrados a Google Cloud serviços.
A tabela a seguir oferece uma visão geral das opções fornecidas por cada tipo de recurso do Cloud Run.
| Recurso | Descrição |
|---|---|
| Serviço | Responde a solicitações HTTP enviadas a um endpoint exclusivo e estável, usando instâncias de contêiner sem estado que oferecem suporte ao escalonamento automático dinâmico e ao escalonamento manual. Também responde a eventos e funções. |
| Job | Executa tarefas paralelizadas que são executadas manualmente ou em uma programação e são executadas até a conclusão. |
| Pool de workers | Processa cargas de trabalho em segundo plano sempre ativas, como cargas de trabalho de filas de mensagens (Kafka, Pub/Sub, RabbitMQ). |
| Instância | Executa cargas de trabalho de longa duração que precisam de um ambiente de execução singleton. |
Serviços do Cloud Run
Um serviço do Cloud Run oferece a infraestrutura necessária para executar um endpoint HTTPS confiável. Para usar esse serviço, é necessário garantir que o código detecte uma porta TCP e identifique solicitações HTTP recebidas.
O diagrama a seguir ilustra como um serviço do Cloud Run executa várias instâncias de contêiner para processar solicitações e eventos da Web de um cliente:
Um serviço padrão inclui os seguintes recursos:
- Endpoint HTTPS exclusivo para cada serviço
- Cada serviço do Cloud Run tem um endpoint HTTPS em um subdomínio exclusivo do domínio
*.run.appe também é possível configurar domínios personalizados. O Cloud Run gerencia o TLS para você e oferece suporte a WebSockets, HTTP/2 (de ponta a ponta) e gRPC (de ponta a ponta). - Escalonamento automático rápido com base em solicitações
- O Cloud Run é escalonado horizontalmente rapidamente para lidar com todas as solicitações recebidas ou para lidar com o aumento da utilização da CPU fora das solicitações se a configuração de faturamento estiver definida como faturamento baseado em instâncias. Um serviço pode ser escalonar horizontalmente de forma rápida para até mil instâncias ou até mais, se você solicitar um aumento de cota. Se a demanda diminuir, o Cloud Run removerá os contêineres inativos. Se você estiver preocupado com custos ou sobrecarregando os sistemas downstream, poderá limitar o número máximo de instâncias.
- Escalonamento manual opcional
- Por padrão, o Cloud Run é escalonado automaticamente para mais instâncias para processar mais tráfego, mas é possível substituir esse comportamento usando o escalonamento manual para controlar o comportamento de escalonamento.
- Gerenciamento de tráfego integrado
Para reduzir o risco de implantar uma nova revisão, o Cloud Run oferece suporte à realização de um lançamento gradual, incluindo o roteamento do tráfego de entrada para a revisão mais recente, a reversão para uma revisão anterior e a divisão do tráfego para várias revisões ao mesmo tempo.
Você pode começar enviando 1% das solicitações para uma nova revisão e aumentar essa porcentagem enquanto monitora a telemetria.
- Serviços públicos e privados
Um serviço do Cloud Run pode ser acessado pela Internet ou ter o acesso restrito destas maneiras:
- Especifique uma política de acesso usando o Cloud Identity and Access Management (IAM).
- Use as configurações de entrada para restringir o acesso à rede. Isso é útil se você quiser permitir apenas o tráfego interno da VPC e dos serviços internos.
- Permitir apenas usuários autenticados com o Identity-Aware Proxy (IAP).
Você pode disponibilizar recursos armazenáveis em cache de um local do perímetro mais próximo dos clientes usando uma rede de fornecimento de conteúdo (CDN), como o Firebase Hosting e o Cloud CDN, para disponibilizar um serviço do Cloud Run.
Escalonar para zero e instâncias mínimas
Por padrão, se o faturamento estiver definido como baseado em instâncias faturamento, o Cloud Run adiciona e remove instâncias automaticamente para lidar com todas as solicitações recebidas ou para lidar com o aumento da utilização da CPU fora das solicitações.
Redução da escala a zero
Se não houver solicitações de entrada para seu serviço, até mesmo a última instância restante será removida. Esse comportamento é normalmente chamado de redução da escala a zero.
Quando uma nova solicitação chega a um serviço sem instâncias ativas, o Cloud Run cria uma nova instância. Esse processo pode aumentar o tempo de resposta para essas solicitações iniciais, dependendo da rapidez com que o contêiner fica pronto para lidar com o tráfego.
Alterar o comportamento de escalonamento
É possível modificar esse comportamento padrão usando um dos seguintes métodos:
- Instâncias mínimas: configure o Cloud Run para manter uma quantidade mínima de instâncias ativas para que o serviço não seja escalonado para zero.
- Escalonamento manual: use o escalonamento manual para manter mais controle sobre o comportamento de escalonamento do serviço.
Preços de pagamento por uso para serviços
A redução da escala para zero é atraente por motivos econômicos, porque você é cobrado pela CPU e memória alocadas para uma instância com uma granularidade de 100 ms. Se você não configurar instâncias mínimas, não haverá cobrança se o serviço não for usado. Há um generoso nível sem custo financeiro. Para mais informações, consulte Preços.
Há duas configurações de faturamento que podem ser ativadas:
- Baseada em solicitações
- Se uma instância não estiver processando solicitações, não haverá cobrança. Você paga uma taxa por solicitação.
- Com base em instâncias
- Você é cobrado durante todo o ciclo de vida de uma instância. Não há taxa por solicitação.
Há um generoso nível sem custo financeiro. Consulte preços para mais informações e consulte Configurações de faturamento para saber como ativar o faturamento baseado em solicitações ou instâncias para seu serviço.
Um sistema de arquivos de contêiner descartável
As instâncias no Cloud Run são descartáveis. Cada contêiner tem uma sobreposição de sistema de arquivos gravável na memória, que não é mantida se o contêiner é desligado. O Cloud Run determina quando parar de enviar solicitações a uma instância e desativá-la, por exemplo, ao reduzir o escalonamento vertical.
Para receber um aviso quando o Cloud Run estiver prestes a encerrar uma instância, o aplicativo pode tratar o sinal SIGTERM. Isso permite que o código transfira buffers locais e mantenha os dados locais em um repositório de dados externo.
Para manter os arquivos de forma permanente, integre-se ao Cloud Storage ou ative um sistema de arquivos de rede (NFS).
Quando usar os serviços do Cloud Run
Os serviços do Cloud Run são ótimos para o código que processa solicitações, eventos ou funções. Como exemplos de casos de uso, temos:
- Sites e aplicativos da Web
- Crie seu app da Web usando sua pilha favorita, acesse seu banco de dados SQL e renderize páginas HTML dinâmicas.
- APIs e microsserviços
- É possível criar uma API REST, uma API GraphQL ou microsserviços particulares que se comunicam por HTTP ou gRPC.
- Processamento de dados de streaming
- Os serviços do Cloud Run podem receber mensagens de Assinaturas de push do Pub/Sub e eventos do Eventarc.
- Cargas de trabalho assíncronas
- As funções do Cloud Run podem responder a eventos assíncronos, como uma mensagem em um tópico do Pub/Sub, uma alteração em um bucket do Cloud Storage ou um evento do Firebase.
- Inferência de IA
- Os serviços do Cloud Run, com ou sem GPU configurada, podem hospedar cargas de trabalho de IA, como modelos de inferência e treinamento de modelo.
Jobs do Cloud Run
Se o código executar o trabalho e depois parar, por exemplo, usando um script, você poderá usar um job do Cloud Run para executá-lo. É possível executar um job na linha de comando usando a Google Cloud CLI, programando um job recorrente, ou executando-o como parte de um fluxo de trabalho.
Jobs de matriz são uma maneira mais rápida de executar jobs
Um job pode iniciar uma única instância para executar o código. Essa é uma maneira comum de executar um script ou uma ferramenta.
No entanto, também é possível usar um job de matriz, iniciando várias instâncias idênticas e independentes em paralelo. Os jobs de matriz são uma maneira mais rápida de processar jobs que podem ser divididos em várias tarefas independentes.
O diagrama a seguir mostra como um job com sete tarefas leva mais tempo para ser executado sequencialmente do que o mesmo job quando quatro instâncias podem processar tarefas independentes em paralelo:
Por exemplo, se você estiver redimensionando e cortando mil imagens do Cloud Storage, processá-las consecutivamente será mais lento do que processá-las em paralelo com muitas instâncias, com o Cloud Run gerenciando o escalonamento automático.
Quando usar jobs do Cloud Run
Os jobs do Cloud Run são adequados para executar códigos que executam tarefas (um job) e são encerrados quando o trabalho é concluído. Por exemplo:
- Script ou ferramenta
- Executar um script para realizar migrações de banco de dados ou outras tarefas operacionais.
- Job de matriz
- Executar o processamento altamente paralelo de todos os arquivos em um bucket do Cloud Storage.
- Job agendado
- Crie e envie faturas em intervalos regulares ou salve os resultados de uma consulta no banco de dados como XML e faça upload do arquivo em intervalos de algumas horas.
- Cargas de trabalho de IA
- Os jobs do Cloud Run com ou sem GPU configurada podem hospedar cargas de trabalho de IA, como inferência em lote, modelos de ajuste fino e treinamento de modelo.
Pools de workers do Cloud Run
Os pools de workers são projetados para cargas de trabalho que não dependem do processamento de solicitações HTTP. Eles fornecem um pool flexível e escalonável de recursos de computação personalizados para processamento contínuo, não HTTP e baseado em pull em segundo plano. As seguintes características principais definem como os pools de workers operam:
Os pools de workers não são escalonados automaticamente. Escalone manualmente o número de instâncias que o pool de workers do Cloud Run exige para processar a carga de trabalho. Para iniciar e permanecer ativa, a carga de trabalho precisa ter pelo menos uma instância. Se você definir as instâncias mínimas como
0, a instância de worker não será iniciada, mesmo que a implantação seja bem-sucedida.Para ajustar instâncias dinamicamente com base na demanda em tempo real, crie seu próprio escalonador automático. Para um exemplo, consulte Escalonar automaticamente as cargas de trabalho do consumidor do Kafka.
Os pools de workers gerenciam lançamentos dividindo instâncias entre revisões, em vez de dividir o tráfego. Por exemplo, para um pool de workers com quatro instâncias, é possível alocar 25% (uma instância) para uma nova revisão e 75% (três instâncias) para uma revisão estável.
Os pools de workers oferecem suporte à saída e entrada VPC direta e não têm um endpoint ou URL com balanceamento de carga. Para mais informações sobre o suporte do servidor de metadados (MDS) e como recuperar os endereços IP particulares da instância do pool de workers, consulte o Contrato de ambiente de execução do contêiner.
O Cloud Run cobra apenas pela duração da execução das instâncias do pool de workers.
Quando usar pools de workers do Cloud Run
Os pools de workers não exigem endpoints HTTP públicos. Isso torna sua rede mais segura e simplifica o código do aplicativo. Você também não precisa gerenciar portas para verificações de integridade. Os casos de uso a seguir se aplicam a pools de workers:
Cargas de trabalho baseadas em pull: implante uma carga de trabalho para extrair mensagens de uma fila para processamento. Por exemplo, consumidor do Kafka, pull do Pub/Sub, e RabbitMQ.
O diagrama a seguir mostra casos de uso para a implantação de pools de workers para cargas de trabalho baseadas em pull:

Em um caso de uso do Pub/Sub, um assinante do Cloud Run escalonado automaticamente extrai mensagens de uma assinatura do Pub/Sub. Em um caso de uso do Kafka, um consumidor do Cloud Run escalonado automaticamente extrai mensagens de um tópico do Kafka.
Cargas de trabalho genéricas sem solicitação: execute uma carga de trabalho baseada em contêiner que não se destina a processar solicitações de entrada.
Instâncias do Cloud Run
Uma instância do Cloud Run foi projetada para cargas de trabalho que exigem um ambiente de execução singleton estável, contínuo e endereçável individualmente, em vez de escalonamento horizontal orientado por solicitações.
Ao contrário de um serviço, que pode ter várias instâncias de contêiner e ser configurado para escalonamento automático ou manual, uma instância do Cloud Run é apenas uma instância.
Uma instância do Cloud Run inclui as seguintes características:
- Gerenciável individualmente: é possível criar, atualizar e excluir cada instância individualmente, iniciar e interromper a instância e monitorar as execuções.
- Endereçável individualmente: cada instância recebe um URL exclusivo.
- De longa duração: a instância pode ser executada sem interrupção por horas ou dias, ou até mais, se estiver configurada para reiniciar automaticamente após atualizações periódicas da infraestrutura (a cada 1 a 2 semanas).
- Criação rápida: a instância é provisionada e executada em aproximadamente 20 segundos ou menos.
Quando usar instâncias do Cloud Run
As instâncias do Cloud Run são projetadas para cargas de trabalho de computação singleton persistentes, projetadas para executar cargas de trabalho agênticas e fluxos de trabalho não relacionados à IA. Como exemplos de casos de uso, temos:
- Agentes de IA de longa duração e mecanismos de fluxo de trabalho de IA
- Crie agentes de segundo plano de longa duração que executam planos de execução de várias etapas, executam assistentes de codificação assíncrona ou gerenciam fluxos de trabalho com estado que exigem um ambiente de instância única.
- Computação sem servidor de longa duração
- Implante servidores leves e sempre ativos, semelhantes a um servidor privado virtual (VPS) que é executado continuamente. Isso é ideal se você quiser cargas de trabalho que não exigem escalonamento automático ou processamento de tráfego em escala da Web e quiser priorizar o custo mais baixo e a longevidade singleton em vez da alta disponibilidade.
- Ambientes de desenvolvedor e loops de depuração
- Implante ambientes dedicados para depurar processos de contêiner remotamente, sincronizar mudanças de código e solucionar problemas de falhas sem encerramento automático do contêiner.
Google Cloud integrações
O Cloud Run se integra ao ecossistema mais amplo do Google Cloud Google Cloud, o que permite criar aplicativos completos.
As integrações essenciais incluem:
- Armazenamento de dados
- O Cloud Run se integra ao Cloud SQL (MySQL gerenciado, PostgreSQL e SQL Server), Memorystore (gerenciado Redis e Memcached), Firestore, Cloud Spanner, Cloud Storage e muito mais. Consulte Armazenamento de dados para ver uma lista completa.
- Geração de registros e relatórios de erros
- O Cloud Logging ingere registros de contêiner automaticamente. Se houver exceções nos registros, o Error Reporting os agrega e notifica você. As seguintes linguagens são compatíveis: Go, Java, Node.js, PHP, Python, Ruby e .NET.
- Identidade do serviço
- Cada revisão do Cloud Run está vinculada a uma conta de serviço, e as Google Cloud bibliotecas de cliente usam essa conta de serviço de maneira transparente para autenticar com as Google Cloud APIs.
- Entrega contínua
- Se você armazenar seu código-fonte no GitHub, poderá configurar o Cloud Run para implantar automaticamente novas confirmações.
- Rede privada
- As instâncias do Cloud Run podem acessar recursos na rede de nuvem privada virtual (VPC) por meio doconector de acesso à VPC sem servidor. É assim que seu serviço se conecta com as máquinas virtuais do Compute Engine ou produtos baseados no Compute Engine, como o Google Kubernetes Engine ou o Memorystore.
- Google Cloud APIs de
- O código do serviço é autenticado de maneira transparente com as Google Cloud APIs. Isso inclui as APIs de IA e machine learning, como a API Cloud Vision, API Speech-to-Text, API AutoML Natural Language, API Cloud Translation e muito mais.
- Tarefas em segundo plano
- É possível programar um código para ser executado posteriormente ou imediatamente após retornar uma solicitação da Web. O Cloud Run funciona bem com o Cloud Tasks para oferecer uma execução assíncrona e confiável.
Consulte Como se conectar a Google Cloud serviços para conferir uma lista dos muitos Google Cloud serviços que funcionam bem com o Cloud Run.
O código está em execução em uma imagem de contêiner
Embora não seja necessário estar familiarizado com contêineres para implantar o código em um Cloud Run, o código sempre acaba sendo executado em instâncias de contêiner em sandbox.
Se você não estiver familiarizado com os contêineres, veja uma breve introdução conceitual.
Como o diagrama mostra, você usa código-fonte, recursos e dependências de biblioteca para criar uma imagem do contêiner. Essa imagem é um pacote que contém tudo o que seu serviço precisa para ser executado, incluindo artefatos de build, recursos, pacotes de sistema e, opcionalmente, um ambiente de execução. Os aplicativos conteinerizados são inerentemente portáteis e executados em qualquer lugar em que um contêiner possa ser executado. Os artefatos de build incluem binários compilados ou arquivos de script, e os ambientes de execução incluem o ambiente de execução JavaScript do Node.js ou uma máquina virtual Java.
Profissionais avançados valorizam o fato de que o Cloud Run não impõe outros encargos à execução do código, e é possível executar qualquer binário no Cloud Run.
Se você quiser mais conveniência ou delegar aplicativos de contêiner ao Google, o Cloud Run se integrará aos buildpacks de código aberto do Google Cloud para oferecer uma implantação baseada na origem.
A seguir
- Implantar um serviço do Cloud Run
- Criar e executar um job do Cloud Run
- Saiba como executar jobs no prazo
- Implantar um pool de workers
- Implantar uma instância do Cloud Run
- Conheça o modelo de recursos
- Leia mais sobre o contrato de ambiente de execução do contêiner