Circuito
Por dónde viaja cada petición y quién la atiende hoy, del navegador a los datos. El tramo resaltado es el activo.
Leyendo el estado del circuito.
Frontend: sitios web
Cada sitio de kutamma.com pasa por Cloudflare. Un Worker pide el contenido a Firebase y, si falla, a Cloudflare Pages.
Navegador
Quien abre un sitio de kutamma.com.
Cloudflare
DNS, proxy y certificado. El navegador nunca ve el dominio de Firebase ni el de Pages.
Worker de enrutado
Decide el origen de cada petición.
Modo: sin datos.
Firebase Hosting
Sin datos.
Sin datosCloudflare Pages
Sin datos.
Sin datosModo de conmutación del frontend
Esperando datos…
- AutomáticoFirebase y, si falla, Pages
- Solo FirebaseSin respaldo
- Forzar PagesTodo desde Cloudflare Pages
Cada botón abre un pipeline de GitLab con el modo elegido. Pulsa edge-apply; aplica en menos de un minuto. Un pipeline posterior sin variable vuelve a automático.
Tiendas
Las tiendas (csr-store) corren en Cloud Run, detrás de un balanceador de GCP. Un registro pivote, tiendas.kutamma.com, apunta a GCP o a OVH según el estado de cada lado.
Visitante
Quien abre el dominio de una tienda.
tiendas.kutamma.com
Pivote con proxy de Cloudflare. Cada minuto un Worker comprueba /api/health de ambos lados.
GCP, Cloud Run
Balanceador en 136.110.132.168.
Sin datosOVH, k3s
Túnel de Cloudflare hacia Traefik y la tienda.
Sin datosModo de conmutación de las tiendas
Modo actual: desconocido. Destino que atiende ahora: desconocido.
Sin datos del conmutador.
Los botones abren un pipeline de GitLab con el modo elegido; pulsa apply y el Worker lo toma en el siguiente minuto.
Ojo: mientras los dominios de tienda sigan apuntando directo al balanceador de GCP y no al pivote, este conmutador no cambia nada para ellos.
Backend: API
Las aplicaciones llaman a ingress.kutamma.com. Un Worker prueba GCP y, si no responde, atiende desde OVH; cuando GCP vuelve, el tráfico regresa solo.
Apps y clientes
Web, móvil y servicios que consumen la API.
ingress.kutamma.com
Proxy de Cloudflare con el Worker de conmutación, que decide el destino en cada petición.
Sin datosGCP, producción
Entrada en 34.168.114.23. Su interior no se monitorea desde aquí.
Sin datosOVH, DRP
Túnel de Cloudflare hacia Traefik en el K3s.
Sin datosDentro de OVH
Servicios (apps)
Sin datos.
Sin datosDatos
- PostgreSQLSin datos
- RedisSin datos
- NATSSin datos
- MongoDB Atlasexterno, compartido
Modo de conmutación de la API
Modo actual: desconocido. Destino que atiende ahora: desconocido.
Sin datos del conmutador.
En automático no hace falta tocar nada: un Worker comprueba GCP y OVH cada minuto, pasa a OVH tras 2 fallos seguidos de GCP y vuelve a GCP tras 3 aciertos seguidos. El cambio de registro DNS es casi instantáneo porque el registro tiene proxy. Los botones abren un pipeline de GitLab con el modo elegido; pulsa apply y el Worker lo toma en el siguiente minuto. Un pipeline posterior sin variable vuelve a automático.
Ojo con los datos: PostgreSQL y Redis de OVH no se replican con los de GCP. Mientras OVH atiende, sus escrituras no llegan a GCP.