Konfigurationsmanagement: Puppet vs Ansible

Die Vorteile von Konfigurationsmanagement

Das Einrichten und Aktualisieren einer großen Anzahl von Systemen kostet nicht nur viel Zeit und Aufwand. Die Fehlerquote bei der manuellen Einrichtung ist entsprechend höher und auch vom Standpunkt der Wirtschaftlichkeit aus gesehen ist manuelle Arbeit nicht mehr machbar.

Konfigurationsmanagement und Automatisierung auf Knopfdruck sind spätestens seit der DevOps-Bewegung das Ziel der IT-Abteilungen. Konfigurationsmanagement-Tools automatisieren einen Großteil der notwendigen Vorgänge und minimieren so auch die Möglichkeit von Fehlern und Unterschieden. Upgrades auf neuere Versionen werden durch reproduzierbare Testsysteme vereinfacht. Durch Versionierung von Änderungen entsteht eine Nachvollziehbarkeit von Entscheidungen und bietet dabei auch gleich eine teilweise Dokumentation der gesamten Umgebung(en).

Wird eine größere Anzahl von Systemen konfiguriert und verwaltet, empfiehlt sich also der Einsatz eines Konfigurationsmanagement-Tools. Puppet und Ansible zählen hier zu den meisteingesetzten Produkten und verfolgen unterschiedliche Wege, um das gemeinsame Ziel zu erreichen: Beide dienen dazu die Komplexität der Konfiguration von verteilten Infrastruktur-Ressourcen zu reduzieren und dabei Geschwindigkeit, Zuverlässigkeit und Compliance zu gewährleisten.

Die Auswahl des passenden Werkzeugs zum Konfigurationsmanagement kann sich entscheidend auf die Effizienz des IT-Betriebs auswirken. Im Folgenden werden daher sowohl Puppet, als auch Ansible hinsichtlich ihrer Funktionsweisen sowie ihrer Vor- und Nachteile eingehender betrachtet.

Puppet – der Altmeister der Konfigurationswerkzeuge

Puppet wurde bereits 2005 gegründet und zählt damit zu den frühesten Infrastruktur-Konfigurations-Management-Tools. Es wurde entwickelt, um die Aufgaben von Systemadministratoren zu automatisieren. Zunächst diente es dem Zweck Konfigurationsdateien zu verteilen, die an einem zentralen Ort für alle Systeme im Netzwerk gespeichert und gepflegt wurden. Puppet fügte jedoch schnell zusätzliche Features hinzu, die mehr als das bloße Erstellen von Roll-out-Dateien umfassen, einschließlich der Fähigkeit, die Konfiguration aus externen Quellen abzurufen.

Die Manifeste der Open-Source-Konfigurationsmanagement-Lösung werden in einer benutzerdefinierten Domain Specific Language (DSL) geschrieben. In einem Manifest (Puppet-Plan) stehen nicht die einzelnen auszuführenden Schritte, sondern die Definition des Zielzustandes von Ressourcen. Packages können z.B. dabei die Zustände present, absent oder latest annehmen. Puppet überführt die Package-Ressourcen in einen Zustand und entscheidet darüber, welcher Package-Manager verwendet wird (Puppet ist Plattform-agnostisch) und führt die entsprechende Operation durch um Paket zu installieren oder zu löschen. Da die Ressourcen voneinander abhängen, wird ein Service erst nach der Installation des dazugehörigen Pakets starten. Ressourcen können als Abhängigkeit beliebig oft in allen Manifesten stehen, jedoch dürfen sie nur einmal deklariert werden. Hiermit wird verhindert, dass z. B. zwei Java-Versionen als aktuell deklariert sind und je nachdem wie das Manifest ausgeführt wird, die eine oder die andere verwendet wird.

Administratoren können Module mit der Community teilen und so einen Beitrag zur Welt der Open-Source-Systemadministration leisten. Puppet funktioniert auf Linux, Microsoft Windows und UNIX-basierten Systemen wie AIX, Solaris und Mac OS X. Es verwendet eine Agent/Primary-Architektur.

Zwei Möglichkeiten für die Serverkonfiguration mit Puppet:

• Die Puppet-Konfiguration ist auf jedem einzelnen Host vorhanden. In diesem Fall greift der Agent lokal auf die Konfiguration zu und setzt sie entsprechend um.
• Oder aber, Puppet wird mit einem Primary Server ausgeführt. Dann stellen die Agenten auf den verschiedenen Hosts eine Verbindung zum Primary Server her. Sie fordern relevante Informationen zur Konfiguration vom Master an.

