Was sind die richtigen Fragen, wenn Sie sich für Chef oder Puppet entscheiden?


16

Ich bin im Begriff, ein neues Projekt zu starten, für das zum Teil viele identische Knoten mit ungefähr drei verschiedenen Klassen bereitgestellt werden müssen:

  • Datenknoten , die Instanzen von MongoDB sharded laufen.
  • Anwendungsknoten , auf denen Instanzen einer Ruby on Rails-Anwendung und einer älteren ASP.NET MVC-Anwendung ausgeführt werden.
  • Verarbeitungsknoten , auf denen von den Anwendungsknoten angeforderte Jobs ausgeführt werden.

Alle Knoten laufen auf Ubuntu 10.04-Instanzen, obwohl unterschiedliche Pakete installiert sind.

Ich kenne Chefkoch aus früheren Projekten, obwohl ich mich nicht als Experte betrachte. In dem Bestreben, Due Diligence zu betreiben, habe ich nach alternativen Möglichkeiten gesucht. Wir haben eine Reihe von Leuten im Haus, die schon lange Puppet benutzen, und sie haben mich ermutigt, einen Blick darauf zu werfen.

Es fällt mir jedoch schwer, beide Optionen zu bewerten. Chefkoch und Marionette teilen viele der gleichen Domain-Terminologie - Pakete , Ressourcen , Attribute usw., und sie haben eine gemeinsame Vorgeschichte, die sich aus unterschiedlichen Herangehensweisen an dasselbe Problem ergibt. In gewissem Sinne sind sie sich also sehr ähnlich. Aber viele der Vergleichsinformationen, die ich gefunden habe, wie dieser Artikel , sind etwas veraltet.

Wenn Sie dieses Projekt heute starten würden, welche Fragen würden Sie sich stellen, um zu entscheiden, ob Sie Chef oder Puppet für das Konfigurationsmanagement verwenden sollten? (Hinweis: Ich möchte keine Antwort auf die Frage "Soll ich Chefkoch oder Marionette verwenden?")


Update 2016: Es gibt eine massive Abwanderung von Chef und Puppet. Sie sind schlecht beraten für ein neues Projekt. Der Kampf ist gegen Salz jetzt ansible. (Ansible ist einfacher einzurichten und loszulegen + funktioniert über SSH, Salt ist einfacher, wenn die Infrastruktur groß und komplex wird + schneller)
user5994461

Antworten:


12

Sowohl Puppet als auch Chef können das tun, was Sie wollen. Am besten fängst du an, das zu tun, was du versuchst, und entscheidest, welches Tool dir am besten gefällt. Ich denke, die großen Fragen, die Sie stellen müssen, sind:

Möchtest du ein DSL? - Kochrezepte sind in Rubin geschrieben, Puppe hat DSL. Ob eine DSL eine gute oder eine schlechte Wahl ist, ist einer der größten Unterschiede zwischen Koch und Marionette. Der Link, den Sie zum Vergleich von bitfield consulting gepostet haben, enthält einige gute Kommentare dazu, die Sie lesen sollten, wenn Sie dies noch nicht getan haben. Ich fand diesen Blog-Beitrag auch nützlich. Lesen Sie auch die Kommentare.

Kennst du Rubin? - Wenn Sie Ruby nicht kennen, kann der Einstieg in den Koch schwieriger sein oder einen größeren Zeitaufwand erfordern, da Sie eine neue Sprache lernen müssen. Puppet hat eine eigene Sprache, mit der man leicht anfangen kann. Ab Puppet 2.6 können Manifeste auch in Ruby geschrieben werden.

Auf der Open Source Bridge im Jahr 2009 gab es eine Diskussionsrunde mit Autoren und Vertretern von Chefkoch, Marionette, bcfg2, cfengine und automateit, die Sie auf bliptv mit 1,75 Stunden Diskussion über Konfigurationsmanagement-Dienstprogramme sehen können.

Opscode / Chef spricht auch in ihren FAQ über den Unterschied zwischen it und puppet .

