06 3 vista de despliegue - lfnavarroj1/sport-app-platform GitHub Wiki
Esta vista muestra dónde se proyecta ejecutar cada componente. La topología GCP es un objetivo arquitectónico; todavía no constituye evidencia de un ambiente remoto desplegado.
flowchart TB
USERS[Usuarios]
MOBILE[Aplicación Android]
STRAVA[API Strava]
subgraph GCP[GCP · región us-central1]
AR[Artifact Registry]
subgraph RUN[Cloud Run]
WEB[Aplicación Angular]
BFW[BFF web]
BFM[BFF móvil]
end
EDGE[API Gateway e Ingress]
subgraph VPC[VPC del proyecto]
FN["Cloud Functions<br/>integración y terceros"]
PS[Pub/Sub]
subgraph GKE[GKE · servicios core]
U[Usuarios]
A[Afiliación]
S[Servicios]
T[Entrenamientos]
E[Eventos]
CQRS["Publicadores y proyectores<br/>por dominio CQRS"]
end
SQLW[("Cloud SQL<br/>escritura y bases únicas")]
SQLR[("Cloud SQL<br/>modelos de lectura")]
end
end
USERS --> WEB
USERS --> MOBILE
WEB --> BFW --> EDGE
MOBILE --> BFM --> EDGE
EDGE --> GKE
EDGE --> FN
GKE --> SQLW
GKE --> SQLR
GKE <--> PS
CQRS <--> PS
CQRS --> SQLW
CQRS --> SQLR
FN <--> PS
FN <--> STRAVA
AR -. imágenes .-> RUN
AR -. imágenes .-> GKE
| Capacidad | Desarrollo local | Objetivo GCP |
|---|---|---|
| Clientes y BFF | Procesos locales o contenedores | Angular y BFF en Cloud Run. |
| Servicios core | Docker Desktop Kubernetes, namespace sportapp-local
|
Deployments en GKE. |
| Base de datos | PostgreSQL local o contenedor de pruebas | Cloud SQL PostgreSQL. |
| Mensajería | Dobles o emuladores cuando se definan | Google Cloud Pub/Sub. |
| Imágenes | Docker local | Artifact Registry. |
| Configuración | Composición Terraform y overlay local desde plataforma; manifiestos internos permanecen en cada componente | Raíces Terraform y overlays por ambiente centralizados en plataforma. |
| Secretos | Variables locales no versionadas | Secret Manager e identidades de carga. |
| Observabilidad | Logs y pruebas locales | Cloud Logging, Monitoring, métricas, alertas y SLO. |
| Parámetro | Línea base | Advertencia |
|---|---|---|
| Región | us-central1 |
Debe evaluarse frente a usuarios latinoamericanos y residencia de datos. |
| Zonas |
us-central1-a, b y c
|
El failover multizona no está demostrado. |
| Réplicas iniciales | Dos pods por microservicio | Es una hipótesis, no una capacidad garantizada. |
| Recursos | 2 vCPU y 2 GB por pod | Requiere pruebas por servicio. |
| Escalamiento | HPA entre 60 % y 80 % | Métrica, mínimo, máximo y estabilización pendientes. |
| Carga de referencia | 1.000 solicitudes concurrentes | El experimento histórico no cumplió la meta de latencia menor a tres segundos. |
flowchart LR
PR[Pull request] --> CI[Calidad, pruebas y seguridad]
CI --> IMG[Imagen OCI por digest]
IMG --> AR[Artifact Registry]
AR --> INT[Integración local]
INT --> PROD[Producción con aprobación]
TF[Terraform de plataforma] --> INT
TF --> PROD
STG["Candidato futuro<br/>Staging no creado"]
INT -. requiere una decisión nueva .-> STG
STG -. promoción futura .-> PROD
Las líneas continuas muestran el flujo vigente: integración en el ambiente local y promoción manual a producción. Las líneas discontinuas representan una posibilidad futura. Staging no existe actualmente y no es un paso obligatorio del flujo; antes de crearlo se deberán aprobar su ubicación, raíz Terraform, proyecto, estado, identidad, presupuesto, política de datos, puerta de promoción y ciclo de apagado.
Terraform está implementado en sport-app-platform: el ambiente de desarrollo local se aplicó y verificó, y la raíz de producción (red privada, GKE regional, Cloud SQL HA con PITR, Pub/Sub, WIF e identidades por carga) está validada, pero no aplicada. Continúan pendientes la aplicación en GCP, la capa de borde, RPO/RTO, SLO y la evidencia de despliegue remoto. Véase Infraestructura Terraform.