Configuration OpenENT
/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.
- Espace de stockage : occupation des volumes de l'ENT (fichiers déposés, modules, assets)
- Administration du moteur de recherche Open Search
- Geolocalisation des établissements et des batiments des établissements
- Gestion des salles (Initialisation RBS - Remote Booking System)
Espace de stockage
Onglet Monitoring > Stockage. Une jauge par volume de l'ENT : ce que pèse son contenu, et la place restante sur le disque qui le porte.
C'est là qu'on voit venir la saturation — en particulier quand les enregistrements de visioconférence commenceront à s'y déposer, la vidéo pesant sans commune mesure avec le reste.
« Occupé par ce volume » est la taille de son contenu. « Disque » est la place du système de
fichiers sous-jacent, partagée par tous les volumes du même nœud. Et la taille demandée dans le
PVC n'est pas un quota : avec un stockage local-path, un volume peut la dépasser jusqu'à remplir
le disque du nœud. Une jauge à 40 % du disque ne dit donc pas qu'il reste 60 % pour ce volume-là.
La mesure est faite dans le pod de l'ENT, seul endroit où ces volumes sont montés — et non depuis Kubernetes, ce qui aurait demandé des droits bien plus larges (exécution de commandes dans les pods, ou accès aux nœuds) pour afficher une jauge. Elle parcourt les répertoires : sur un stockage bien rempli, elle prend quelques secondes, d'où le bouton Mesurer plutôt qu'un rafraîchissement continu.
- 1Identifiant unique du nœud Hazelcast — UUID de l'instance en cours d'exécution.
- 2Adresse IP et port — où le nœud écoute pour les connexions du cluster (ex: 127.0.0.1:5701).
- 3État du nœud — ACTIVE (actif), PASSIVE (en attente), ou FAILED (en erreur).
- 4Version du cluster — numéro de version de Hazelcast déployée.
- 1Identifiant unique du module Vert.x supportant l'événement.
- 2Process.
- 3Adresse IP au sein du cluster Kubernetes.
- 4Metadonnée du module.
- 1Adress du bus d'évenement.
- 2Noeud supportant l'adresse.
- 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.
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.
- 1Détection des modules en erreur.
- 2Nombre de modules démarrés.
- 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.
- 4Chaque module peut être arrêté et démarré
- 5Redéploiement d'un module par une version plus récente ou sans anomalie sans interruption de service
- 6Visualisation des logs spécifiques au module
La version cible se choisit de trois façons :
- une version déjà présente sur disque, c'est-à-dire déployée au moins une fois sur la plateforme : la bascule est immédiate, sans téléchargement ;
- une version publiée dans le dépôt Maven mais jamais installée ici : elle est listée avec sa date de publication et le launcher la télécharge au moment du déploiement ;
- un numéro de version saisi à la main, utile quand la version vient d'être publiée ou que le dépôt n'est pas interrogeable depuis le dashboard.
Une version absente du disque est d'abord recherchée dans le dépôt : un numéro erroné est refusé sans que le module en service ne soit arrêté. Si le téléchargement ou le démarrage de la nouvelle version échoue malgré tout, la version précédente est automatiquement remise en service.
Pour recharger un module sans changer de numéro de version — cas des modules forkés, dont l'artefact est republié sous les mêmes coordonnées — on utilise l'action « Mettre à jour depuis le dépôt » de la vue Modules & versions, et non le changement de version.
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.
- 1Détection des modules en erreur.
- 2Technologies utilisés (Vert.x pour les anciens modules, Quarkus pour les nouveaux (voir ADR 001).
- 3Version présent dans le container ou dans le jar.
- 4Version de Vert.x si disponible.
- 5Branche de code utilisé pour construire le module.
- 6Commit du code
- 7Date du binaire construit par Github
- 7Version du JDK utilisé