| 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:
- exigida pela plataforma;
- util, mas opcional;
- valida apenas em producao;
- desnecessaria para a POC;
- 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
- Leia
README.md, docs/architecture/, docs/observability.md, Dockerfiles, Compose e ADRs relacionadas.
- Classifique cada workload como service, worker pool, job ou fora de Cloud Run.
- Confirme compatibilidade do container com porta dinamica, startup, shutdown e sinais de encerramento.
- Para APIs HTTP, preserve health/readiness ja existentes quando fizerem sentido para a plataforma.
- Para workers e jobs, avalie se health/readiness HTTP e realmente necessario ou se observabilidade por metricas e alertas e mais adequada.
- Modele variaveis por ambiente sem versionar secrets.
- Defina service account dedicada por workload com menor privilegio.
- Avalie conectividade com Cloud SQL, Kafka/Pub/Sub, Keycloak/OIDC e observabilidade.
- Defina limites de CPU, memoria, concorrencia, timeout e escala conforme o perfil do workload.
- Atualize documentacao e ADR quando a decisao afetar estrategia de deploy, operacao, conectividade, observabilidade, seguranca ou custo.