Es ist einfacher, zunächst ohne zentralen Server (masterless) zu arbeiten. Allerdings sind die Anwender in diesem Fall dazu gezwungen, sich beispielsweise um das Verteilen aktueller Manifeste mit Git selbst zu kümmern. Es ist auch möglich, zu einem späteren Zeitpunkt noch auf einen zentralen Server umzusteigen, jedoch ist dies mit einem gewissen Aufwand verbunden. Bei der Konfiguration von mehreren Servern empfiehlt es sich Konstrukte zur Wiederverwendung von Teil-Manifesten und zur Modularisierung zu verwenden, da ein einzelnes langes Manifest zu unübersichtlich ist.

Doch woher nimmt Puppet die Informationen, welcher Plan für welchen Server gedacht ist?

Wird Puppet mit einem Primary Server betrieben, gibt es eine zentrale Datei in der die Node-Definitionen enthalten sind. Mit den Administrationstools können Nodes zu Gruppen zusammengefasst und einzelnen Nodes-Gruppen Klassen und Variablen zugewiesen werden. Wenn bereits ein anderes Werkzeug zur Verwaltung der IT-Assets im Einsatz ist, kann es sinnvoll sein alternativ ein Skript zu schreiben, dass die Zuordnung vornimmt.

Was sind Puppet Manifeste?

Puppet Manifeste beschreiben den gewünschten Zustand eines Systems. Dabei läßt sich die Reihenfolge der Schritte nicht eindeutig vordefinieren. Ziel ist es, den definierten Zustand zu erreichen. Es gibt Situationen, die einen sequenziellen Ablauf von Konfigurationsschritten erfordern. Ein Beispiel wäre ein rollierendes Patchen von Webservern. Hier kommt es auf eine genaue Abfolge der Schritte an, damit es beim Patchen nicht zu
Ausfallzeiten kommt. Zu diesem Zweck bietet Puppet Pläne und Tasks zur Orchestrierung an. Pläne werden in der Puppet DSL geschrieben und stellen praktische Sprachmittel zur Realisierung von sequenziellen Abläufen zur
Verfügung. Innerhalb der Pläne können Aufgaben (Tasks) ablaufen.

Die Vor- und Nachteile von Puppet

Ansible – der aufstrebende Neuling

Ansible entstand 2012 und zählt daher zu den neuesten Konfigurations-Management-Tools auf dem Markt. Es wurde 2015 von Red Hat übernommen.

Ansible kombiniert Softwareverteilung, Ad-hoc Befehlsausführung und Konfigurationsdateimanagement. Allerdings verwendet es dabei nicht wie Puppet ein Server-Client-Prinzip, sondern SSH, um mit den einzelnen Systemen zu sprechen und die notwendigen Konfigurationsschritte auszuführen. Es benötigt dazu auf den Systemen lediglich einen SSH-Server und eine Python 2.6/2.7-Installation. Ansible nutzt also weder ein eigenes Protokoll noch eine Client-Software. Im Gegensatz zu Puppet benötigt Ansible also keine zu installierenden Agenten. Aus diesem Grund kann Ansible die gewünschte Konfiguration nicht dauerhaft durchsetzen. Änderungen an Systemen werden nur korrigiert, wenn das entsprechende Playbook erneut ausgeführt wird.

Playbooks (YAML-Dateien) beschreiben den Zustand eines Systems. Mit ihrer Hilfe kann z. B. jedes beliebige Shell-Kommando auf einem System ausgeführt werden. Zusätzlich enthält Ansible eine Anzahl eingebauter Module, durch deren Aufruf Aktionen einfach ausgeführt werden können, ohne dass dafür die korrekte Kommandozeilen-Syntax nötig ist. Außerdem achten die Module auf die Umgebung in der sie ausgeführt werden und erlauben so die Verwendung des gleichen Codes auf unterschiedlichsten Systemen.

Aus den Playbooks und den dazugehörigen Dateien erstellt Ansible kleine Python-Programme. Diese werden mittels SSH auf die Systeme übertragen, dort ausgeführt und anschließend wieder gelöscht. Aufgrund der Multiplexing-Funktion der OpenSSH-Implementierung funktioniert Ansible auch mit einer großen Anzahl von Tasks performant. Verbindungen und Anweisungen können so gleichzeitig ablaufen und es muss nicht immer wieder eine neue Verbindung zum Host aufgebaut werden.

Ansible kann auch als Orchestrierungslösung genutzt werden, die Nutzern das Betreiben virtueller Maschinen in Cloud-Umgebungen erleichtert. Das Ansible-Handbuch umfasst Module für nahezu jede Cloud-Umgebung.

Die Vor- und Nachteile von Ansible

Puppet vs Ansible – Unterschiede

