Aller au contenu principal

Central — Vue d'ensemble

Le central est le projet de supervision de parc : Saturn (API REST), Venus (gateway GraphQL + serveur web) et Mercure (API logs), avec PostgreSQL pour les données métier (auth, inventaire nodes, IP, noms) et une API logs Python dédiée qui indexe et requête les logs des nodes dans Elasticsearch.

Un service DNS/DHCP indépendant (central-dnsdhcp, Go) expose un CRUD HTTP pour les records DNS et DHCP, avec sa propre base PostgreSQL dédiée.

Dans le contexte cible, le central est le logiciel de contrôle dédié aux sociétés de services (eau, électricité, connectivité) pour opérer un réseau de boîtiers déployés dans les maisons.

:::info Découplage des logs L'API centrale (saturn) ne se connecte plus directement à Elasticsearch. Elle délègue toute l'ingestion et la lecture des logs à un microservice Python (central-mercure), seul composant à parler à Elasticsearch. :::

Le projet domotic reste local au node et sert au pilotage des équipements attachés à la combinaison nano-ordinateur + cartes d'E/S.

Architecture globale (intégrée)​

leukOS est une architecture distribuée à deux niveaux :

  • un plan local node (projet domotic) pour piloter les équipements connectés à un nano-ordinateur + cartes d'E/S ;
  • un plan central de supervision de parc (central) pour voir les nodes connectés, orchestrer les actions et historiser.

Le scénario cible est un déploiement territorial : un boîtier par maison, piloté localement (écran) et à distance (mobile), avec un central opérateur pour les sociétés de services.

La supervision distante passe aujourd'hui principalement par HTTP/GraphQL.

Schéma d'ensemble​

Architecture globale leukOS

Vue globale de l'architecture leukOS (nodes, domotique locale et central de supervision).

Les couches​

1. Node (edge)​

Chaque node exécute un daemon C++17 qui constitue l'automate proprement dit :

  • Pilotage matériel via libgpiod (/dev/gpiochip0).
  • Gestionnaires : relais, vannes, compteurs, scheduler, watchdog.
  • Persistance locale en SQLite (/var/lib/leukos/node.db).
  • API REST locale (port 8080) consommée par l'IHM Qt.
  • Client MQTT vers le broker local Mosquitto.

Une IHM Qt6/QML tourne en local sur l'écran tactile du node et n'est qu'un client de l'API REST.

2. Bus de messages (MQTT)​

Le broker Mosquitto local de chaque node gère la télémétrie et les commandes MQTT au niveau node. Dans l'implémentation actuelle, le central n'envoie pas les actions via un bridge MQTT : il appelle l'API locale node en HTTP.

3. Domotic local (node)​

Le projet domotic (Go + web Vue) est local au node et sert à piloter les devices connectés au nano-ordinateur + SM.

4. Central supervision​

Le projet central supervise le parc de nodes et sépare les stockages :

  • PostgreSQL pour l'authentification, l'inventaire des nodes, les noms et IP.
  • Elasticsearch pour l'indexation des logs via mercure.
  • CoreDNS pour la résolution DNS locale.
  • venus (NestJS/GraphQL) sert le web et agrège les APIs.
  • saturn (Go/REST) gère inventaire, actions, DNS.
  • mercure (Python/FastAPI) gère l'accès aux logs Elasticsearch.

Le central est conçu pour une exploitation opérateur :

  • pilotage à distance des accès de services (eau/électricité) via relais et vannes ;
  • supervision multi-sites et audit des actions ;
  • gestion d'une connectivité internet/intranet locale selon la politique de déploiement.

5. Interface web​

Une application Vue 3 + Vite consomme l'API centrale et présente la topologie du parc, l'état de connexion des nodes et les opérations à distance.

Principes structurants​

  • Séparation stricte des responsabilités : les interfaces (Qt, web) ne contiennent aucune logique métier ; tout passe par des API.
  • Autonomie locale : la logique de contrôle vit sur le node.
  • Standards ouverts : MQTT, REST, WebSocket, JSON, YAML.
  • Déterminisme : boucle de contrôle à intervalle fixe, OS minimal Buildroot.

Composants​

Clusters de la flotte​

Cluster DNA (IAM)​

Cluster DNA IAM de la flotte

Le cluster DNA joue le role de manager IAM de la flotte. Dans notre cas, cette brique est portee par Keycloak pour centraliser les identites, les roles et les politiques d'acces.

Il fournit une authentification unique pour les operateurs et les services, et securise les appels entre les couches web, Venus et Saturn.

  • Identites centralisees : utilisateurs, comptes techniques, groupes et roles de la plateforme.

  • SSO operateur : parcours de connexion unifie entre les interfaces d'administration.

  • Controle d'acces : permissions fines par domaine (lecture flotte, actions, logs, administration).

