Archive

Posts Tagged ‘rundeck’

Un SI propre avec iTop, RunDeck, Puppet, FusionInventory

March 23rd, 2011 19 comments

Au vu de mes futures (nouvelles ) activités, et parce qu’au XXI ème siècle, on se doit d’avoir un système d’information propre, j’ai commencé une maquette en n’utilisant que des outils libres. Les objectifs sont multiples :

  • l’information ne doit être déclarée qu’à un seul endroit
  • la configuration des serveurs doit être automatisée
  • disposer d’une CMDB
  • automatisé toutes les tâches possibles

Une CMDB, cékoidonc ?

Avant de rentrer dans la technique, je me permet un petit rappel sur la définition d’une CMDB (Configuration Management DataBase), qui est un concept né et normalisé par ITIL. Comme le décrit Wikipedia, une CMDB recense les composants d’un système d’information. Par exemple, la liste des serveurs, mais aussi et surtout la liste des serveurs d’applications, des applications, et de tout autre composant structurant. Une fois renseigné ces différentes briques, il est possible de les regrouper, notamment par solutions applications et par processus métier, et surtout, de lier toutes ces briques. L’objectif ? Définir des relations de dépendance, entre le métier (par exemple “Vendre des articles via mon site d’ecommerce”) et les briques techniques (le serveur “LDAP”). D’une part, renseigner ces informations oblige à documenter ces interactions, et éviter qu’elles ne soient que dans la tête de l’administrateur, mais pour un administrateur, cela permet de répondre à la question fatidique “qu’est ce qui se passe si je change mon serveur LDAP”. Bon nombre d’administrateur vont me dire “mais je sais très bien quelles applications utilisent le LDAP” ou bien encore “c’est dans Puppet, donc j’ai pas à m’en occuper”, je leur répondrais alors “oui, toi tu es conscient de l’impact technique. Si je demande à ta direction s’ils mesurent les impacts business de ta migration, ils vont en penser quoi ?” (Et là, je viens de me faire des ennemis, mais c’est une autre histoire).

Jusqu’il y a encore quelques années, je n’avais trouvé aucun logiciel opensource me permettant de créer cette CMDB. En effet, la plupart des logiciels de ce genre viennent avec un modèle déjà tout prêt. Cependant, nous n’avons pas tous les même besoin, et j’irais presque jusqu’à dire pas tous la même manière de les représenter (même si justement ITIL décrit un modèle de référence). Or, il y a quelques mois de cela, j’ai découvert un nouveau logiciel dans ce monde très spécifique, à savoir iTop. C’est un outil GPL, écrit en PHP, et d’origine française. Ses auteurs sont des anciens de HP, pour qui ils ont déjà travaillés sur ces problématiques. Résultat, bien qu’encore jeune, iTop est un outil formidable, car très simple d’utilisation, mais aussi par sa richesse. En effet, il est relativement aisé de modifier le modèle par défaut (au hasard celui d’ITIL) pour l’adapter à ses besoins. Pour citer un des fondateurs de la société Combodo éditrice de ce logiciel, il est tout à fait possible de schématiser une école maternelle avec ses élèves, ses professeurs, ses salles, etc. C’est typiquement le genre de logiciel que j’affectionne, il répond à un besoin, mais via une approche framework que logiciel rigide.

Exemple d’un processus métier

Voici un exemple du processus métier gérer la configuration. Étant administrateur système mon métier reste technique, chez d’autres sociétés, “Gérer la configuration” sera plutôt une solution applicative qu’un processus métier.

iTop : processus métier

La gestion des jobs

Dans un SI, avec plein de serveurs, il peut être intéressant de pouvoir exécuter des jobs, aussi bien à intervalle régulier, que de manière occasionnelle. Bien entendu, chaque UNIX vient avec un daemon CRON, mais celui-ci est mono serveur, à une syntaxe différente entre les différents UNIX, etc. On pourrait très bien imaginer de gérer les fichiers cron via le logiciel de conformité de configuration, mais cela ne répond qu’au besoin de jobs réguliers. Pour cette brique, je me suis tourné vers RunDeck. Cet outil est un job scheduler en Java, encore une fois un projet relativement jeune, mais qui profite d’une grande expérience puisqu’il est issu des même développeurs que ControlTier, autre outil de job scheduling. Avec quelques lignes de développement PHP, RunDeck utilise iTop pour obtenir la liste des nodes (serveurs), et utilise une notion de tags dans iTop, pour rajouter par exemple le tag puppet que je défini sur les serveurs où l’agent est installé.

La conformité de la configuration

Chers lecteurs, étant donné que vous êtes en grande majorité des administrateurs systèmes, je vais passer outre la description de Puppet. Pour les autres, en quelques mots, c’est un outil qui permet de s’assurer que des classes de serveurs soient configurés de la même manière, par exemple en forçant la présence de tel ou tel package, que le fichier /etc/sshd/sshd_config soit identique, et ce à partir d’un fichier maître, etc. Par défaut, un daemon est présent sur chaque nœud, mais pour ma part j’ai choisi de ne pas l’utiliser, et d’exécuter l’agent via un job RunDeck (avec mon fameux tag). Cela me permet de centraliser via la WebUI de RunDeck la sortie des différentes instances des agents, et également de pouvoir exécuter l’agent avant d’attendre le prochain scheduling

La gestion de l’inventaire

Jusqu’ici, j’ai déclaré mes serveurs (grosso modo nom, adresse IP, informations SSH) dans iTop, mais j’aimerais bien avoir un inventaire plus précis, comme par exemple la liste des packages installés, la quantité de mémoire, etc. Ça tombe bien, il existe un outil performant pour faire l’inventaire d’une machine UNIX, à savoir FusionInventory. Et vous allez me demander, comment intégrer tout ça ? (en fait, je me doute que vous l’aurez déjà deviné). Tout simplement en forçant la présence du paquetage via Puppet, et l’exécution d’un inventaire toujours via Puppet (j’aurais pu également le faire via RunDeck cependant). Ensuite, je collecte le XML que génère FusionInventory, je lui applique quelques XSL, et j’intègre le résultat dans iTop, et tout ça de manière automatique. Voila, la boucle est bouclée.

Pour résumer

Les liens entre les composants

Et demain ?

Et bien, demain, je vais coupler de manière plus forte iTop et puppet. Avec un peu de travail, mais rien de bien compliqué, je vais pouvoir faire en sorte que iTop soit l’origine d’une partie de la configuration, notamment celle métier. L’objectif est par exemple, via iTop, de créer une nouvelle instance Tomcat sur un serveur, et que puppet assure son installation (je le fais déjà, mais via les fichiers de configuration puppet).