Voilà le fruit d'une recherche de solutions au niveau du thème "gestion des ressources", pour les besoins de la DSI.
Précision : "ressources", dans ce contexte, désigne les PC des salles de TP (puisqu'on parle de la plateforme d'enseignement), mais peut également désigner les serveurs (hébergeant moodle, le webmail, les VMs, etc).
L'objectif de cette recherche est de trouver une solution qui permette, grosso modo :
- de s'assurer que la configuration des machines de TP est bien celle souhaitée
- et dans le cas contraire, la solution doit permettre d'amener les machines dans l'état souhaité
Ces deux objectifs sont respectivement de l'ordre de la supervision et de la gestion de configuration.
Une bonne solution, du point de vue de la DSI, doit passer par une interface de contrôle et de pilotage, type tableau de bord, qui :
- affiche l'état des différentes machines (groupées intelligemment par bâtiment, salle, ou autres critères pertinents)
- pour une machine donnée, affiche des indicateurs permettant en un coup d'oeil de savoir en quoi l'état actuel de la machine diffère de l'état souhaité
- permette de déclencher en temps réel des actions dont le but est de corriger ou prévenir d'éventuels problèmes. Par exemple, il faudrait pouvoir facilement et rapidement :
- éteindre les PC d'une salle donnée
- installer ou reconfigurer un logiciel sur un ensemble de PC
- tester qu'une machine répond bien au ping
- etc.
Idéalement, cette interface présenterait par défaut des indicateurs qui concernent les salles de TP où ont lieu des cours en ce moment même, le système faisant le lien entre la date actuelle, le TP en question, et l'état dans lequel devraient se trouver les machines. Ce lien se ferai grâce aux données présentes dans l'emploi du temps et dans une base de connaissances.
Ainsi donc, les deux objectifs à atteindre sont de l'ordre de la supervision et la gestion de configuration des machines.
L'objectif de supervision trouve de nombreuses solutions. Deux modes sont généralement utlisés :
- "monitor poll" : le serveur se connecte aux clients pour récupérer des informations.
- Avantages : rien a installer sur les clients, aucun service ne tourne tant que la sonde ne passe pas. De plus, comme toute la logique de supervision est centralisée sur le serveur, cela fait un unique point à administrer.
- Inconvénients : les clients doivent intégrer un moyen d'accès (telnet, ssh), et doivent être joignables depuis le serveur. De plus, cela demandes d'importantes ressources côté serveur.
- "agent push" : un service est installé sur les postes et c'est lui qui va se charger de récupérer des informations et de les envoyer périodiquement au serveur.
- Avantages et inconvénients : inverses du mode "monitor poll".
Idéalement, notre solution de supervision lancerait des checks périodiques sur les machines, vraisemblablement avant le début des TP (pour tester la chaîne de configuration), et de manière générale, afin de tester le bon fonctionnement des machines en continu.
La chaîne de configuration serait un ensemble de tests qu'il est nécessaire de valider. Le succès de ces tests est censé être suffisants pour prouver qu'une machine est fonctionnelle et prête à accueillir un TP donné.
TODO : expliciter le besoin de la DSI et la solution répondant à ce besoin, en ce qui concerne la supervision. En gros :
- on a besoin de données fraîches quand un TP va avoir lieu bientot
- la chaine de configuration peut être composée de nombreux éléments qui sont récupérés dans la base de connaissance : quels genre d'éléments, accédés/modifiés par qui ?
- une fois récupérés les données d'un check, est-ce qu'on gère différents niveaux de criticités, si oui comment décide-t-on de cette criticité..
Pour rappel, le second objectif est d'avoir un outil permettant de faire en sorte que l'ensemble du parc soit dans l'état souhaité.
Il existe des solutions très populaires pour pallier exactement à ce problème, appelés outils de Configuration Management (Gestion de la configuration). Voici un petit billet qui présente le concept.
En très bref, dans ces outils, on retrouve généralement des fichiers textuels qui décrivent l'état dans lequel on souhaite qu'une machine soit. Exemple fictif :
"Toutes les machines du parc sous CentOS 6 doivent avoir le paquet "git" d'installé, et un fichier /etc/gitconfig dont le contenu est celui ci : /un/modele/de/gitconfig"
Ce fichier ne fait que décrire un état fictif, mais avec des outils de configuration management, la réalisation de cet état sur un parc de machines est l'affaire d'une simple commande.
Les outils de gestion de configuration, dans le cas de grands parcs de machines, s'utilisent généralement en mode client/serveur : le serveur contient la configuration du parc, les clients ne font que récupérer et appliquer cette configuration à eux mêmes, s'ils sont concernés par certains critères. Par exemple, on peut souhaiter que les machines du bâtiment 501 sous Windows disposent de Matlab, et pas les autres machines. Au sein des outils de gestion de configuration, il est généralement facile de désigner un ensemble de machines partageant un critère commun. On peut se baser sur des caractéristiques de la machine (son système d'exploitation, sa quantité de RAM, son hostname, etc.), ou bien sur une liste arbitraire pré-établie côté serveur.
Tout comme pour les outils de supervisions, on retrouve des systèmes de gestion de configuration qui utilisent un agent, et d'autres non. Les avantages et inconvénients sont similaires à ceux détaillés dans la partie supervision.
TODO
Comme évoqué plus haut, notre solution requiert des données piochées dans l'emploi du temps et dans une base de connaissance.
Il faut voir quelles données sont stockées dans l'emploi du temps (intitulés des TPs, enseignants, bâtiment, salle, horaire, N°groupe) et quelles données sont stockées dans la base de connaissance (liste des élèves, répartitions en binômes/hexanômes, logiciels et fichiers nécessaires pour ce TP, quels PCs se trouvent dans quelle salle, etc.).
D'ailleurs, je parle d'une base de connaissance, mais rien n'indique qu'elle doit être unique, on pourrait imaginer qu'elle soit répartie entre un annuaire LDAP, une base PostgreSQL, une base SQL Server, un service web maison avec une api REST, etc. Mais du coup ça serait la merde quand un de ces trucs tombe : il faudrait donc idéalement un point central, si possible redondé. Reste à voir si :
- on traite la migration des données vers un point central
- on considère que c'est déjà tout centralisé
- on considère que il n'y aura pas de problèmes car on a confiance dans l'existant (par exemple s'il n'y a que 3-4 points centraux en lesquels on a confiance)
À mon avis ça sera un mix de 1) et 3) à détailler (surtout quand on parlera du déploiement). Ça peut impliquer beaucoup de changement au niveau de l'aspect données du SI.
On exclut d'office les outils non multiplateforme. Restent :
- en supervision : Nagios, Icinga, Centreon, Shinken, Zabbix, OpenNMS...
- en configuration management : Chef, Puppet, CFEngine, Salt..
La plupart de ces outils proposent un agent à installer sur les postes clients. Salt est une solution récente proposant une nouvelle approche pour cet agent, basée sur une connexion permanente entre lui et le serveur, permettant ainsi une réactivité immédiate. Grâce à ses capacités avancées d'exécution distante et de gestion de configuration, on choisit de placer Salt en tant que candidat à la fois pour la supervision et la gestion de configuration.
On choisit d'intègrer également OCS Inventory NG dans les candidats, car cet outil est possiblement déjà installé sur certains postes administratifs, et s'intègre à GLPI pour la gestion du parc informatique et du support. OCS Inventory NG permet avant tout la gestion d'inventaires (matériels et logiciels) de parcs informatiques, mais a également été doté d'une solution de déploiement de logiciels sur les postes clients.
Avantages :
- intégration transparente à GLPI
- installation simple
- interface web native
Inconvénients :
- peu customisable
- monitor poll : pas de réactivité
- pas vraiment d'apect "gestion de la configuration" avancé
Avantages :
- extrêmement souple : création aisée de ses propres checks, targetting avancé, évènements custom
- en mode connecté de l'agent vers le serveur
- "scalable enough to manage tens of thousands of servers, and fast enough to communicate with them in seconds"
- l'agent push comme le monitor poll sont envisageables
- interface web native
- mutual auth
- développement très actif
Inconvénients :
- pas d'intégration à GLPI
- avant tout un outil/framework, et non pas un logiciel clef en main
- pas un outil de supervision à la base, mais d'exécution distante (notion plus générale) : nécessité de réaliser soi même la gestion des checks et leur sauvegarde
Par sa souplesse et son développement actif, Salt est une solution qui satisfait nos besoins et qui promet de résoudre également les problèmes d'infrastructure auxquels nous pourrons être confrontés dans le futur.
En contrepartie, ce choix va nécessiter certains développements pour pouvoir adapter cet outil au contexte particulier de la DSI. Heureusement, Salt est justement pensé pour ne pas présupposer une utilisation particulière, mais au contraire pour laisser un maximum de libertés à l'utilisation. Cela se retrouve par exemple dans le fait que :
- l'outil s'utilise aussi bien en CLI (Command Line Interface) que via une API HTTP, une interface web avancée ("clicodrome"), ou via un SDK en python
- une action côté serveur peut en déclencher côté clients (fonctionnement traditionnel de la remote execution), aussi bien qu'un évènement remonté volontairement depuis le client peut déclencher une action côté serveur (via une simple attente sur le bus d'évènements)
- la plupart des choix par défaut (langage de templates, de représentation des données, SGBD des informations en cache, SGBD des données renvoyées par les clients, type du file server) disposent de nombreuses alternatives, et il est généralement simple de rajouter les siennes
Notamment, le développement d'une interface web dédiée à l'usage spécifique de la DSI, le lien avec la base de connaissance, et le développement d'un module de supervision gérant les chaînes de configuration, sont à réaliser.
TODO
Bla bla, on explique quelle solution on choisit pour la base de connaissance.
La mise en place de Salt et de la base de connaissance dans l'infrastructure cible conduirait en théorie à un résultat final proche de celui ci :
- Un ou des Salt Master (serveur maître), avec une nécessité de redondance pour éviter un Single Point Of Failure
- Des Minions (clients avec l'agent d'installé) connectés au Salt Master
- TODO Une base de connaissance répartie comme ceci, et contenant cela (à compléter ;])
- Une application web dédiée au pilotage de l'ensemble
- Un gestionnaire de déclenchements d'actions (ex : lancement de sondes de supervision, lancement d'un déploiement, création d'un ticket support) basé sur des évènements (ex : insertion d'une valeur dans la base de connaissance, fin d'un timer pour une tâche planifiée...). Ce module pourrait tirer partie de l'event bus du Salt Master, ou bien être indépendant.