Journal Jouer au ptit chef ou à la poupée ?

Posté par .
7
3
avr.
2012

Bonjour,
Avez vous l'expérience de ces outils "magiques" que sont Puppet et Chef ?

Nous sommes en train de mettre sur pied une infra-structure pour une société de sevices (non ce n'est pas une faute de frappe) et nous allons devoir gérer beaucoup de VM majoritairement sous RedHat / Centos.
Comme nous sommes des feignants de catégorie AAA++ nous étudions ce que doit contenir la VM de base et comment gérer les mises à jour, les configurations les déploiements rapide, etc.

Et là 3 outils : puppet / chef / cfengine

  • cfengine pas encore étudié
  • puppet simple et efficace
  • Chef m'a l'air puissant et bien pensé

mais je ne les ai encore jamais utilisé sauf pour les tutos "hello_world_esque" ;
je me suis fais ma petite idée, mais j'aimerais avoir la vôtre ou un retour d'expérience

Moulument votre

  • # Forum ?

    Posté par . Évalué à 10.

    Ca serait plutot sa place

  • # Fan de puppet

    Posté par (page perso) . Évalué à 10.

    Perso, j'ai migré de cfengine 2 à puppet, et je suis fan de puppet. On l'utilise au taf sur 1700 serveurs, je l'utilise sur mes 6 serveurs, et sur les serveurs de Mageia ( d'ailleurs, le dépot est publique : http://svnweb.mageia.org/adm/ , si tu veux voir une archi plus complète qu'un hello world ). De ce que j'ai vu au FOSDEM, c'est utilisé par Debian, par Fedora, par Wikimedia, entre autres références plus prestigieuses.

    Mais comme je pense que plein de gens vont te dire du bien de Puppet, je vais vite me focaliser par honnêteté sur les soucis.

    Le plus gros souci de puppet, c'est que la configuration simple ne va pas tenir la charge ( genre, sqlite + serveur par défaut webrick ), mais ça se déploie vite.
    Donc tu va très vite devoir te pencher sur les soucis de scalability, mais c'est amplement couvert sur le web ( hélas pas de façon très intégré à la distribution, mais y a du travail avec ça en cours )

    Autre souci, c'est du ruby, donc une consommation mémoire supérieur à celle de cfengine, et pas aussi rapide à converger ( mais ceci dit, je n'ai pas vraiment vu de problème avec ça au vue des machines que j'ai , mais si le but est d'avoir des milliers de mini vm, ça peut être bloquant ).

    Enfin, il faut bien voir que puppet est un langage de description, pas de programmation. Ce qui peut faire grincer des dents si tu ne le prends pas comme tel, les choix qui ont été fait sont très opiniatre, et pareil, tout le monde n'aime pas.

    À contrario, chef a l'air plus difficile à déployer, mais permet plus de choses. Il utilise directement ruby pour décrire les systèmes ( ce que puppet peut faire aussi, mais c'est pas très employé de ce que je sais ). Chef est plus apte à servir de brique de base pour faire un outil de gestion d'infrastructure ( genre, une interface personnalisé ). Il y a un article très bien dans Linux Mag sur le sujet, je t'invite à regarder.

    Et pour finir, si tu as du RH/Centos, l'outil Cloudforms que Red hat va sortir devrait s'appuyer sur puppet, ce qui garanti que le support de puppet ne devrait pas être trop mauvais ( alors qu'il y a pas de paquet rpm de chef pour le moment en dehors de celui d'opscode, ce qui me fait sauter au plafond en tant que contributeur à une distribution ).

  • # Saltstack ou Cuisine ?

    Posté par (page perso) . Évalué à 4.

    Il y a aussi http://saltstack.org/ et https://github.com/sebastien/cuisine

    Je te recommanderais plutôt Saltstack, qui est plus riche, j'ai une connaissance qui l'utilise, il en est très content.

    Le gros interêt, c'est qu'ils sont en Python, qui possède plus de librairies orienté système que Ruby.

  • # Cloudify

    Posté par . Évalué à 1.

    Y'avait une présentation de Cloudify chez Octo Tech lundi. C'était très intéressant.

  • # Pertinance ?

    Posté par (page perso) . Évalué à 2.

    Au boulot l'admin gère ~ 35 serveurs, dont une dizaine sous windows…
    Je découvre un peu les outils de gestion comme puppet ou chef et je me pose la question de la pertinence dans notre infra.

    Les serveurs sont géré au cas par cas, à la main ce qui amène une infra très hétérogène et peu maintenable et scriptable.

    J'ai l'impression que ces outils sont particulièrement intéressant avec 100+ serveurs, mais que avec si peu c'est assez capillotracté…

    Qu'en pensez vous?

    Après il faut arriver à changer les manières de fonctionner et ça non plus c'est pas gagner…

    • [^] # Re: Pertinance ?

      Posté par . Évalué à 5.

      Moi, j'ai commencé petit, et même avec peu de serveurs, c'est quand même agréable quand tu te dis par exemple "Tiens, j'aurais besoin de htop sur tous les serveurs".
      Tu configure puppet pour, et tu es sur que tous tes serveurs ont htop, même ceux que tu n'as pas encore installés !

      C'est pareil pour tout ce qu'on oublie tout le temps quand on fait une installation manuelle (ntp, syslog, resolv.conf, relais smtp, snmp…).

      Dans le genre de config hétérogène que tu as, il y a un point qui est dommage et c'est pareil de mon coté : Windows…
      Le jour où on pourra faire, même un minimum de truc, ça sera super.
      Mes collègues Microsoftiens ont beau dire qu'ils peuvent faire ce qu'il veulent avec l'AD et les GPO, n'empêche qu'ils ne font pas grand chose dans les faits…

    • [^] # Re: Pertinance ?

      Posté par (page perso) . Évalué à 3.

      Au cas par cas, tu veux dire que les serveurs ont pas tous besoin d'être mis à jour ou d'avoir ntp, ssh et les mêmes clés ssh ? Qu'il y a pas le même besoin de mettre un motd, qu'ils ont des systémes de monitoring différents et totalement non factorisable ?

      parce que sinon, tu peux déployer un outil pour gerer les points communs, et tant pis pour le reste.

      Comme dit plus haut, je m'en sert sur une infra de moins de 10 machines, et le simple fait de passer par puppet et svn permet à tout le monde de suivre les modifs, et de réagir si un truc est cassé ( genre, revert, genre, regarder le diff ).

      • [^] # Re: Pertinance ?

        Posté par (page perso) . Évalué à 2.

        le parc est hétérogène surtout à cause de la manière d'administrer…
        déjà il n'y a pas de clé ssh :p … ensuite les mises à jour c'est "bon celui là je dois le mettre à jour ça fait longtemps" ou "celui là, pas de mise à jours, ça fais trop longtemps et il tourne bien comme ça" ( oui oui je sais ça fait peur…)

        Au niveau des os c'est genre souvent debian mais parfois on avais besoin de redhat, et là y'avais un truc en testing,…ah ici c'est des backports… enfin je crois que vous voyez +- le truc…

        Un peu d’homogénéisation ne ferais pas de mal :)
        je cherche des arguments pour convaincre le sys admin :)

        • [^] # Re: Pertinance ?

          Posté par (page perso) . Évalué à 4.

          "c'est une compétence qui s'arrache sur le marché, donc ça permet de te recaser plus facilement"

        • [^] # Re: Pertinance ?

          Posté par (page perso) . Évalué à 2. Dernière modification le 04/04/12 à 23:42.

          Même si tu n'as pas deux machines avec la moindre configuration en commun (j'ai comme un doute), décrire la configuration de chacun de manière centralisée permet de s'y retrouver beaucoup plus facilement. Il est aussi plus facile de backuper le repo central qui contient la configuration que de faire ça au cas par cas sur chaque serveur (tu archives tout /etc ? comment tu fais la différence entre les fichiers fournis par la distro et ceux que tu as modifiés ?).

          Je pense que le choix de l'outil de gestion de configuration importe moins que le fait d'en avoir un. Perso je me suis mis a Puppet et ça me rappelle mes débuts avec CVS : il y a plein de limitations absurdes mais c'est largement mieux que de ne rien avoir.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Puppet ou Chef

    Posté par . Évalué à 7.

    C'est bizarre cette propension à utiliser ruby dans ce genre d'outils…

    Ayant très rapidement essayé Chef mais lu des docs, vu des présentations, je dirais qu'on a deux approches :
    1. puppet : orienté sysadmin, on décrit ce qu'on veut, et ça le fait
    2. chef : orienté développeur, on dit ce qu'il faut faire

    Chef est procédural, on sait dans quel ordre vont se faire les choses.
    Puppet, il y a une résolution d'un arbre de décision, en fonction des dépendances, on peut savoir dans quel ordre se feront les choses, seulement si on a explicité des dépendances.

    Voilà, en fonction des ses goûts ou affinité, le choix peut se faire sur ces critères.

  • # Merci beaucoup !

    Posté par . Évalué à 2.

    Merci pour vos précisions et votre aide,

    cela conforte mon idée qu'il faut peut être prévoir … les 2
    tant que l'on ne s'est pas fait une idée précise.

    Je pense même que dans certain cas il faut savoir jongler avec les deux, un peu comme
    certain scripts en shell deviennent trop complexe et nécessite de passer dans un langage de scripts comme python ou ruby.

    Je jetterais un oeil sur les variantes en python, ruby est sympa mais je préfère python.

    par contre je suis convaincu que même pour peu de serveur ce genre d'outils peut être pratique.

    Le but est de d'automatiser les choses … automatisables et surtout de ne rien oublier

    Je vois plein d'utilité a ce genre d'outils capables d'interagir avec plein de serveur
    dans l'installation c'est sur …
    Mais dans la maintenance quotidienne … l'essentiel de notre job repose sur un ERP très très vorace en tout … CPU, RAM, disque, avec des GROS fichiers en Go plein de petits fichiers en ko bref que du bonheur :)
    cela permet d'automatiser le déploiements de nos scripts spécifiques pour faire le ménage, calculer les stats BDD, faire les sauvegardes etc …

    Encore merci pour vos remarques pertinentes

    A bientot

  • # recettes puppet avec du code ruby

    Posté par . Évalué à 2.

    À noter que dans Puppet il est maintenant possible comme dans Chef d'utiliser directement du ruby pour décrire ses recettes (depuis la version 2.6).

    Voici la documentation de la chose :

    http://projects.puppetlabs.com/projects/1/wiki/Ruby_Dsl

  • # Cfengine, et pourquoi pas Spacewalk

    Posté par (page perso) . Évalué à 5.

    Pas testé Chef.

    À l'époque où j'avais testé Puppet sur CentOS 5, il tirait des dizaines de dépendances, là où un seul paquet suffisait pour Cfengine.

    J'ai aussi eu l'impression, avec quelques tests rapides, que Puppet devenait vite bien plus gourmand en mémoire que Cfengine.

    Du coup, j'ai finalement choisi Cfengine, et pour le moment, je ne le regrette pas.

    Après, pour ton besoin, peut-être pourrait-il être intéressant de jeter un coup d’œil du côté de Spacewalk, la version libre de Red-Hat Network Satellite. Je suis d'ailleurs preneur de tout retour d'expérience sur cet outil : quand j'avais voulu m'y intéresser, j'avais abandonner faute de doc. Mais l'outil semble avoir pas mal évolué depuis !

    • [^] # Re: Cfengine, et pourquoi pas Spacewalk

      Posté par (page perso) . Évalué à 1.

      Chef à aussi un ensemble de dépendances plus important que cfengine (il est basé ruby) et à une tendance à leaker de la mémoire.

      En contre partie et aux dires du stagiaire en école d'ingé qui à fait l'analyse comparative des trois solutions, obtenir ne serait-ce que ce que permet chef ou puppet "nu" avec un cfengine lui a pris plus de temps que de tester les deux autres solutions cumulées (je n'exclue pas qu'il se soit fourvoyé ;) mais son rapport sur le sujet semblait correct).

      • [^] # Re: Cfengine, et pourquoi pas Spacewalk

        Posté par . Évalué à 3.

        En contre partie et aux dires du stagiaire en école d'ingé qui à fait l'analyse comparative des trois solutions, obtenir ne serait-ce que ce que permet chef ou puppet "nu" avec un cfengine lui a pris plus de temps que de tester les deux autres solutions cumulées (je n'exclue pas qu'il se soit fourvoyé ;) mais son rapport sur le sujet semblait correct).

        Le temps de découverte et de mise en place ne me paraît pas important dans ce genre de cas. Ce qui compte à mon avis, c'est la puissance dans l'administration et l'exploitation.

        C'est comme dire que Notepad est mieux que Vi car il suffit de dix minutes pour le maîtriser :-)

        Pour ma part, je ne connais pas Chef mais je préfère Cfengine à Puppet pour ces raisons :

        • moins lourd ;
        • un seul paquet (contre plein de dépendances, surtout que bien souvent Ruby n'est installé que pour Puppet) ;
        • je trouve le langage de configuration de Cfengine plus simple (celle de Puppet est en Ruby, ça ne me paraît pas l'idéal pour de la configuration) ;
        • il me semble que Cfengine permet aussi de faire du procédural, ça correspond plus à ma logique.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Cfengine, et pourquoi pas Spacewalk

      Posté par . Évalué à 0.

      À l'époque où j'avais testé Puppet sur CentOS 5, il tirait des dizaines de dépendances, là où un seul paquet suffisait pour Cfengine.

      J'ai aussi choisi CFEngine pour cette raison, et quelques autres liées :
      - Consommation de ressources (RAM surtout mais aussi CPU) très bas par rapport à Puppet et Chef (CFEngine est écrit en C, très efficace)
      - Rapidité d'application des configurations (par défaut CFEngine tourne toutes les 5 minutes et est facile à scaler même à cette fréquence, Puppet/Chef c'est toutes les 30 minutes, et difficile à scaler même à cette fréquence ;) - voir https://t.co/kBQqRKzP)
      - Historique de sécurité - je sais pas pour Chef, mais chez Puppet il pleut les CVE ces temps ci (cf http://puppetlabs.com/security/), CFEngine n'a eu que 4 failles de sécurité en 19 ans (dont aucune considérée exploitable)
      - Ca peut paraître un détail, mais Chef et Puppet ne savent pas éditer le contenu de fichiers textes, seulement copier des templates en remplacant des variables dedans. CFEngine lui a plein d'approches pour éditer finement des fichiers (ajouter des lignes, remplacer des patterns, trouver des sections style .ini [section] etc).

      Petit disclaimer : je travaille sur le projet Rudder (un outil pour aider à propager l'utilisation de la gestion de configuration dans une boite en le rendant plus simple grace à une interface web, des configs toutes faites, du reporting automatique…) qui se base sur CFEngine, donc j'ai maintenant un parti pris, même si j'en avais pas à l'époque où j'ai fait ce choix (2009)

  • # Puppet/puppetmaster

    Posté par (page perso) . Évalué à 3.

    Nous utilisons Puppet au boulot (environ 600 serveur ainsi que toutes les workstations) et je peux te dire que c'est génial. Si tu veux voir quelques exemple (nous faisons plein de modules publiques, c'est ça le libre) je te laisse allez sur http://github.com/camptocamp notre module apt est particulièrement apprécié. Nous avons aussi des modules apache, postfix, ssh, nagios, bref un peut tout ce que tu peux trouver sur un serveur, c'est un bon début si tu veux te faire une petit idée. Par contre je te conseil de bien lire la doc de puppet en long et en large, mais en même temps elle est très bien faite.

    Pour ce qui est des autres solutions, j'ai touché un peut à chef par curiosité, et une fois que tu as fais du puppet (en même temps tu peux aussi faire du puppet comme un porc…) et bien c'est vraiment imbuvable.
    Pour ce qui est de cfengine, un collègue qui l'a un peut touché m'a dit que c'est vraiment à des années lumières de puppet, après c'est subjectif (et on est pas vendredi).

    En tout cas pour ce qui est des déploiements rapides, je monte une VE (on utilise openvz) en 20 minutes clefs en main et entièrement configurée. Donc avec une bonne infra bien pensée et puppet, c'est le rêve de l'admin sys paresseux !

    Librement

    Si tu ne sais pas demande, si tu sais partage !

  • # Comme promis je vous donne mes premières impressions

    Posté par . Évalué à 1.

    Bonjour la foule !

    nous sommes mon collègue et moi en train de monter notre nouvelle archi
    (VMWARE + REDHAT en grosse majorité)

    J'ai testé puppet et … cela ne me convient pas franchement
    voici mon avis qui n'engage que moi :

    • puppet / puppet entreprise la distinction est trop ténu et parfois on a du mal à faire la différence. par contre l'un n'est pas libre l'autre l'est
    • l'install de puppet entreprise est simple (download ;./puppet-entreprise-installer) mais cela viens avec plein de truc web que l'on a du mal a appréhender au début (à quoi ca sert ?)
    • celle de puppet libre est simple, une fois que l'on a trouvé la bonne page web et que l'on veut juste se faire la main et que l'on a pas besoin de tout l'attirail. restez simple svp …

    Pour conclure je vais certainement me tourner vers … Fabric et pssh car cela correspond mieux a ce que j'attends.
    Car en fait puppet est surtout fait pour gérer des parcs importants de machines identiques, a mon avis il est fait pour cela.
    Notre rôle d'admin sera plutôt de gérer une multitude de cas spécifique issue d'une base
    commune.
    En gros on génère une machine virtuelle puis elle doit évoluer dans le sens qu'elle veut
    (nous ne faisons de maj que si on est obligé …)

    Sinon un conseil : puppet libre ou puppet entreprise semble prendre des chemins différents la distinction entre les deux est encore flou pour l'instant et certains modules nécessite d'être paluché pour être utilisable de partout.
    Donc mieux vaut en choisir un et s'y tenir
    J'ai commencé par puppet entreprise par flemme … puis vu que j'étais limité a 10 noeuds, j'ai viré vers puppet libre et certainement me suis emmèlé les pinceaux.
    La doc et les tutos que j'ai trouvé partait quasi inévitablement vers puppet-entreprise

    Bref je n'ai pas encore besoin de puppet et verrais plus tard donc …

    Merci à tous pour vos remarques et votre aide

    A+
    chris

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.