gcp-cloud-run-deployment

name	gcp-cloud-run-deployment
description	Use esta skill para desenhar, revisar ou documentar deploy de APIs, workers e jobs em Cloud Run para esta POC .NET. Cobre container, porta, variaveis, secrets, service account, escalabilidade, health, logs, Cloud SQL e limites operacionais.

Objetivo

Orientar a preparacao de APIs e workers .NET deste repositorio para execucao em Cloud Run, sem executar deploy real automaticamente.

Quando usar

• Planejar ou revisar deploy de LedgerService.Api, BalanceService.Api, workers ou jobs em Cloud Run.
• Ajustar Dockerfile, configuracao de porta, health/readiness, variaveis de ambiente, secrets ou service account para Cloud Run.
• Avaliar se um componente deve ser Cloud Run service, job, worker pool ou GKE.
• Documentar estrategia de deploy, escalabilidade, logs, metricas, custos ou limites.

Quando nao usar

• Rodar stack local Docker Compose sem relacao com Cloud Run.
• Criar Cloud SQL, IAM ou rede como foco principal. Combine com as skills GCP correspondentes.
• Executar deploy real sem pedido explicito.

Mapeamento inicial da POC

• APIs HTTP tendem a mapear para Cloud Run services.
• Workers Kafka exigem avaliacao cuidadosa: worker pool, job, GKE ou alternativa gerenciada dependem do modelo de mensageria escolhido.
• PostgreSQL local deve ser substituido por Cloud SQL ou por outro servico explicitamente decidido.
• Imagens devem ficar preferencialmente em Artifact Registry.
• Segredos devem vir de Secret Manager ou mecanismo equivalente, nunca de arquivo versionado.

Regras de decisao

Nao introduza health/readiness, portas HTTP, endpoints auxiliares, sidecars ou novos recursos de Cloud Run apenas por checklist.

Antes de propor mudanca operacional, classifique se ela e:

1. exigida pela plataforma;
2. util, mas opcional;
3. valida apenas em producao;
4. desnecessaria para a POC;
5. potencialmente prejudicial pelo custo, complexidade ou carga operacional.

Para workers e jobs, nao introduza endpoints HTTP de health/readiness por padrao. Avalie primeiro se o ambiente de execucao exige probes HTTP ou se metricas, logs, exit code, retry policy e alertas cobrem melhor a saude operacional.

Se endpoints forem realmente necessarios, mantenha-os leves e baseados em estado interno do processo. Evite readiness que consulte banco pesado, fila, DLQ ou views de grande volume em tempo real.

Passos

1. Leia README.md, docs/architecture/, docs/observability.md, Dockerfiles, Compose e ADRs relacionadas.
2. Classifique cada workload como service, worker pool, job ou fora de Cloud Run.
3. Confirme compatibilidade do container com porta dinamica, startup, shutdown e sinais de encerramento.
4. Para APIs HTTP, preserve health/readiness ja existentes quando fizerem sentido para a plataforma.
5. Para workers e jobs, avalie se health/readiness HTTP e realmente necessario ou se observabilidade por metricas e alertas e mais adequada.
6. Modele variaveis por ambiente sem versionar secrets.
7. Defina service account dedicada por workload com menor privilegio.
8. Avalie conectividade com Cloud SQL, Kafka/Pub/Sub, Keycloak/OIDC e observabilidade.
9. Defina limites de CPU, memoria, concorrencia, timeout e escala conforme o perfil do workload.
10. Atualize documentacao e ADR quando a decisao afetar estrategia de deploy, operacao, conectividade, observabilidade, seguranca ou custo.