55 votes

Puppet vs Chef, pour et contre selon les utilisateurs et les cas d'utilisation

J'ai déjà googlé et lu le "à la marionnette ou à la chèvre, c'est la question". article.

Je suis intéressé par les cas d'utilisation, les mises en œuvre dans le monde réel dans lesquelles les gens ont choisi l'un ou l'autre sur la base de problèmes réels.

Je suis particulièrement intéressé par intégration avec cobbler (je sais que Puppet est une approche standard dans ce sens) ; quelqu'un a-t-il une expérience dans le domaine de la gestion de l'information ? intégration cordonnier-chef ?

Merci d'avance

62voto

chiggsy Points 1576

Pour être honnête, je pense que cela se résume à un simple point de vue : Chef semble être une solution plus impérative et programmatique, l'utilisation de ruby comme langage me fait instantanément espérer que quelqu'un l'a porté en Python, comme c'est le cas avec toutes les idées de ruby.

Mais ce n'est pas ce que vous voulez pour ce genre de choses. Vous voulez parler du vide dans lequel le système sera et déclarer :

"Sur le port 80 appelle du nord le démon nommé nginx. Sa tâche est de servir."

"Un utilisateur doit exister, son nom doit être chiggsy et il doit être l'un des puissants du groupe de la roue,"

"Élevez un mur de feu, mince aux endroits 80,443,8080"

Et ainsi de suite, mais peut-être dans un langage moins fleuri.

Puppet supporte mieux ce paradigme. J'aurais utilisé l'un ou l'autre, je n'avais pas de préférence mais, en fin de compte, le déclaratif me convenait mieux.

Marionnette.

18voto

dan zen Points 543

J'ai écrit une comparaison détaillée de Chef et Puppet ici : Puppet vs Chef : 10 raisons pour lesquelles Puppet l'emporte . Bien qu'il ne comprenne pas de cas d'utilisation, j'espère qu'il fournira des points de départ utiles aux personnes qui se demandent quel outil choisir pour l'automatisation de leur infrastructure.

14voto

Joel K Points 5727

Désolé pour la verbosité. Utilisez l'outil qui vous permet de faire votre travail facilement. C'est le but de l'automatisation, non ?

Histoire : J'ai utilisé Puppet dans des concerts précédents et le mois dernier, j'ai passé environ une semaine à essayer de m'habituer à Chef pour voir si j'allais faire le changement dans mon nouveau concert.

Je n'ai pas sauté.

Jargon : Un problème malheureux avec ces deux systèmes est la surcharge de jargon. (recettes, modèles, nœuds, rôles, attributs, fournisseurs) C'est sans fin. J'ai trouvé que Chef allait un peu plus loin. (Couteau, Shef, etc.)

Maturité du code : Il suffit de dire que j'ai trouvé Chef juste un peu trop brut. Il ressemble beaucoup à ce que Puppet a ressenti dans la période .21/.22 il y a 3-4 ans. Il y a beaucoup de flux en cours.

Je ne dis pas que cela n'est pas arrivé avec Puppet non plus. (J'ai redécouvert de nombreuses fonctionnalités de Puppet qui n'ont fait surface que ces dernières années. -- correspondance de regex !)

Rubis : Je n'ai pas aimé toute la surcharge de ruby dans Chef. (vous avez besoin de gem et rake avant même de pouvoir commencer) Vous pouvez utiliser ruby pour résoudre des problèmes complexes dans Puppet à la facter, mais vous n'êtes pas obligé de le faire si vous ne le voulez pas.

La complexité : Je n'ai pas aimé l'accent mis sur l'interface graphique de Chef. Je sais que c'est joli et que Puppet a une interface web en préparation, mais je pense qu'elle devrait être plus découplée.

Chef a une architecture beaucoup plus complexe. Elle est peut-être plus évolutive, mais il y a beaucoup de points de défaillance potentiels.
http://wiki.opscode.com/display/chef/Architecture

Chef a besoin de couchdb, rabbitmq et solr en plus du serveur API et de l'interface web.

Je veux juste une interface client/serveur simple qui n'a pas besoin d'un cadre MVC par-dessus et d'un magasin de données complexe derrière elle.

Puppet est beaucoup plus simple dans ce domaine. (ce qui ne veut pas dire qu'il n'y a pas beaucoup d'ajouts pour le rendre plus compliqué).

Faire son travail : En fin de compte, j'ai fait ce que je savais. Après avoir passé une semaine à bidouiller et à peine être capable de faire l'essentiel avec Chef, j'ai pu revenir à Puppet et répondre à mes besoins de base en quelques heures. (gestion des paquets, gestion des utilisateurs, modèles de fichiers de configuration)

Avertissement sur les modules : Puppet a récemment évolué vers l'utilisation de "modules" qui sont fournis par des tiers. Je n'ai pas fini d'utiliser ces modules et j'ai trouvé une grande variété dans leur qualité. Assurez-vous de jeter un coup d'œil sous les couvertures et de voir ce qu'ils font et comment ils fonctionnent avant de vous lancer dans ces modules.

5voto

Riaan Points 411

Voici une opinion : Nous les avons tous essayés dans notre entreprise et nous préférons Puppet. Tout simplement parce qu'il est facile à utiliser.

1voto

sarath Points 11

J'ai moi-même vu des cas où la gestion de 1000 hôtes avec des configurations différentes, est beaucoup plus facile avec Puppet. En fait, des entreprises comme Google utilisent Puppet pour leur déploiement.

L'architecture principale de Puppet est telle qu'elle fonctionne beaucoup mieux que les autres si vous la configurez de la bonne manière. Par exemple, en ajoutant vos faits personnalisés pour vos configurations personnalisées, etc. Les liens ci-dessous peuvent fournir des informations http://slashroot.in/Puppet-tutorial-installing-Puppet-master-and-Puppet-agent

http://slashroot.in/Puppet-tutorial-how-does-Puppet-work

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X