Añadir ovh-cloud/docs/arquitectura.md
This commit is contained in:
parent
ef88432a87
commit
faf459e0f8
81
ovh-cloud/docs/arquitectura.md
Normal file
81
ovh-cloud/docs/arquitectura.md
Normal file
@ -0,0 +1,81 @@
|
|||||||
|
# Arquitectura
|
||||||
|
|
||||||
|
## Papel de OVH
|
||||||
|
|
||||||
|
OVH es la frontera pública endurecida de MESAVAULT.
|
||||||
|
|
||||||
|
Su papel correcto es:
|
||||||
|
|
||||||
|
- publicar servicios web
|
||||||
|
- centralizar identidad y MFA
|
||||||
|
- alojar tenants de cliente
|
||||||
|
- enrutar subrutas públicas
|
||||||
|
- actuar como ingress LoRaWAN
|
||||||
|
- hablar con el stack por Tailscale
|
||||||
|
|
||||||
|
## Separación correcta con platform-40
|
||||||
|
|
||||||
|
La arquitectura consolidada es:
|
||||||
|
|
||||||
|
### OVH
|
||||||
|
- Traefik
|
||||||
|
- Authentik
|
||||||
|
- logout handler
|
||||||
|
- Gateway Bridge
|
||||||
|
- tenant Grafana del cliente
|
||||||
|
- routing `/control/*`
|
||||||
|
|
||||||
|
### platform-40
|
||||||
|
- Mosquitto
|
||||||
|
- ChirpStack core
|
||||||
|
- Grafana interno
|
||||||
|
- MinIO
|
||||||
|
- Portainer
|
||||||
|
- PostgreSQL
|
||||||
|
- servicios de vertical
|
||||||
|
- persistencia real
|
||||||
|
|
||||||
|
## Principio clave
|
||||||
|
|
||||||
|
OVH no guarda datos del backend. OVH enruta y autentica. `platform-40` sí guarda datos.
|
||||||
|
|
||||||
|
## Caso drenaje
|
||||||
|
|
||||||
|
Arquitectura final documentada:
|
||||||
|
|
||||||
|
Cliente final
|
||||||
|
→ `https://elpicon.panel.mesavault.es`
|
||||||
|
→ Grafana tenant del cliente en OVH
|
||||||
|
→ iframe a `/control/ui`
|
||||||
|
→ OVH VPS
|
||||||
|
→ Traefik + Authentik + routing `/control/*` + logout handler + Tailscale
|
||||||
|
→ `platform-40`
|
||||||
|
→ `drain_control_api`, `drain_control_scheduler`, `drain01_norm`, `drain01_pg`, `mv_postgres_hot`, `mv_mosquitto`, `cs_chirpstack`
|
||||||
|
→ ChirpStack
|
||||||
|
→ nodo físico `LSN50 + XKC`
|
||||||
|
|
||||||
|
## Decisión clave de publicación
|
||||||
|
|
||||||
|
Se valoraron dos estrategias:
|
||||||
|
|
||||||
|
- subdominio separado para control
|
||||||
|
- subruta dentro del mismo tenant
|
||||||
|
|
||||||
|
La decisión final fue:
|
||||||
|
|
||||||
|
- publicar la UI en `/control/` bajo el mismo host del tenant del cliente
|
||||||
|
|
||||||
|
Motivos:
|
||||||
|
- un solo host por cliente
|
||||||
|
- más limpio para escalar
|
||||||
|
- mejor integración visual
|
||||||
|
- más fácil de embeber en Grafana
|
||||||
|
- arquitectura más coherente con el tenant público del cliente
|
||||||
|
|
||||||
|
## Tailscale
|
||||||
|
|
||||||
|
Tailscale es el enlace correcto entre OVH y `platform-40` para que OVH hable con el stack sin abrir servicios internos a Internet.
|
||||||
|
|
||||||
|
## Advertencia importante
|
||||||
|
|
||||||
|
Con Tailscale activo, cualquier contenedor publicado en `0.0.0.0` en `platform-40` pasa a ser accesible también por la interfaz Tailscale. Por eso el criterio correcto de exposición mínima se reforzó tanto en el frontal como en el backend.
|
||||||
Loading…
x
Reference in New Issue
Block a user