Tipp: Finden Sie Anwendungsfehler und Leistungsprobleme sofort mit Stackify Retrace

Die Fehlersuche und Optimierung Ihres Codes ist mit integrierten Fehlern, Protokollen und Leistungseinblicken auf Code-Ebene einfach.

Ähnlichkeiten

Chef und Puppet haben Ähnlichkeiten in der Art und Weise, wie sie Konfigurationen in Servern verwalten. Auch wenn beide Tools intern unterschiedlich arbeiten, ist das Ergebnis das gleiche. Mit beiden Werkzeugen können Sie den gewünschten Zustand durch Code definieren. Beide Tools arbeiten mit einer Master-Knoten-Architektur, bei der der Master für die Speicherung aller Daten zuständig ist und die Knoten dafür sorgen, dass die Server immer über die gewünschte Konfiguration verfügen.

Eines der Hauptziele bei der Verwendung von Chef oder Puppet für das Konfigurationsmanagement ist beispielsweise, dass Sie den gewünschten Zustand einer Gruppe von Servern als Code definieren können. Es sollte keine Rolle spielen, ob Sie dieselbe Konfiguration auf Server anwenden wollen, denn Chef und Puppet sorgen dafür, dass jede Änderung auf unabhängige Weise umgesetzt wird. Auf dieselbe Weise drücken wir alle mehrmals Strg + S, um sicherzustellen, dass wir die Änderungen speichern. Wenn jedoch jemand manuell in den Server eingreift und den gewünschten Zustand des Servers ändert, bringen diese Tools die Server auf den neuesten Stand, indem sie sie neu konfigurieren.

Aus Sicht der Architektur sehen Chef und Puppet ziemlich ähnlich aus, da sie beide eine Master-Agent-Architektur verwenden. Ein Masterknoten ist der Ort, an dem alle Serverkonfigurationen gespeichert werden. Die Master-Knoten für beide Tools sind hochverfügbar (HA), allerdings mit leichten Unterschieden – dazu später mehr. Für jeden Server, den Sie verwalten möchten, ist ein Agent installiert, der die Konfiguration in regelmäßigen Abständen automatisch abruft. Die Agenten überprüfen immer, ob der gewünschte Zustand eingehalten wird, nicht umgekehrt. Beide Tools können Linux- und Windows-Server verwalten.

Schließlich gibt es von beiden Tools eine Open-Source-Version und eine kostenpflichtige Version mit mehr Funktionen wie einer besseren HA-Konfiguration.

Unterschiede

Ich sagte bereits, dass die Architektur von Chef und Puppet ähnlich ist, aber sie unterscheiden sich leicht darin, wie sie HA handhaben. Bei Puppet repliziert der Master seine Daten auf einen anderen Server, und sie arbeiten auf eine aktive/passive Weise. Bei Chef wird HA mit drei Servern in einem aktiv/aktiven Modus mit einem API-Frontend gehandhabt, das horizontal skaliert werden kann.

Ein wesentlicher Unterschied zwischen Chef und Puppet besteht darin, wie sie die gewünschte Statuskonfiguration für Server definieren. Jedes Tool hat seine eigene domänenspezifische Sprache (DSL). Chef verwendet Ruby als DSL. Sie haben mehr Freiheiten bei der Erstellung komplexer Konfigurationen, da Sie eine Programmiersprache verwenden. Chef nennt diese gewünschten Zustandskonfigurationen, die Sie schreiben, Rezepte. Alles, was Sie mit Ruby tun können, können Sie auch in Chef tun, um Rezepte wie if-Bedingungen oder den Aufruf anderer Bibliotheken zu erstellen. Dies hat den Vorteil, dass Entwickler sich beim Schreiben von Chef-Rezepten wohler fühlen. Außerdem fühlen sich Entwickler nicht nur auf eine DSL beschränkt, wenn sie eine Konfiguration definieren.

Andererseits hat Puppet seine eigene DSL, „die so konzipiert wurde, dass sie für Sysadmins zugänglich ist.“ Und wenn Sie Erfahrung mit Nagios-Konfigurationsdateien haben, wird das Schreiben von Manifesten (die Version von Chef-Rezepten) kein Problem sein. Sie haben hier nicht allzu viele Freiheiten, aber das ist auch gut so, wenn man eine universelle Sprache haben will. Sie müssen also keinen Entwicklerhintergrund haben, um Puppet zu verwenden und zu lernen.

