Quelles sont les bonnes questions à se poser pour décider d'utiliser Chef ou Puppet?

Je suis sur le point de démarrer un nouveau projet qui nécessitera, en partie, le déploiement de nombreux nœuds identiques d'environ trois classes différentes:

• Noeuds de données , qui exécuteront des instances fragmentées de MongoDB.
• Noeuds d'application , qui exécuteront des instances d'une application Ruby on Rails et d'une ancienne application ASP.NET MVC.
• Noeuds de traitement , qui exécuteront les travaux demandés par les noeuds d'application.

Tous les nœuds s'exécuteront sur des instances d'Ubuntu 10.04, bien que différents packages soient installés.

J'ai une certaine familiarité avec Chef des projets précédents, bien que je ne me considère pas comme un expert. Dans un effort pour faire preuve de diligence raisonnable, j'ai étudié des possibilités alternatives. Nous avons un certain nombre de personnes en interne qui sont des utilisateurs de marionnettes de longue date, et ils m'ont encouragé à y jeter un œil.

J'ai cependant du mal à évaluer les deux choix. Chef et Puppet partagent la même terminologie de domaine - packages , ressources , attributs , etc. - et ils ont une histoire commune qui découle de l'adoption d'approches différentes du même problème. Donc, dans un certain sens, ils sont très similaires. Mais une grande partie des informations de comparaison que j'ai trouvées, comme cet article , est un peu dépassée.

Si vous commenciez ce projet aujourd'hui, quelles questions vous poseriez-vous pour décider si vous devez utiliser Chef ou Puppet pour la gestion de la configuration? (Remarque: je ne veux pas de réponse à la question "Dois-je utiliser Chef ou Puppet?")

Puppet et Chef peuvent faire ce que vous voulez très bien. Votre meilleur va être de commencer à faire ce que vous essayez de faire et de décider quel outil vous préférez. Je pense que les grandes questions que vous devez vous poser sont:

Voulez-vous une DSL? - Les recettes du chef sont écrites en rubis, la marionnette a une DSL. Qu'une DSL soit bonne ou mauvaise est l'une des plus grandes différences entre le chef et la marionnette. Le lien que vous avez publié vers la comparaison de bitfield consulting contient de bons commentaires à ce sujet, que vous devriez lire si vous ne l'avez pas déjà fait. J'ai également trouvé cet article de blog utile, assurez-vous de lire également les commentaires.

Connaissez-vous le rubis? - Si vous ne connaissez pas le rubis, commencer avec le chef peut être plus difficile ou nécessiter un investissement de temps plus important car vous devez apprendre une nouvelle langue. Puppet a sa propre langue qui est facile à démarrer. À partir de la marionnette 2.6, les manifestes peuvent également être écrits en rubis .

À l'Open Source Bridge en 2009, ils avaient un panel d'auteurs et de représentants de chef, marionnette, bcfg2, cfengine et automateit que vous pouvez regarder sur bliptv qui a 1,75 heures de discussion sur les utilitaires de gestion de la configuration.

Opscode / Chef parle également de la différence entre celui-ci et la marionnette dans leur FAQ .

Je pense que si vous ne connaissez pas les bonnes questions à poser, cela peut venir du fait que vous n'avez pas trop d'expérience de travail avec l'un ou l'autre, une fois que vous commencerez à les utiliser, vous verrez les différences entre eux. Je suggère de venir avec des problèmes réels que vous résolverez avec un chef ou une marionnette, puis essayez de les résoudre et voyez ce que vous aimez / n'aimez pas à leur sujet. Avec Opscode / Chef, ils offrent une solution hébergée que vous pouvez configurer gratuitement 5 nœuds pour commencer.

Permettez-moi de dire d'abord - si vous n'utilisez pas Puppet ou Chef; Il n'y a pas de mauvaise réponse. Soit sera tellement mieux que ce que vous faites maintenant.

En tant que chef d'équipe, j'ai fait le choix de Puppet pour mon équipe. Si j'étais une équipe de moi-même, j'aurais plutôt choisi Chef. Voici pourquoi:

Bien que mon expertise soit certainement en administration de systèmes, mon expérience est en programmation. C'est pour cela que je suis allé à l'école, et je ne suis pas étranger à l'écriture d'applications complètes (pas seulement des scripts). Bien que je ne connaissais pas Ruby, je le voulais, et le chef aurait été une excellente excuse pour aller apprendre les deux.

