Skip to main content

Configuration OpenENT

Concerne :Super-administrateur

/admin/configuration/openent — supervision technique de la plateforme :

  • Cluster Hazelcast (membres, event bus, souscriptions, adminstration des modules, métriques Hazelcast et JVM),
  • Kubernetes,
  • Versions des modules déployés,
  • Visualisation des variables utilisées par les modules
  • Création automatique des permissions pour la plateforme lors de l'initialisation d'un déploiement d'un nouvel Open ENT
  • Administration de la plateforme Open ENT par API (utilisation du Open ENT Cli)
  • Paramètrages des logs en temps réel
  • Journaux et événements NATS.
  • Administration du moteur de recherche Open Search
  • Geolocalisation des établissements et des batiments des établissements
  • Gestion des salles (Initialisation RBS - Remote Booking System)
  1. 1Identifiant unique du nœud Hazelcast — UUID de l'instance en cours d'exécution.
  2. 2Adresse IP et port — où le nœud écoute pour les connexions du cluster (ex: 127.0.0.1:5701).
  3. 3État du nœud — ACTIVE (actif), PASSIVE (en attente), ou FAILED (en erreur).
  4. 4Version du cluster — numéro de version de Hazelcast déployée.
superadmin
  1. 1Identifiant unique du module Vert.x supportant l'événement.
  2. 2Process.
  3. 3Adresse IP au sein du cluster Kubernetes.
  4. 4Metadonnée du module.
superadmin
  1. 1Adress du bus d'évenement.
  2. 2Noeud supportant l'adresse.
  3. 3Adresse Local. Quand on parle d'une adresse locale, cela signifie que le message est échangé à l'intérieur de la même instance Vert.x, sans passer par le réseau ni être distribué sur d'autres nœuds.
superadmin

Cette vue offre une supervision centralisée des modules composant la plateforme Open ENT. Elle permet de suivre leur état d’exécution, d’identifier rapidement les éventuelles anomalies et d’effectuer les principales opérations d’administration sans accéder directement aux serveurs. Depuis cette interface, un administrateur peut notamment démarrer ou arrêter un module, consulter ses journaux d’exécution ou déclencher son redéploiement afin de corriger un incident ou déployer une nouvelle version tout en limitant l’impact sur les utilisateurs.

  1. 1Détection des modules en erreur.
  2. 2Nombre de modules démarrés.
  3. 3Nom des modules. Les modules peuvent être soit dans la JVM de l'Open ENT Launcher ou bien dans un container Docker déployé dans Kubernetes.
  4. 4Chaque module peut être arrêté et démarré
  5. 5Redéploiement d'un module par une version plus récente ou sans anomalie sans interruption de service
  6. 6Visualisation des logs spécifiques au module
superadmin
Paramètrage d'un module. Tous les modules ont une configuration exprimé en YAML paramètrablesuperadmin
Visualisation des logs spécifiques à un modulesuperadmin
Changement de version d'un module à chaud sans interruption de service (avec redémarrage d'un POD dans Kubernetes ou au sein d'une JVM)superadmin
Métriques JVMsuperadmin

Cette vue permet de vérifier rapidement l’état des modules déployés sur la plateforme Open ENT ainsi que les informations de traçabilité associées à chaque version. Elle est particulièrement utile lors des opérations d’exploitation, de diagnostic ou de support afin d’identifier précisément la version exécutée, l’origine du code source utilisé pour la construction du binaire et l’environnement technique associé (framework, JDK, date de compilation, etc.). Les différents indicateurs affichés facilitent également la détection d’éventuelles anomalies de déploiement ou de cohérence entre les modules.

  1. 1Détection des modules en erreur.
  2. 2Technologies utilisés (Vert.x pour les anciens modules, Quarkus pour les nouveaux (voir ADR 001).
  3. 3Version présent dans le container ou dans le jar.
  4. 4Version de Vert.x si disponible.
  5. 5Branche de code utilisé pour construire le module.
  6. 6Commit du code
  7. 7Date du binaire construit par Github
  8. 7Version du JDK utilisé
superadmin