Cluster DNS/DHCP​

Cluster DNS et DHCP de la flotte

Le cluster DNS/DHCP maintient la resolution des noms et l'attribution des adresses pour les nodes et services de terrain.

Il s'appuie sur central-dnsdhcp pour le CRUD reseau et sur CoreDNS pour l'exposition DNS locale.

  • Adressage maitrise : attribution DHCP stable et traçable.

  • Resolution locale : noms de nodes coherents pour les appels de supervision et de maintenance.

  • Automatisation : propagation des changements via API sans edition manuelle de zones DNS.

Cluster Saturn​

Cluster Saturn de supervision

Saturn est le coeur API de supervision: inventaire, dispatch d'actions, integration DNS/DHCP, et orchestration des flux vers les nodes.

Les commandes operateur sont valides, journalisees puis transmises vers l'API locale node selon les politiques de la flotte.

Implémentation Go (architecture hexagonale), exposee sur le port :8130. Saturn sert de facade API pour la supervision, l'inventaire et l'exposition des operations aux couches superieures. Selon les besoins d'integration, Saturn peut aussi se connecter en gRPC a des services internes, en plus des appels REST.

  • Inventaire de parc : etat des nodes, IP, connectivite, metadonnees d'exploitation.

  • Execution des actions : relais/vannes avec traçabilite complete des ordres.

  • Interface de gouvernance : API de reference pour le web, Venus et les services satellites.

  • Dispatch node : les actions sont enfilees puis transmises en HTTP vers l'API locale node (http://<node_ip>:8080).

  • Connectivite mixte : Saturn combine REST et gRPC selon le composant cible (par exemple pour certaines integrations de services).

  • Logs decouples : Saturn interroge l'API logs Python en client REST, sans acces direct a Elasticsearch.

Cluster Venus​

Cluster Venus GraphQL et web

Venus expose la passerelle GraphQL et sert l'interface web de la flotte. Il agrège Saturn et Mercure pour proposer une vue operateur unifiee.

Cette couche simplifie le frontend en masquant les details des services internes et en conservant un contrat API stable.

  • BFF GraphQL : aggregation des donnees metier, reseau et logs.

  • Experience web : supervision temps reel, recherche et pilotage depuis une interface unique.

  • Couplage faible : evolution des backends sans casser les parcours operateur.

Cluster Logs​

Stack logs Mercure Elasticsearch Kafka

Le cluster logs est compose de Mercure (API Python/FastAPI), Elasticsearch (indexation/requete) et Kafka (tampon d'ingestion).

Mercure est implemente en Python + FastAPI (central/mercure) et expose le port :8140 comme point d'acces unique aux logs.

Cette stack peut aussi accueillir une couche IA pour classifier, resumer et detecter des anomalies dans les evenements, afin d'accelerer le diagnostic operateur.

  • Point d'entree unique : l'API centrale et le frontend passent par Mercure pour consulter les logs.

  • Ingestion robuste : les nodes publient vers Mercure, puis Kafka absorbe les pics avant indexation Elasticsearch.

  • Decouplage : Saturn n'accede pas directement a Elasticsearch et consomme Mercure en REST.

  • Usage IA possible : detection d'anomalies, regroupement intelligent d'incidents similaires et priorisation automatique des alertes.

Stockages​

StockageAccédé parUsage
PostgreSQLsaturnAuth, comptes, inventaire des nodes, noms, IP, états de connexion.
Elasticsearchcentral-mercureLogs techniques et événements remontés par les nodes.

L'interface web​

Application Vue 3 + Vite (central/venus/web) : supervision de parc, visualisation des nodes connectés, recherche et consultation des logs.

Elle sert d'interface d'exploitation pour les équipes opérateurs :

  • suivi de l'état du parc ;
  • émission d'actions à distance ;
  • contrôle et audit des événements de service.

Services d'infrastructure​

  • central-mercure : microservice Python d'accès aux logs (Elasticsearch).
  • central-dnsdhcp : microservice Go CRUD DNS/DHCP (records en PostgreSQL dédié).
  • central-kafka : tampon d'ingestion des logs avant indexation.
  • coredns : DNS local (résolution des noms des nodes).
  • postgres : base relationnelle centrale (externe).
  • elasticsearch : indexation et requêtage des logs (externe, via l'API logs).

Le tout est orchestré via central/docker-compose.central.yml.

Pour aller plus loin​

  • API du central — endpoints principaux et flux de commande.
  • API logs — microservice Python d'accès à Elasticsearch.
  • Interface web — le frontend de supervision.
  • Saturn — API de supervision, orchestration node, DNS/DHCP.