Archive

Archive for March, 2011

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).

Makefile et squelette qui va bien pour docbook vers PDF

March 14th, 2011 No comments

Étant donné mon futur changement professionnel (vous en saurez plus dans un futur proche), je me suis confronté au problème de la production des documents (principalement technique). Plusieurs solutions s’offraient à moi, la plus facile, en tant qu’utilisateur de Mac OS X, est d’utiliser Pages, de la suite iWork. Bien que ce dernier soit un produit très adapté pour produire rapidement un joli document, je trouve que la construction d’un thème from scratch n’est pas très facile, et de toute façon, il n’est utilisable que sous Mac, donc difficile en clientèle par exemple. La seconde solution, est d’utiliser OpenOffice ou LibreOffice, cependant, après quelques années d’expériences, je trouve que ce n’est pas très pratique sur le long terme, de plus, l’avenir des deux produits me semble incertain, le premier est devenu payant, le second, communautaire, ne me rassure pas quant à son avenir.

Les deux solutions restantes sont docbook et LaTeX. Le dernier, bien que connu pour être très bien, me parait coûteux en temps, principalement sur la personnalisation du rendu (PDF dans mon cas). Me reste donc docbook (si vous êtes anti XML, passé votre chemin). Pour ma part, il me semble absolument indispensable de différencier le contenu de son style (le rendu). Bien que beaucoup (mais ce n’est probablement pas votre cas, cher lecteur) pensent que <important>mon texte</important> soit équivalent à <gras>mon texte</gras>, ce n’est pas mon cas. Je peux pouvoir écrire un document (un contenu) à un instant t et le rendre en PDF mais surtout pouvoir modifier le style (couleur du titre, etc.) sans toucher le document d’origine, et ce plusieurs mois après la rédaction du fichier. C’est pourquoi je me suis tourné vers docbook.

Après quelques heures perdues, j’ai réussi à obtenir un squelette de production de mes documents, que je vais décrire dans le présent billet.

Les fichiers

Pour commencer, voici la liste des fichiers impliqués dans la production d’un document :

  • documentation.xml, c’est mon fichier source docbook, le contenu que je veux produire en pdf ;
  • default.xsl, ce fichier est une transformation XML (xsl) qui me permet de modifier le fichier docbook d’origine, pour par exemple rajouter automatique la partie sur l’auteur si elle n’est pas présente dans le document d’origine. Autant essayer de ne pas dupliquer l’information autant que faire se peut. ;
  • monstyle.xsl, c’est le fichier qui me permet de surcharger la transformation docbook vers FO (une étape intermédiaire avant transformation en PDF). C’est là que je vais définir les couleurs (ou tout paramètre disponible par la XSL de Walsh), ou bien encore surcharger un template précis ;
  • et finalement, un fichier Makefile qui me permet d’automatiser tout cela.

Le Makefile

Comme expliqué précédemment, ce fichier me permet d’automatiser la transformation d’un fichier docbook vers un fichier PDF. Et comme je galère un peu sur Makefile, je vais profiter de ce billet pour me faire un mémo.

DOCUMENTS=documentation.xml

FOP=/Users/bbonfils/tools/fop-1.0/fop
FOP_XSL=xsl/docbook.xsl
FOP_CONF=conf/fop.xconf
DEFAULT_XSL=xsl/default.xsl
XSLTPROC=xsltproc
XMLLINT=xmllint
TMP=tmp
ENV=LC_ALL=en_US.UTF-8
FOP_ENV=FOP_OPTS=-Djava.awt.headless=true

default: $(DOCUMENTS:.xml=.pdf)

%.pdf: %.xml
   $(ENV) $(XSLTPROC) $(DEFAULT_XSL) $? | $(XMLLINT) -format - > $(TMP)/$?
   $(ENV) $(FOP_ENV) $(FOP) -c $(FOP_CONF) -xml $(TMP)/$? -xsl $(FOP_XSL) -pdf $@

clean:
   @rm -f *.pdf

Les premières lignes définissent des variables, notamment DOCUMENTS qui me permet de lister les fichiers docbook à transformer en PDF. Ensuite, je défini la règle implicite suivante: :

%.pdf: %.xml
   $(ENV) $(XSLTPROC) $(DEFAULT_XSL) $? | $(XMLLINT) -format - > $(TMP)/$?
   $(ENV) $(FOP_ENV) $(FOP) -c $(FOP_CONF) -xml $(TMP)/$? -xsl $(FOP_XSL) -pdf $@

qui décrit la manière de compiler (transformer dans mon cas) un fichier XML vers un PDF. La première ligne permet d’appliquer ma XSL default.xsl qui permet de rajouter les informations de l’auteur si elles n’existent pas. La deuxième ligne applique la transformation docbook vers FO puis de FO vers PDF.

Et finalement, je définis la cible par défaut default en lui demande de me transformer la liste des fichiers renseignés par la variable DOCUMENTS en PDF, par substitution de l’extension.

Voilà, voilà, je dois avouer que ce billet est plus un memento personnel, mais tant qu’a faire, autant partager avec le monde. Pour les lecteurs avertis, vous aurez remarque que je traite que des fichiers textes qui sont donc parfaitement adaptés pour un gestionnaire de source tel que Subversion ou Git.

Categories: Business tools Tags:

Vidéos du séminaire #2

March 11th, 2011 No comments

Oups, je viens de me rendre rencontre que j’ai oublié de poster le lien des vidéos du deuxième séminaire sysadmin. Un grand merci à _nono_ pour son travail, ainsi que l’IRCAM pour nous avoir prété leur salle.

Categories: Social, Sysadmin Tags: