Auteur:


Date:
20/03/2012

Catégories:
Developpement
Open-source
Planet-libre
Systeme

Tags:



En route vers Puppet, Chef, CfEngine…

  

Derrière ce titre un peu pompeux se cache une problématique que tout administrateur système s'est ou se posera un jour ou l'autre: Comment gérer l'installation, la mise à jour et la configuration de toutes les machines de son parc informatique ?

Ce billet a pour objectif de poser le problème de base et d'aborder quelques unes des solutions possibles. Il servira d'introduction à une série d'article sur ce vaste et intéressant sujet.

Introduction

Imaginons donc un responsable informatique disposant de trois administrateurs système: Michel, David et Jean-Pierre. Il leurs demande de travailler sur les solutions de déploiement des logiciels dans le système d'information de  l'entreprise. Quelques jours plus tard, il leur demande de présenter leurs solutions...

Première solution: "à la mimine"

La première solution pour répondre à la question posée est celle Michel, sysadmin de base (fort en technique mais moins en processus et en communication): lire la documentation du système (ou logiciel) à installer (ou mettre à jour), Googlelifier si la documentation est trop longue (ou seulement en Anglais), tester sur un environnement de développement (Jean-Pierre est quand même un garçon prudent) puis appliquer la dite procédure sur l'ensemble des machines.

On trouve également certains Michel (ceux qui ont passé la certification ISO) qui vont documenter leur installation dans un beau document (ou encore mieux un Wiki). Comme Michel travaille souvent seul, le document ne sera jamais partagé ou enrichie, il deviendra donc obsolète à la prochaine version du système (ou logiciel).

Cette première solution apporte quelques avantages: Michel peut maîtriser de manière unitaire toutes les installations et donc facilement identifier les problèmes, il a une connaissance précise et réelles des briques de ses machines.

D'un autre coté, Michel demande un certain temps pour déployer ou mettre à jour vos logiciels sur les 100 machines de votre parc et il deviendrait complètement débordé, voir incompétent,  si ce nombre passait à plusieurs centaines voir milliers de machines...

Deuxième solution: "script, script, script..."

Michel a un collègue, David, qui adopte une méthode similaire dans les premières étapes (lecture de la documentation, recherche sur Internet, test dans un environnement de développement). Mais qui, au lieu de faire lui même les opérations sur les machines, passe par un script Shell qui va automatiser ces taches. Si vous suivez ce blog, vous savez que j'utilise souvent cette méthode pour installer des composants sur mes machines persos (et quelques fois professionnelles).

David bichonne ses beaux scripts dans un repos Git. Ses procédures sont rodées: connexion en SSH, récupération du script et le exécution.

Tout semble parfait mais les développements de ces scripts peuvent vite devenir une vrai galère quand on s'attaque à un parc multi-distribution (ceux qui ont essayé de développer un script d'installation multi-plateforme/distribution doivent me comprendre...).

Troisième solution: "gestionnaire de configuration des machines"

Bienvenu dans le monde de Jean-Pierre. Lui, il utilise un gestionnaire de configuration des machines. Ces systèmes apportent une couche d'abstraction entre ceux que l'on veut faire (les besoins) et comment ces besoins sont concrètement résolus sur les machines cibles.Un pseudo langage de programmation permet de définir les actions à effectuer et le moteur de configuration des machines va s'occuper du déploiement, de l'exécution et de la génération d'un rapport sur chacune des machines cibles.

Plusieurs solutions existent, des propriétaires (comme IBM Tivoli, BSM ou HP Operations Manager i) et des libres (Puppet, Chef, CfEngine). C'est bien sûr sur ces dernières que Jean-Pierre, grand partisan des solutions libres, a donc porté son choix.

Il ne reste plus qu'à commencer à jouer avec le bébé en travaillant sur un environnement de développement/Cloud (teasing pour les prochains billets :)).

Conclusion

Je ne connais pas assez ces solutions pour avoir un avis tranché sur la meilleure solution libre. Après quelques recherches sur le net et la consultation des 3 sites internet officiels, je trouve que le projet Puppet est très bien structuré et documenté. Je pense donc partir sur cette solution pour mes prochains billet sur le sujet.

La discussion est cependant ouverte (et les commentaires sont fait pour cela).

Je suis preneur de retours d'expériences sur ces 3 solutions libres !

Sources ayant inspiré ce billet:

 

  • djojo

    Salut à toi,
    D’après mes souvenirs, Chef est le successeur (fork puis amélioration) des 2 autres produits que tu cite … Il s’apparenterait à la version 3 de la suite (qui est parti sensiblement du même point, mais en se forkant à 2 reprise pour arriver à Chef).

    My 2 cents

  • http://www.zenanny.com Cyril B

    Mes deux cents. J’ai eu la même problématique (parc de plus de 1000 serveurs sous CentOS) dans l’un de mes précédents emplois et j’avais choisi Puppet pour deux raisons :

    - Documentation claire et abondante, bonne communauté active derrière.
    - Simplicité d’installation et de maintenance.

    L’expérience a été vraiment concluante, on a vraiment pu déployer plein de templates différents suivant le type de serveurs en toute simplicité.

    J’avais délaissé Chef et CfEngine, peut être à tort, car je les trouvais plus orienté dev que sysadmin dans la logique de déploiement et d’administration.

    • http://twitter.com/nico_charles Nicolas Charles

      Je trouve que CFEngine est beaucoup plus orienté sysadmin que dev.
      La syntaxe force à changer son mode de pensée quand on est dev, pour passer de “je veux ca, puis ca, et après faire ceci” à “J’ai besoin de çà”

      C’est completement à l’opposé du scripting, complétement différent de tous les langages (Ruby est un langage de developpeur)

  • Edouard

    Nous utilisons maintenant Puppet depuis plusieurs années, et même certaines contributions (en rapport avec ldap). Et c’est le pied ;)
    Nous avons nos modules de configuration pour a peu près tout et n’importe quoi (conf réseaux, paquets rpm à installer, utilisateurs, montages, vpn etc). L’intérêt c’est que les architectes livrent des LDIF décrivant leur plateforme, et ce LDIF est appliqué aux différentes étapes de la vie du projet (dev, intégration, virtualisation, prod); nous en sommes plutot très satisfait même si les outils autour de ça manquent encore. Et pis bien sûr l’avantage énorme, c’est la diminution des risques d’erreurs humaines sur des déploiements de plateformes avec des configurations complexes, avec puppet nous sommes sûrs que la conf est identique partout.
    Puppet couplé à Cobbler et à Func, et ça couvre presque tous les besoins.

    Nous regardons maintenant pour intégrer rundeck, plus pour faciliter l’exploitation.

    Voilà un bref retour d’expérience sur Puppet. CfEngine n’avait pas été retenu à cause de sa syntaxe inbitable…bref +1 pour puppet

  • http://grummfy.be Grummfy

    Hello,
    avec puppet, tu un outils sympa (d’après les écho que j’en ai eu) : Foreman

  • http://www.choix-libres.org Gamoth

    J’ai intégré une entreprise qui utilise massivement Puppet pour gérer un parc de quelques milliers de machines sous Ubuntu. Je trouve la documentation assez bien fichue, elle manque peut être de détail sur certains points précis.
    Par contre, le gros point noir de cette solution est le pseudo-langage Puppet, basé sur Ruby qui lui même est interprété.
    Du coup, les timeout sont rapidement atteints lors de la demande de compilation du catalogue et des templates.
    Je noterai également qu’un passage de puppet n’est pas toujours suffisant pour remettre une configuration à jour. Nous sommes souvent obligés de nous y reprendre à 3 fois pour que tout passe.
    Ces problèmes sont peut être du à la version utilisée qui est la 0.25 ou aux nombres de machines.

    Bon courage.

    • Edouard

      Etonnant comme problèmes. Pour les timeouts vous passez par le moteur web intégré ou par le module apache (mod_passenger)? car nous aucun problème à ce niveau (plusieurs milliers de machines et beaucoup de templates). Nous utilisons aussi la version 0.25.

    • http://twitter.com/BinBashFR binbash.fr

      Bonjour,

      Comme vous le fait remarquer Edouard, si vous utilisez toujours le serveur web WEBRick (l’installation par défaut de Puppet), les problèmes de TO viennent certainement de là. Il est indispensable d’utiliser passenger pour gérer ce nombre de serveurs ;-) Voir de faire un partage de charge entre plusieurs serveurs Puppet.J’ai écrit une série d’articles sur cette problématique et ca commence ici : http://binbash.fr/2012/01/09/installer-un-serveur-puppet-scalable-partie-1/

      @nicolargo : pour avoir testé Chef, j’ai largement préféré la syntaxe de Puppet beaucoup plus simple à aborder pour un profil sysadmin. Clairement les deux softs se valent, il y a des + et des – pour chacun d’entre eux. J’avais par contre directement éliminé CFengine de mes tests… Il est à mon avis encore aujourd’hui dépassé par Puppet et Chef. C’est mon avis ;-)
      Bref, bons tests sur Puppet, c’est clairement le genre de soft qui change complètement la façon d’administrer des serveurs. C’est impactant pour nos métiers, ceux de nos collègues (on ne peut plus se permettre n’importe quoi sur un serveur “Puppétisé”) mais le retour arrière est impossible tellement c’est pratique !
      Au plaisir de lire tes futurs billets sur le sujet ;-)

      • http://www.choix-libres.org Gamoth

        Nous sommes passés sur du Puppet + Passenger Apache. Ce qui permet de mieux répartir la charge.
        Mais nous n’avons pas plusieurs serveurs puppetmaster. Il est possible que nous ayons atteint la limite d’un puppetmaster.

        • Edouard

          Je sais plus si c’est pas dans la doc officiel, mais genre avec puppetmasterd et donc webrick ça gère genre 15 à 20 clients. Nous avec apache, environ 800 clients ça passe, mais nous coupons le service puppet sur les clients, nous préférons déclencher volontairement (via func) le déploiement de configuration.

  • http://twitter.com/nico_charles Nicolas Charles

    Je vais donner un avis différent de la majorité.

    J’utilise CFEngine, pour plusieurs raisons :
    - ca s’installe partout (pas besoin de 50 dépendances, consommation mémoire et CPU très réduite). C’est très pragmatique, parce qu’on n’a pas toujours des grosses machines à gérer (et surtout, sur le cloud où on paye à la resource utilisée (bien que pour la partie cloud, Chef est très bien integré et marche très bien, du coup, ca peut valoir le coup de l’utiliser) )
    - c’est scalable : out of the box, il ne faut qu’un serveur pour gérer des milliers de machines, avec des remediations toutes les 5 minutes (et pas toutes les 30 minutes, ou une heure)
    - ca marche. Pas besoin d’outils comme MCollective, de tuer les demons puppet, de tuner le serveur, ou d’autres magies

    Alors, oui la syntaxe de CFEngine est (semble?) plus complexe, oui la doc n’est pas parfaite. Mais ca marche, et surtout ca marche bien.

    Il existe même une interface Web pour gérer la config des serveurs, avoir du reporting (Rudder : http://www.rudder-project.org )

  • Jonathan

    Intro très sympa sur le besoin d’un outil de gestion de configuration !

    Je te conseillerais de bien regarder CFEngine 3, même s’il peut paraitre moins “sexy” au premier abord. La version 3 est une refonte complète (par rapport a la version 2, qui avait inspirée la création de Puppet), récente et très vivante. Attention car les ressources sur le web parlent souvent des deux versions sans clairement distinguer…

    Quelques atouts de CFEngine a mes yeux : très léger (qq Mo de RAM) et efficace, installation très facile (presque pas de dépendances), scalable facilement, multi-plateforme (linux, bsd, unix, windows…), communauté active et sympa. Un bémol principal : la prise en main du langage est assez difficile (comme sur dans l’article, c’est une autre façon de penser).

    Disclaimer: je suis un des auteurs de Rudder (http://www.rudder-project.org), qui est basé sur CFEngine. Mon avis est donc base sur pas mal de recherches mais peut être aussi biaise :)

  • http://cfengine.com Geir

    Bonjour,

    Tout d’abord un disclaimer: je travaille pour CFEngine tant que Knowledge Engineer.

    C’est vrai que Chef et Puppet étaient les derniers à entrer sur le marché, mais CFEngine a été complètement re-écrit en 2008 (CFEngine 3) et compte aujourd’hui parmi les outils les plus modernes en config management. Hélas, beaucoup associent CFEngine toujours à la version 2, nous travaillons bien sûr pour changer ça.

    Parmi les points que je souhaite mettre en avant dans ce contexte, CFEngine est:
    - facile à installer: deux lignes de commande et peu de dépendances
    - facile à maintenir: pas besoin de réviser des nombreux paquets avant de mettre à jour
    - scalable: une machine pour gérer des milliers de serveurs
    - léger et agile: petite empreinte mémoire, temps d’exécution courte, s’exécute toutes les 5 minutes
    - orienté administrateurs de système: philosophie générale, pas besoin d’utiliser une autre langue de programmation pour développer des fonctions/solutions avancées

    Vu la tache qu’on essaie de résoudre, je pense que tous les outils demandent un certain effort pour apprendre leur langage. Celui de CFEngine a été développé pour être facile à comprendre et servir en même temps comme documentation des intentions de l’administrateur système et configurer le système même. J’aimerais bien voir une évaluation indépendante des différents langages, si vous en connaissez, faites-moi signe.

  • JaShuGan

    Bonjour,

    Nous avons mis en place Puppet sur notre environnement de production et de mon point de vue c’est magique :)
    Je ne vais pas répéter les avantages de telles solutions (ah si : homogénéité, réduction du taux d’erreur humaine, de la charge …).
    Depuis j’ai intégré une nouvelle mission (sans outil de gestion de configuration), je peux vous dire que j’ai l’impression d’être retourné à l’age de pierre loll.
    J’ai utilisé un temps Cfengine, je trouve la syntaxe puppet plus intuitive.
    Merci Nico

  • Gounick

    Bonjour Nicolargo,
    Y aura-t-il un billet dédié à Puppet ?

    • http://www.nicolargo.com nicolargo

      C’est prévu… manque juste un peu de temps devant moi… :(