Ich denke, Sie wissen nicht, welche Fragen Sie stellen sollen, weil Sie nicht allzu viel Erfahrung in der Arbeit mit beiden haben. Sobald Sie sie verwenden, werden Sie die Unterschiede zwischen ihnen bemerken. Ich würde vorschlagen, mit einigen Problemen aus dem wirklichen Leben zu kommen, die Sie mit dem Koch oder der Marionette lösen werden, und dann zu versuchen, sie zu lösen und zu sehen, was Sie an ihnen mögen / nicht mögen. Mit Opscode / Chef bieten sie eine gehostete Lösung , mit der Sie kostenlos 5 Knoten einrichten können, um loszulegen.


3
Chefkoch hat auch ein DSL, der Unterschied ist, dass es sich um ein internes Ruby-DSL handelt, während das DSL von Puppet extern ist. Puppet hat seit kurzem auch ein reines Ruby-DSL hinzugefügt, aber es wird weder von Puppenbenutzern noch von Puppet Labs empfohlen oder empfohlen.
jtimberman

1
"willst du rubin wissen" ist wohl die frage nummer 1. Ich hoffe immer noch auf ein System, das auf Python basiert. :)
Sirex

Die verlinkten Blog-Artikel sind sehr hilfreich für Leute, die einen Vergleich zwischen Koch und Marionette anstellen möchten.
Clinton

6

Lassen Sie mich zuerst sagen - wenn Sie weder Puppet noch Chef verwenden; Es gibt keine falsche Antwort. Beide werden so viel besser sein als das, was Sie jetzt tun.

Als Teamleiter habe ich die Wahl für Puppet für mein Team getroffen. Wenn ich ein Team von nur mir selbst wäre, hätte ich stattdessen Chef gewählt. Hier ist der Grund:

Während ich mit Sicherheit Erfahrung in der Systemadministration habe, liegt mein Hintergrund in der Programmierung. Dafür bin ich zur Schule gegangen, und ich bin nicht fremd darin, vollständige Bewerbungen (nicht nur Skripte) zu schreiben. Obwohl ich Ruby nicht kannte, möchte ich und Chef wäre eine großartige Ausrede gewesen, um beides zu lernen.

Mein Team besteht jedoch aus Systemadministratoren, die abgesehen von gelegentlichen Shell-Skripten nur über wenig oder gar keine Programmiererfahrung verfügen. Für sie ist das Schreiben eines Puppenmoduls mit dem Schreiben einer Konfigurationsdatei vergleichbar. Es ist deklarativ, es gibt keine Iteratoren und insgesamt ist es admin-freundlicher.

Teams mit Entwicklern, die Sysadmin-Aktivitäten ausführen, bevorzugen in der Regel Chefkoch. Da Puppets DSL deklarativ ist, spielt die Reihenfolge (auch innerhalb einzelner Dateien) keine Rolle, und das frustriert viele, die an eine typischere Programmiersprache gewöhnt sind.

Ich habe auch schon oft gehört, dass Chef viel wolkenfreundlicher ist als Puppet, aber Puppet hat dies im vergangenen Jahr mit seinem Produkt Puppet Enterprise zum Schwerpunkt gemacht. Ich kann aus Erfahrung nicht über die Cloud-Fähigkeiten beider Produkte sprechen.

Aufgrund der oben genannten Eigenschaften ist das Klischee (und es ist oft richtig), dass Puppet auf physischen Computern, auf denen Chef die Start-ups in der Cloud regiert, im Unternehmen weit verbreiteter ist. Es gibt natürlich Ausnahmen, aber was ich gesehen habe, spricht zweifellos für das Stereotyp.

Wenn es sich um ein Ein-Personen-Team handelt, bewerten Sie beide und wählen Sie das aus, das Ihnen gefällt. Wenn Sie jedoch wie ich ein Team von Mitarbeitern haben, achten Sie darauf, dass die Bedürfnisse Ihres Teams Vorrang vor den persönlichen Vorlieben haben. Dies erspart Ihnen später, wenn Sie versuchen, sich anzumelden.


