Vue d'ensemble du Navin Manager
Le Navin Manager (paquet navin-manager) est la console de gestion de la plateforme IA Navin Enterprise. Elle installe, configure, démarre,
arrête, redémarre, contrôle, débogue et met en cluster tous les services utilisés par la plateforme (LiteLLM,
OPA, OpenFGA, Keycloak, OpenBao, Redis, OpenSearch, Qdrant, ClickHouse, SeaweedFS, Prometheus, Alertmanager, Jaeger,
NATS, Temporal, LiveKit, Opik, Ragas et les composants Navin Enterprise) sur des hôtes bancaires sous Red Hat
Enterprise Linux, Rocky Linux, AlmaLinux, Oracle Linux, CentOS Stream, Ubuntu ou Debian, reliés à Internet ou
entièrement hors ligne.
Elle reprend les principes d'Apache Ambari (un catalogue de services, un assistant d'installation de cluster, un agent sur chaque hôte, des configurations versionnées, des opérations découpées en étapes et en tâches, des alertes) avec le design Navin et un modèle de sécurité pensé pour les banques.
Le schéma d'architecture interactif se trouve dans architecture.html (source : assets/architecture.json).
Briques
| Brique | Rôle |
|---|---|
Serveur (navin-manager serve) | API REST /api/v1, console web, moteur d'opérations, évaluation des alertes, planificateur. Port 8460. |
| API agent | Point d'entrée des agents /agent/v1 et miroir local /repo/. Port 8461, TLS avec certificat client en production. |
Agent (nm-agent) | Tourne sur chaque hôte géré sous forme de service systemd. Il ouvre toutes les connexions (aucun port en écoute sur l'hôte), exécute les tâches du serveur une par une et remonte les faits, les métriques et l'état des composants. |
| Base de la console | PostgreSQL fourni par la banque (cluster séparé). navin-manager s'y connecte seulement. |
| Catalogue | Un descripteur par service : paramètres, modes cluster, composants, fichiers, contrôles de santé, commandes. |
| Miroir hors ligne | Archives, images de conteneurs et paquets Python avec leur sha256, construits une fois hors de la banque puis copiés. |
Notions
Cluster. Ensemble d'hôtes gérés ensemble, en mode production, preprod (pré-production), test,
development (développement) ou sandbox (bac à sable). Les clusters de développement, de test et bac à
sable acceptent les services réservés aux tests (par exemple un PostgreSQL local) ; les clusters de production et
de pré-production les refusent.
Hôte. Machine enregistrée par son agent avec un jeton d'amorçage. Le serveur conserve ses faits (système, CPU, mémoire, disques, SELinux, pare-feu, horloge, Python, Podman, GPU) et évalue les contrôles préalables dès leur arrivée.
Service, composant, mode, méthode. Un service du catalogue (par exemple Redis) possède des composants (serveur, sentinelle), des modes cluster (autonome, réplication, sentinelle, cluster) avec des règles de placement (minimum, maximum, nombre impair pour un quorum, multiple d'un facteur de réplication) et des méthodes d'installation :
| Méthode | Exécution du composant |
|---|---|
binary | Archive officielle vérifiée par sha256, lancée par une unité systemd durcie. |
podman | Image officielle épinglée par empreinte, lancée par systemd sur le réseau isolé du cluster (ports déclarés publiés, --network host seulement si justifié), no-new-privileges et étiquettes SELinux ; rendu Quadlet disponible (installation durcie). |
python | Environnement virtuel installé depuis le dépôt de paquets Python hors ligne. |
package | Paquets du système ou du dépôt de l'éditeur, mis en miroir par la banque. |
Liaison. Un service qui en utilise un autre (LiteLLM utilise PostgreSQL et Redis) reçoit une liaison : soit un service géré dans le cluster, soit une connexion externe vers un cluster que la banque exploite déjà. Les modèles de fichiers voient la même forme dans les deux cas : le choix ne change jamais les fichiers de configuration. Les fournisseurs multi-locataires (PostgreSQL, MySQL, ClickHouse, SeaweedFS) donnent à chaque consommateur sa base, son utilisateur ou son bucket, avec un secret dérivé de la clé maître et jamais stocké.
Service socle. SeaweedFS est le stockage objet de la plateforme : les documents, les médias, les exports, les
sauvegardes et l'archive d'audit WORM y sont rangés, et c'est le stockage prévu pour les skills et les serveurs MCP.
Navin Enterprise et Opik s'y lient. Il est installé par
défaut : l'assistant d'installation le sélectionne dans un cluster qui ne l'a pas encore, et l'ajoute dès qu'un
service sélectionné en a besoin. Ne le décochez que pour lier à la place un stockage S3 existant de la banque (une
connexion de type s3).
Configuration. Chaque modification crée une version (auteur, date, note). Les versions se comparent et se restaurent. Un groupe de configuration surcharge des paramètres pour certains hôtes. Le conseiller recommande des valeurs à partir des faits de l'hôte (par exemple un tas JVM de la moitié de la mémoire, plafonné à 31 Go). Les hôtes dont la configuration en service est plus ancienne que la version courante sont signalés : un redémarrage l'applique.
Opération. Chaque action (installation, démarrage, redémarrage progressif, application de configuration, commande, mise hors service) est une opération composée d'étapes ordonnées ; une étape lance une tâche par hôte en parallèle. Les journaux défilent en direct, une opération en échec se relance à partir de l'étape en échec, une opération en cours peut être interrompue.
Alerte. Des définitions intégrées surveillent les hôtes (signal de l'agent, disque, mémoire, charge, prérequis), les composants (arrêtés, contrôles de santé en échec, redémarrage nécessaire), les certificats, les opérations en échec et la console elle-même. Les alertes se résolvent d'elles-mêmes quand la condition disparaît et notifient des destinataires courriel, webhook ou syslog.
PostgreSQL
PostgreSQL est toujours installé par la banque, dans un cluster séparé : la base de la console et les bases des services de la plateforme sont des connexions externes. navin-manager n'installe un PostgreSQL que dans un cluster bac à sable, pour des tests rapides.