Der Hauptunterschied der beiden Konfigurationsmanagement-Lösungen liegt in ihrer Arbeitsweise. Puppet verwendet normalerweise Agenten, die auf jeder einzelnen Maschine installiert werden. Ansible hingegen läuft von einem Ort aus und verbindet sich mit den Maschinen, die es verwaltet mit SSH. Allerdings kann Puppet auch Orchestrierungen mittels SSH/WinRM ohne Puppet Agenten ausführen.

Es findet also keine Ansible-Installation auf den einzelnen Maschinen statt. Allerdings ist es notwendig, dass sich auf jeder Maschine eine Python 2 Installation befindet. Vor allem bei neuen Linux Distributionen ist dies unter Umständen nicht mehr der Fall.

Eigenschaften	Puppet	Ansible
Zugriff	Agent Installation bzw. SSH/WinRM	SSH bzw. git
Konfigurationssprache	YAML und Puppet DSL	Konfiguration in YAML
Erweiterbarkeit	Ruby	Python
Templatesprache	EPP, ERB	Jinja
Community	Puppet Forge	Ansible Galaxy

 

Die Konfiguration findet bei Ansible im YAML statt, während hingegen Puppet zusätzlich eine eigene DSL bietet. Erweitern lässt sich Puppet in Ruby und Ansible mit Python.

Wann eignet sich welches der beiden Tools?

Puppet eignet sich besonders für das Management von heterogenen Umgebungen. Durch den Agenten gibt es eine native Unterstützung unterschiedlicher Systeme. Bei Ansible für Windows gibt es nur eine rudimentäre Unterstützung, da die Module aufgrund der Nutzung von PowerShell neu entwickelt werden müssen.

Ansible hat Vorteile, wenn es um ältere Systeme geht, sofern mindestens Python 2.6 installiert ist. Es muss keine weitere Software installiert werden und damit lassen sich auch legacy Systeme einfach verwalten. Dadurch dass keine Installation notwendig ist, können Anwender sofort loslegen.

Ansible hat gewisse Vorteile, wenn es um die Performance geht. Während eines typischen Setups zieht sich ein Puppet-Agent zunächst beim Start eines Puppet-Run die gesamte Konfiguration vom Master und lädt diese in den lokalen Cache. Anschließend generiert der Puppet-Master einen vollständigen Katalog für einen Host und erst dann erfolgt die Ausführung. Allerdings beherrscht Puppet auch die Orchestrierung mittels Tasks und Plänen. Damit entfällt die Nutzung eines Puppet Agents. Ansible führt ausstehende Arbeiten auf verschiedenen Hosts deutlich schneller aus. Es kopiert die entsprechenden Module auf das System und führt diese mit den angegebenen Parametern aus. Die Ansible Playbooks sind auch auch für den Laien lesbarer. Dies wird dadurch unterstützt, dass die einzelnen Tasks jeweils auch einen Namen bekommen können. Auch wenn man bisher wenig mit Ansible zu tun hatte, sind sie aufgrund ihrer klaren Struktur einfacher nachzuvollziehen. Auf der anderen Seite können komplizierte Setups in Ansible für den klassischen Programmierer unübersichtlich werden, da die gesamte Konfiguration in YAML Datenstrukturen hinterlegt ist. Konstrukte wie Schleifen müssen hier durch bestimmte Konstrukte nachgebildet werden.

Die Trennung von Daten und Code ist wiederum bei Puppet deutlich einfacher. Hier gibt es mit Hiera eine hierarchische Datenbank, die alle Konfigurationswerte enthalten und somit der Code für unterschiedliche Systeme und Umgebungen angewendet werden kann. Puppet erfordert zu Beginn eine Einarbeitungsphase in die Puppet DSL. Danach geht die Konfiguration von Servern sehr schnell von der Hand. Aufgrund des Puppet Agents kann man sich im Gegensatz zu Ansible sicher sein, dass die Konfiguration auf den durch Puppet verwalteten Servern der gewünschten Konfiguration entspricht.

Wichtig ist anzumerken, dass Ansible deutlich jünger ist als Puppet. Inwiefern die Lösung noch weiter wächst und welche Arten von Features noch hinzukommen können, besonders nach dem Kauf durch Red Hat, bleibt abzuwarten. Es spricht aber auch nichts dagegen beide Tools parallel zu nutzen. Dies wird so z. B. bei Red Hat Satellite 6 so gemacht. Die eigentliche Konfiguration wurde über Puppet abgebildet, „on-Demand“ Funktionalität nutzt Ansible.

Noch Fragen zu IT-Automation?

Falls Sie Fragen rund um IT-Automatisierung haben oder eine passende Automation-Lösung suchen, sind wir gerne für Sie da, von der Beratung bis zur Implementierung.

 

August 2022: Update des ursprüglichen Blogbeitrages von 2017