O Que É o Google Cloud Run? Containers Serverless no GCP
O Google Cloud Run executa uma imagem de container como um serviço escalável ou um job, cuidando do escalonamento (inclusive a zero) e da infraestrutura para que você apenas forneça uma imagem.
O Cloud Run atinge um ponto ideal entre funções no estilo Lambda e Kubernetes completo: você fornece um container, e ele o executa como um serviço HTTP com autoscaling ou um job em batch. Você não gerencia servidores nem clusters, e ele escala a zero quando ocioso, então você não paga nada entre requisições.
Como o Cloud Run funciona
Você faz deploy de uma imagem de container que escuta em uma porta. O Cloud Run roteia requisições HTTP (ou gRPC) para instâncias, subindo-as conforme o tráfego chega e descendo a zero quando ocioso. Cada revisão é imutável, e você pode dividir tráfego entre revisões.
Serviços vs jobs
- Serviços tratam requisições de entrada e fazem autoscaling com o tráfego.
- Jobs executam um container até a conclusão para trabalho em batch ou agendado.
- Ambos usam o mesmo formato de imagem de container.
Escalonamento e cold starts
O Cloud Run escala horizontalmente com base na concorrência e na carga de requisições. Escalar a zero economiza dinheiro, mas introduz um cold start na próxima requisição; você pode definir um número mínimo de instâncias quentes para evitar isso em serviços sensíveis à latência.
Por que as equipes gostam dele
Ele executa qualquer container, então não há runtime proprietário a mirar. É mais barato do que servidores sempre ligados para tráfego irregular, mais simples do que o GKE e mais flexível do que plataformas só de funções, porque você controla a imagem inteira.
Papel no CI/CD
Um pipeline faz o build da imagem, a envia para o Artifact Registry e executa gcloud run deploy para publicar uma nova revisão. Com o Workload Identity Federation, o GitHub Actions autentica sem um arquivo de chave. O tráfego pode ser deslocado gradualmente entre revisões para releases canary.
Principais conclusões
- O Cloud Run executa qualquer container como um serviço com autoscaling ou um job em batch.
- Ele escala a zero para economizar custo, com instâncias quentes opcionais para evitar cold starts.
- Pipelines enviam uma imagem para o Artifact Registry e fazem deploy de uma nova revisão.