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 CHP . Évalué à 10.
Ca serait plutot sa place
# Fan de puppet
Posté par Misc (site web personnel) . É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 Ludo . É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 Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Y'avait une présentation de Cloudify chez Octo Tech lundi. C'était très intéressant.
[^] # Re: Cloudify
Posté par Misc (site web personnel) . Évalué à 2.
J'arrive pas à trouver le code, c'est écrit en quoi ?
[^] # Re: Cloudify
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Y'a du java et du groovy.
Regarde le présentation et le bootstrapping
# Pertinance ?
Posté par eMerzh (site web personnel) . É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 Gilles Mocellin . É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
htopsur 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 Misc (site web personnel) . É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 eMerzh (site web personnel) . É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 Misc (site web personnel) . É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 Krunch (site web personnel) . Évalué à 2. Dernière modification le 04 avril 2012 à 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 Gilles Mocellin . É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 fait2.
chef: orienté développeur, on dit ce qu'il faut faireChef 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 Christophe B. (site web personnel) . É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 Dreammm . É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 Xavier Teyssier (site web personnel) . É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 -=[ silmaril ]=- (site web personnel) . É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 zebra3 . Évalué à 3.
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 :
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 Jonathan Clarke . Évalué à 0.
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 napster2core . É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 Christophe B. (site web personnel) . É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 :
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.