La gestion de configuration est de plus en plus à la mode, à cause des problématiques actuelles de scalabilité et de provisioning de machines en masse dans le cloud. Une autre chose qui soit présente en masse dans une entreprise ou même chez Madame Michu, ce sont les terminaux mobiles et les tablettes. C’est de ce constat qu’est née une idée un peu originale : pourquoi ne pas essayer d’associer le meilleur des deux mondes ?
1. Présentation des principes de la gestion de configuration
1.1. Introduction générale
La gestion de configuration est un concept qui essaie de répondre à des problématiques bien connues de tout administrateur système/réseau en charge d’une infrastructure de plus de 4 machines :
- Toutes mes machines sont-elles à jour ?
- Ce petit correctif que j’ai apporté à la configuration de X, est-il bien présent partout ?
- Si une de mes machines explose/prend feu/se transforme en raton-laveur, serai-je à même de tout reconfigurer correctement dessus pour que ça marche comme je veux ? Et aurai-je le temps de tout faire correctement ?
On peut trouver d’autres exemples du même genre, mais une information importante ressort déjà : passé un petit nombre de machines (tout dépend de la personne), il devient impossible de savoir à un instant T " où on en est ". Et le problème empire quand on n’est pas le seul à gérer tout ça, ce qui j’espère, est le cas dans une infrastructure d’entreprise ou d’association.
Le concept de gestion de la configuration tente de répondre à ce problème, en proposant plusieurs approches (différentes selon les outils) afin de garder un parc cohérent.
Bien sûr, la récente mode du cloud computing et de la scalabilité offre une toute nouvelle dimension à ce concept, en en faisant même une des bases incontournables de tous les gros systèmes de cloud provisioning du moment.
En effet, il devient possible, grâce à un outil de gestion de configuration, de faire un provisioning complet d’une VM, en déployant uniquement des images de base intégrant l’outil choisi, qui se charge au premier démarrage d’installer les services qui seront nécessaires, en fonction de son environnement.
Il est aussi possible, grâce à des outils comme Vagrant (http://www.vagrantup.org) de faire ceci à l’échelle d’un poste de travail, permettant par exemple à un développeur de redéployer des environnements de test propres à volonté.
1.2. CFEngine 3
Différents outils existent pour faire de la gestion de configuration, et ils ont presque tous déjà été couverts par un article dans GLMF ou GLMF hors-série : Puppet, CFEngine 2, Chef...
CFEngine 3 (http://www.cfengine.com) est une réécriture à partir de zéro de CFEngine 2 (vu dans GLMF n° 95), suite aux nombreux retours de la communauté et à ce qui a été appris pendant et après la création de Puppet par un contributeur de CFEngine 2.
Fig. 1 : Historique de l'évolution de CFEngine dans le temps
CFEngine 3 est donc un outil de gestion de configuration moderne, entièrement réécrit récemment, qui se base sur la théorie des promesses (http://en.wikipedia.org/wiki/Promise_theory), nom donné aux configurations à appliquer par l’outil.
Voici un exemple simple d’utilisation de CFEngine 3 :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
############################# # Promesse de création de fichier # ############################# # Le body common control définit ce qui doit être fait par l’agent CFEngine. body common control { # J’inclus ces fichiers de promesses inputs => { "/var/cfengine/inputs/cfengine_stdlib.cf" }; # J’exécute ces bundles bundlesequence => { "create_foobar_in_tmp" }; } # Ce bundle va servir à définir le contenu d’un fichier bundle agent create_foobar_in_tmp { # Les promesses qui suivent agissent sur un fichier files: "/tmp/foobar" create => “true”, # Si le fichier n’existe pas, je le crée # Je crée des classes en fonction de la tenue de la promesse: # file_ok si la promesse est tenue, file_nok si ce n’est pas le cas. # Note: Il est possible d’utiliser trois types d’états en pratique: # Promesse tenue, réparée ou non tenue. On considère ici par simplicité # qu’une promesse réparée est tenue. classes => if_else("file_ok", "file_nok"); reports: files_ok:: "The file is present"; files_failed:: "The file has NOT been created."; } |
1.3. Rudder
CFEngine 3 est un outil très puissant ; il permet à peu près de tout faire avec sa machine, du moment où on est capable de décrire l’état voulu en une promesse du langage CFEngine. Seulement, cette puissance a un prix : il est difficile pour un débutant de pouvoir maîtriser CFEngine rapidement, la courbe d’apprentissage étant assez longue. C’est là que Rudder entre en jeu !
Le projet Rudder (http://www.rudder-project.org) permet une accessibilité simplifiée à la gestion de configuration, via une interface web disposant de promesses déjà pré-conçues. Cette interface vient se poser en tant qu’intermédiaire entre l’utilisateur et CFEngine 3 et lui permet, par exemple, de configurer le serveur OpenSSH sur un groupe de machines simplement en remplissant un formulaire web et en associant la définition ainsi créée à un groupe de serveurs. Rudder se charge ensuite de remonter des informations sur l’application de ces promesses (" Compliance ").
Fig. 2 : Écran principal de Rudder, qui permet de gérer les associations entre une directive (une instance configurée d'une technique) et un groupe de machines.
