Risu Server

Voir en un coup d'œil quels services tournent sur quels serveurs, ce qui dépend de quoi, et ce qui est en bonne santé — sans fouiller dans des dizaines de fichiers README éparpillés.

Le projet

Lors de la reprise du parc informatique de KalyaSante, la question s'est posée immédiatement : où est hébergé tel service ? Que se passe-t-il si ce serveur tombe ? Quels autres services en dépendent ? Sans réponse claire, garantir la sécurité, le suivi et la redondance était mission impossible.

Risu Server est la réponse : un panneau web auto-hébergé qui centralise le recensement des serveurs et des services, documente leurs dépendances mutuelles et surveille leur état de santé. Il tourne aujourd'hui en production et monitore l'ensemble du parc Kalya.

Ce que ça fait

• Inventaire serveurs et services — chaque service documente ses ports, son hébergeur, une couleur identifiable et des notes rédigées en Markdown
• Graphe de dépendances interactif — visualisation des liens entre services (quel service dépend de quel autre, avec labels et types de relation), navigable et réorganisable à la souris
• Surveillance en continu — health check configuré par service, état visible en un coup d'œil depuis le tableau de bord
• API REST publique v1 — intégration dans des pipelines externes (scripts, CI, outils tiers) via token Bearer, avec documentation Swagger générée automatiquement
• Authentification OAuth configurable — se connecte à n'importe quel provider (maison ou standard) via variables d'environnement, sans modifier une ligne de code

Le défi

Le plus délicat à construire : la visualisation des dépendances. Un service peut dépendre de plusieurs autres, qui dépendent eux-mêmes d'autres services — le graphe peut vite devenir illisible. Intégrer cytoscape et vis-network avec du drag-and-drop a demandé de trouver le bon équilibre entre densité d'information et clarté de lecture.

L'autre enjeu : rendre le panneau déployable dans n'importe quel environnement sans toucher au code. Le système OAuth est entièrement piloté par variables d'environnement — endpoints, mapping des champs utilisateur, PKCE, mode strict — pour s'adapter aussi bien à un provider interne qu'à un service du marché. Le déploiement Cloudron est packagé clé en main.

Comment ça fonctionne

graph LR
    Browser["Navigateur\n(Svelte SSR)"]
    External["Outils externes\n(scripts, CI…)"]

    Browser -->|OAuth session| Web["Pages web\nInertia"]
    Browser -->|OAuth token| Compat["API compat front\n/api/*"]
    External -->|Bearer token| API_V1["API REST v1\n/api/v1/*"]

    Web --> Core["Controllers → Lucid ORM → SQLite"]
    Compat --> Core
    API_V1 --> Core

L'application est un monolithe AdonisJS exposant trois surfaces distinctes : les pages web Svelte rendues en SSR via Inertia, une API interne consommée par le frontend pour les données en temps réel, et une API REST versionnée ouverte aux intégrations externes. Chaque surface possède sa propre stratégie d'authentification.

En image

Chaque nœud représente un service ou un serveur ; les lignes illustrent les dépendances qui font la solidité — ou la fragilité — d'une infrastructure.

Stack

Liens

• Code source → (open source, licence MIT)