Cependant, mon équipe est pleine d'administrateurs de systèmes avec peu ou pas d'expérience en programmation, à part le script shell occasionnel. Pour eux, écrire un module marionnette ressemble beaucoup à écrire un fichier de configuration. Il est déclaratif, il n'y a pas d'itérateurs et, dans l'ensemble, il est plus convivial pour les administrateurs.

Les équipes remplies de développeurs effectuant des activités d'administrateur système ont tendance à préférer Chef. Étant donné que le DSL de Puppet est déclaratif, l'ordre (même dans les fichiers individuels) n'a pas d'importance, et cela contrarie beaucoup de gens habitués à un langage de programmation plus typique.

J'ai également entendu dire à maintes reprises que Chef est beaucoup plus convivial pour le cloud que Puppet, mais Puppet a mis l'accent sur leur produit Puppet Enterprise au cours de l'année écoulée. Je ne peux pas parler d'expérience sur les capacités de cloud des deux produits.

En raison de ces qualités ci-dessus, le stéréotype (et c'est souvent correct) est que vous trouverez que Puppet est plus répandu dans l'entreprise sur les machines physiques, où Chef gouverne les startups dans le cloud. Il y a des exceptions bien sûr, mais ce que j'ai vu confirme certainement le stéréotype.

Si c'est une équipe d'une personne, évaluez les deux et choisissez celle que vous aimez. Cependant, si comme moi, vous avez une équipe de personnes, assurez-vous de garder la priorité sur les besoins de votre équipe par rapport à vos préférences personnelles, cela vous sauvera plus tard lorsque vous essaierez d'obtenir l'adhésion.

Divulgation complète, nous n'utilisons ni l'un ni l'autre, bien que nous les ayons évalués en interne tout en essayant de décider d'un système de gestion de configuration. Ne me considérez donc pas comme un expert sur quoi que ce soit après tout.

• Est-il facile d'obtenir une configuration d'instance?
• Quelle configuration est requise sur le client pour qu'il communique avec le serveur?

Etc. Mais vous pouvez répondre vous-même à ces questions très facilement: configurez-les! Obtenir un échantillon opérationnel représente quelques heures de votre temps pour chaque produit, et compte tenu du fait que tout ce que vous utilisez sera probablement utilisé pendant une longue période, le temps en vaut la peine. Non seulement vous pouvez avoir une idée de la façon dont ils gèrent les choses spécifiques à la plate-forme (c'est-à-dire basées sur Debian et apt, basées sur RPM et miam), mais cela vous aidera certainement à avoir une idée des applications.

Gardez également à l'esprit que toutes les fonctionnalités du monde ne compenseront pas une interface difficile, de plus, cela peut exposer des problèmes spécifiques à votre infrastructure - c'est-à-dire ce qui se passe si les fichiers de configuration sont mis à jour dans un ordre différent que prévu?

Voilà donc mon conseil; Chef et Puppet ne sont pas si difficiles à installer un serveur et un ou deux clients, et vous donneront une expérience de première main sur les deux. De plus, si vous commencez à le configurer et réalisez que c'est une énorme douleur, vous en aurez déjà les connaissances avant de vous y engager.

S'il y a des personnes sur votre projet qui ont déjà de l'expérience avec Puppet, alors je vous suggère d'utiliser simplement Puppet.

Chef et Puppet sont assez similaires, et les deux projets sont également de haute qualité. Si vous avez accès à des personnes qui ont déjà une expérience Puppet, utilisez simplement Puppet.

Ce qui précède est certainement une bonne ligne directrice, j'aime aussi poser ces questions générales chaque fois que j'envisage une nouvelle dépendance de tiers.

• Quel est l'âge du projet?
• Dans quelle mesure la communauté est-elle active (listes de diffusion, bugs, irc, etc.)?
• Une bonne documentation solide est-elle fournie avec les pratiques standard?

Ce sont de bons indicateurs de la réussite globale du projet et peuvent quelque peu prédire la durée de vie.

Essayez de trouver des gens qui utilisent Chef ou Marionnette depuis plus de deux mois et demandez-leur ce qu'ils ont vécu.

Pour moi, c'est étroitement lié à la tradition d'une communauté spécifique. Historiquement, Chef était plus proche des gars de RubyOnRails. Également un élément important de la popularité du chef dans la communauté ROR, car Engineyard a construit son infrastructure sur le chef.