Schließlich unterscheiden sich diese Tools darin, wie Sie Rezepte oder Manifeste entwickeln und testen. Chef hat eine Workstation mit dem Chef SDK, die Sie auf Ihrem lokalen Computer als Testumgebung installieren können. Sie können die Rezepte lokal testen und sie dann auf den Masterknoten hochladen. Puppet verfügt nicht über eine Workstation, aber über ein SDK, mit dem Sie Manifeste während der Entwicklung testen können. Außerdem können Sie Manifeste lokal mit dem Befehl puppet apply anwenden.

Beispiele

Schauen wir uns ein Codebeispiel an, um sicherzustellen, dass der Stackify-Agent installiert ist.

Ein Rezept in Chef sieht wie folgt aus (reines Ruby):

# ...# bunch of variables declared# ...# download and extract stackify agenttar_extract node do target_dir Chef::Config creates "#{Chef::Config}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}" not_if { File.exist?(stackify_agent_jar_location) }endtemplate_file = "#{Chef::Config}/#{stackify_agent_install_relative_path}/stackify-agent.conf"template template_file do source "stackify-agent.conf.erb"end# run stackify agent install scriptbash 'agent_install' do user 'root' cwd "#{Chef::Config}/#{stackify_agent_install_relative_path}" code <<-EOH ./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options} rm -rf #{Chef::Config}/Linux rm -rf #{Chef::Config}/#{stackify_agent_install_relative_path} EOH not_if { File.exist?(stackify_agent_jar_location) }end