2
Justins Kommentar ist der beste Ansatz. Persönlich bevorzuge ich den Koch, da dies die erste CM-Option war, die ich gelernt habe, aber in der Praxis und unter Berücksichtigung der vorhandenen Teamstärke bei Marionetten tendiere ich dazu, Marionetten mit reinen Infrastrukturprojekten zu spielen, wohingegen das Anwendungsteam DevOps mehr auf den Koch ausgerichtet ist. Verwenden Sie das Beste und Praktischste für Ihre Anforderungen.

5

Vollständige Offenlegung, wir verwenden keine dieser beiden Methoden, obwohl wir sie intern ausgewertet haben, als wir versuchten, ein Konfigurationsmanagementsystem auszuwählen. Betrachten Sie mich also nicht als einen Experten für das, was auch immer.

  • Wie einfach ist es, eine Instanz einzurichten?
  • Welches Setup ist auf dem Client erforderlich, damit er mit dem Server kommuniziert?

Und so weiter. Aber Sie können diese Fragen ganz einfach selbst beantworten: Richten Sie sie ein! Die Inbetriebnahme einer Probe dauert für jedes Produkt ein paar Stunden, und wenn man bedenkt, dass das, wofür Sie es verwenden, wahrscheinlich lange Zeit verwendet wird, lohnt sich die Zeit auf jeden Fall. Sie können nicht nur ein Gefühl dafür bekommen, wie sie mit plattformspezifischen Dingen umgehen (dh Debian-basiert und apt, RPM-basiert und yum), sondern es wird Ihnen auch definitiv helfen, ein Gefühl für die Anwendungen zu bekommen.

Denken Sie auch daran, dass nicht alle Funktionen der Welt eine schwierige Benutzeroberfläche ausgleichen. Außerdem kann dies zu Problemen führen, die für Ihre Infrastruktur spezifisch sind, z. B. was passiert, wenn Konfigurationsdateien in einer anderen Reihenfolge aktualisiert werden als erwartet?

Das ist also mein Rat. Chefkoch und Puppet sind nicht allzu schwierig, einen Server und ein oder zwei Clients einzurichten, und bieten Ihnen Erfahrungen aus erster Hand. Wenn Sie anfangen, es einzurichten und feststellen, dass es sehr schmerzhaft ist, haben Sie bereits das Wissen, bevor Sie sich darauf festlegen.


5

Wenn es Leute in Ihrem Projekt gibt, die bereits Erfahrung mit Puppet haben, dann schlage ich vor, dass Sie einfach Puppet verwenden.

Chefkoch und Puppet sind sich ziemlich ähnlich, und beide Projekte sind von gleicher Qualität. Wenn Sie Zugang zu Personen haben, die bereits Erfahrung mit Puppet haben, verwenden Sie einfach Puppet.


2

Das oben Gesagte ist definitiv eine gute Richtlinie. Ich stelle diese allgemeinen Fragen auch gerne, wenn ich über eine neue Abhängigkeit von Dritten nachdenke.

  • Wie alt ist das Projekt?
  • Wie aktiv ist die Community (Mailinglisten, Bugs, IRC usw.)?
  • Ist eine gute und solide Dokumentation mit Standardpraktiken versehen?

Dies sind gute Indikatoren für den Gesamterfolg des Projekts und können die Lebensdauer etwas vorhersagen.


Alter ist entweder leicht oder schwer zu beurteilen: Chefkoch wurde von einer Firma gegründet, die Puppet verwendet hatte, aber mit bestimmten Dingen unzufrieden war. Es ist ein paar Jahre neuer, könnte aber als Gabel angesehen werden.
freiheit

0

Versuchen Sie, Leute zu finden, die seit mehr als ein paar Monaten entweder Chef oder Puppet verwenden, und fragen Sie sie nach ihren Erfahrungen.


0

Für mich ist es eng mit der Tradition einer bestimmten Gemeinschaft verbunden. In der Vergangenheit war Chefkoch den RubyOnRails-Leuten näher gekommen. Auch ein großes Stück der Beliebtheit von Chefs in der ROR-Community, da Engineyard seine Infrastruktur auf dem Chef aufgebaut hat.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.