Für Puppet gibt es ein Modul, um den Stackify-Agenten zu installieren, und das Manifest sieht wie folgt aus:

 class { 'stackify': package_ensure => 'present', package_install_options_environment => 'development', package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', file_download_directory => 'C:\Temp', service_manage => true, service_ensure => true, service_enable => true, }

Wie Sie sehen, bestätigen die obigen Code-Beispiele, was ich zuvor gesagt habe. In Chef haben Sie mehr Freiheiten. Aber in Puppet kann der Code einfacher aussehen, wenn es ein Modul gibt, das man verwenden kann.

Premium Features

Lassen Sie uns den Vergleich machen, einschließlich der Premium Features, die andere Dinge als das Konfigurationsmanagement beinhalten.

Für Puppet gibt es Puppet Enterprise, das die folgenden Funktionen umfasst:

• Berichte, die bei der Einhaltung von Richtlinien helfen
• Orchestrierung von Anwendungs- und Infrastrukturimplementierungen
• Automatisierte Infrastrukturbereitstellung mit Infrastructure as Code
• Code-Verwaltung, um Infrastrukturänderungen automatisch zu fördern
• Knotenverwaltung für granulare Kontrolle von Servern
• Rollen-.basierte Zugriffskontrollrichtlinien für Benutzer
• Support per E-Mail oder Telefon

Sie haben auch Puppet Remediate, das ist ein Tool für das Schwachstellenmanagement Ihrer Server. Sie erhalten einen besseren Einblick in die Schwachstellen auf Ihren Servern und können Patches in großem Umfang auf alle Server anwenden.

Die kostenpflichtige Version von Chef bietet neben dem Konfigurationsmanagement die folgenden Funktionen:

• Compliance- und Sicherheitsmanagement
• Erstellen von CI/CD-Pipelines und Verwalten von Releases für alle Anwendungen
• Übersicht mit Dashboards für den gesamten Infrastruktur-Stack

Weitere Details finden Sie auf den Websites der einzelnen Anbieter, die über gute Ressourcen verfügen, um Ihnen den Einstieg zu erleichtern.

Wie man sich entscheidet

Wie man sich zwischen Chef und Puppet entscheidet, ist eine schwierige Frage, und die Antwort lautet wie immer … „Es kommt darauf an.“

Für welches Tool man sich auch entscheidet, es sollte eine Entscheidung des Teams sein, vor allem von denjenigen, die letztendlich mit dem Tool arbeiten werden. Ein guter Ansatz könnte darin bestehen, den Hintergrund des Teams zu berücksichtigen. Leute mit einem Sysadmin-Hintergrund finden es vielleicht besser, Puppet zu verwenden. Auch wenn sie die DSL lernen müssen, wird es nie so sein wie das Erlernen einer Programmiersprache. Wenn sie jedoch einen Hintergrund in der Entwicklung haben, könnte Chef besser geeignet sein (auch wenn sie Ruby nicht kennen).

Aber Sie sollten auch die Premium-Funktionen der einzelnen Tools berücksichtigen. Welche dieser Funktionen wird Ihrem Unternehmen helfen, Silos und Verschwendung zu reduzieren? Auch hier hängt alles von Ihren Bedürfnissen ab. Ich habe die Erfahrung gemacht, dass beide Anbieter immer versuchen, bei den Funktionen mit den anderen gleichzuziehen. Bei Puppet können Sie beispielsweise benutzerdefinierte Funktionen mit Ruby erstellen.

Ein weiterer wichtiger Aspekt ist natürlich die Preisgestaltung. Die Preise möchte ich hier nicht nennen, weil sie sehr stark schwanken und je nach Kundenbedürfnis variieren. Ein weiterer Grund ist, dass im Fall von Puppet die Preisseite keine öffentliche Nummer hat, sondern eine Schaltfläche „Kontakt“. Chef hingegen hat auf seiner Preisseite Nummern, aber Sie müssen sich trotzdem mit ihnen in Verbindung setzen. Ich würde Ihnen raten, sich direkt mit ihnen in Verbindung zu setzen und nach einem guten Angebot zu suchen. Abhängig von der Anzahl der Server, die Sie verwalten müssen, könnten sie Ihnen einen besseren Preis anbieten.

Es gibt kein Patentrezept

Als freundliche Erinnerung: Es gibt kein Patentrezept für ein Konfigurationsmanagement-Tool. Sowohl Chef als auch Puppet sind heutzutage sehr ausgereift, und sie verbessern ihre Produkte ständig, investieren in die Forschung, schaffen bessere Möglichkeiten, ihr Tool zu erlernen, usw. Ich hoffe, dieser Vergleich hat Ihnen geholfen, die Funktionsweise beider Tools besser zu verstehen. Vielleicht bereiten Sie sich auf ein Vorstellungsgespräch vor oder sind neugierig auf die wichtigsten Unterschiede und Gemeinsamkeiten.

Wenn Sie jedoch entscheiden, welches Tool Sie für Ihr Unternehmen einsetzen wollen, sollten Sie sich darüber im Klaren sein, welche Probleme Sie haben und wie diese Art von Tools Ihnen helfen kann, die Belastung zu verringern. Es wird immer eine Lernkurve geben, und es wird vom Hintergrund des Teams abhängen, welches Tool für sie besser geeignet ist. Außerdem sollten Sie sich neben dem Konfigurationsmanagement auch die Premium-Funktionen und -Dienste ansehen, da Ihr Unternehmen möglicherweise mehr Hilfe bei der Einhaltung von Richtlinien benötigt.

• Über den Autor
• Neueste Beiträge

Über Christian Melendez

Christian Meléndez ist ein Technologe, der als Softwareentwickler begann und in letzter Zeit zum Cloud-Architekten wurde, der sich auf die Implementierung von Continuous-Delivery-Pipelines mit Anwendungen in verschiedenen Geschmacksrichtungen konzentriert, darunter .NET, Node.js und Java, oft unter Verwendung von Docker-Containern.

• AWS Elastic Beanstalk .NET Core Getting Started – January 17, 2020
• AWS Batch: Ein detaillierter Leitfaden für den Start Ihres ersten Jobs – 26. Dezember 2019
• Azure Container Service (AKS) – Eine ausführliche Einführung – 18. Dezember 2019
• Senden von benutzerdefinierten CloudWatch-Metriken von Lambda mit Codebeispielen – 14. November 2019
• Chef vs. Puppet: Unterschiede, Gemeinsamkeiten und wie man sich entscheidet – September 24, 2019