Configuration Management Ansible, Puppet, Saltstack – Welches Tool ist das richtige?

Der Aufwand, Applikationen und Services für die eigene Firma und für Kunden bereitzustellen, wächst, stetig. Die Anzahl der Systemadministratoren aber bleibt. Stellen bleiben unbesetzt - aus Kostengründen oder weil passendes Know-how nicht gefunden wird. Also müssten Prozesse und Aufgaben automatisiert werden, zum Beispiel mit Tools für das Konfigurations-Management. Was sollte ein solches Tool leisten können?

Anbieter zum Thema

Rosenberger-OSI GmbH & Co. OHG

DataCore Software GmbH

Datacenter One GmbH

ATIX AG

Red Hat GmbH

Configuration Management soll, wie der Name schon sagt, das Konfigurationen von Servern übernehmen. Dabei geht es darum, neue Server mit einer Basiskonfiguration auszustatten und Anwendungen auf diesen Servern zu installieren inklusive den benötigten Anpassungen von Konfigurationsdateien. Neben den neuen Servern ist es aber auch möglich Änderungen global, für einzelne Gruppen oder nur einzelne Hosts auszurollen und jeden Servern manuell umzukonfigurieren.

Wenn ein Administrator etwa die Aufgabe bekommt, 50 neue Linux-Server aufzusetzen und diese mit der unternehmensspezifischen Basiskonfiguration auszustatten, um sie dann an eine andere Abteilung zu übergeben, ist bei manuellem Abarbeiten dieser Aufgabe der Mitarbeiter zeitlich lange gebunden. Aber es besteht auch eine hohe Wahrscheinlichkeit, dass bei 50 neuen Maschinen am Ende bei vereinzelten Fällen Fehler in der Basiskonfiguration bestehen; denn bei dieser Menge wird gerne einmal ein Schritt vergessen. Oder es wird ein Script auf einer Maschine mehrfach ausgeführt und dabei eine Konfiguration durch doppeltes Bearbeiten in einem fehlerhaften Zustand versetzt. Eine automatisierte Umsetzung ist somit nicht nur eine Arbeitserleichterung sondern reduziert die Fehler und schafft Reproduzierbarkeit.

Arbeitserleichterung und Fehlervermeidung

Umgekehrt wird von solchen Tools eine Umsetzung mit Idempotenz als auch eine Form von „Infrastructure as Code“ gefördert und teilweise erzwungen. Idempotenz bedeutet in der IT, dass ein Skript oder Programmcode, mehrfach ausgeführt werden kann, aber immer das gleiche Ergebnis liefert.

Tools für Configuration Management führen dementsprechend nur Änderungen an Konfigurationen durch, die notwendig sind. Wenn die Konfiguration bereits im richtigen Zustand ist, wird der Schritt übersprungen. Damit können die entsprechenden Skripte auf jedem Host mehrfach ausgeführt werden, ohne dass dadurch Probleme entstehen.

Infrastructure as Code hat den Vorteil, dass die Server-Konfiguration in einer lesbaren Form beschrieben ist. Dieser Code wird zentral verwaltet. Die Versionskontrolle erfolgt üblicherweise mit „git“. Typischerweise wird beim Configuration Management der Code zur Umsetzung von der Parametrisierung für die eigene Umgebung getrennt. Dadurch kann der Code universeller gestaltet sein und wiederverwendet werden.

Hilfe durch die Community

In der Community teilen viele ihre Module und Rollen zur Umsetzung der Konfiguration für bestimmte Anwendungen, so dass man nur die entsprechenden Parameter einsetzen muss. Das erspart die Arbeit, die Module für gängige Use-Cases neu zu entwickeln, und durch eine aktive Community werden so bestehende Module weiterentwickelt und verbessert.

Der Code selbst ist typischerweise deskriptiv und verwendet eine für das Tool entwickelt Syntax. Dabei wird Wert auf ein gewisses Maß an Lesbarkeit und Einfachheit gelegt. Darunter werden je nach Tool, die Funktionen in einer Programmiersprache wie „Ruby“ oder „Python“ umgesetzt.

Im Endeffekt beschreiben die Module selbst aber nicht den Weg zur Umsetzung, sondern wie Ressourcen, zum Beispiel installierte Pakete, Dateien und Ordner, auszusehen haben. Dadurch wird ein Soll-Zustand für die Konfiguration erstellt und die Tools vergleichen den Soll- mit dem Ist-Zustand und führen die nötigen Änderungen durch um den Soll-Zustand zu erreichen.

Ansible, Puppet und Saltstack

Es gibt viele Tools, die man für ein Configuration Management einsetzen kann. Die drei gängigsten Open-Source-Produkte sind: „Ansible“, „Puppet“ und „Saltstack“.

Ansible ist der Newcomer unter den Dreien mit einem ersten Release im Jahr 2012. Drei Jahre später hat Red Hat das Tool aufgekauft und entwickelt es weiter. Zu Ansible gibt es eine Enterprise Version mit einer Web-Oberfläche mit der Bezeichnung „Ansible Tower“. Die Upstream-Variante für die Ansible-Tower mit der Oberfläche und einer REST API trägt die Bezeichnung „AWX“. Ansible verwendet als Programmiersprache Python und konfiguriert die Zielsysteme, indem eine SSH-Verbindung geöffnet und mit entsprechenden Python-Skripten die Tasks abgearbeitet wird.

Da Ansible inzwischen auch eine sehr große Community besitzt, gibt es mit „Ansible Galaxy“ einen Community-Hub der als Anlaufstelle für vorgefertige Rollen dient. Mit diesen Rollen stellen andere Nutzer ihre Ansible Umsetzungen für die Konfiguration einer Anwendung oder eines Dienstes, idealerweise mit einer Dokumentation, bereit, so dass man diese nicht komplett selbst schreiben muss. Im besten Fall bekommen andere also mit wenig Aufwand schon eine Lösung. Wenn man eigene Rollen entwickelt, lassen sich diese in Ansible Galaxy anderen Nutzern zur Verfügung stellen. Aktuell umfasst die Ansible Galaxy etwa 22.000 Rollen von anderen Nutzern.

Das Erste

Puppet ist bereits 2005 veröffentlicht worden und war lange Zeit der Platzhirsch unter den Tools. Puppet wird von der Firma Puppetlabs mit Support als Produkt Puppet Enterprise vertrieben.

Im Gegensatz zu Ansible basiert Puppet auf Ruby als Programmiersprache und verwendet eine Client-basierte Kommunikation. Auf den Zielsystemen wird ein so genannter Puppet Agent installiert, der im Normalfall alle 30 min beim entsprechenden `Puppetmaster´ anfrägt, wie die Konfiguration auszusehen hat. Anschließend vergleicht der Agent den Ist- mit dem Soll-Zustand und führt gegebenenfalls die nötigen Änderungen durch um den Soll-Zustand zu erreichen.

Wie bei Ansible gibt es auch bei Puppet eine aktive Community, die ihre Puppet-Module in der „Puppet Forge“ zur Verfügung stellen. Der Umfang ist mit etwa 6.300 Modulen geringer als der von Ansible Galaxy, allerdings sind die Module die hier zur Verfügung stehen in der Regel besser gepflegt und veraltete Module regelmäßig entfernt.

Das Dritte im Bunde

Saltstack von der gleichnamigen Firma wurde 2011 veröffentlicht. Auch hier existiert eine Enterprise Version mit Support vom Hersteller mitder Bezeichnung „Saltstack Enterprise“. Wie bei Ansible wird bei Saltstack Python als Programmiersprache verwendet.

Im Gegensatz zu den anderen beiden Tools aber gibt es bei Saltstack die Möglichkeit, sowohl eine Client-basierte als auch eine Form über SSH zu verwenden. Bei der Variante mit Clients gibt es einen ´Saltmaster`, der die ´Salt Minions` versorgt, ähnlich wie es bei Puppet mit dem Puppetmaster und den Puppet-Agents der Fall ist. Bei der Variante von salt-ssh kann Saltstack ähnlich wie Ansible verwendet werden; die Verbindung wird über SSH hergestellt und das Zielsystem muss keinen Agenten installiert haben, sondern nur einen passenden Zugriff über SSH. Zusätzlich gibt es bei Saltstack die Möglichkeit Aktionen über ´Event-Trigger` auszulösen.

Die Community bei Saltstack ist im Vergleich zu Puppet und Ansible deutlich kleiner. Es gibt fertige Module, so genannte Formulas, in einem Github-Repository der Saltstack-Entwickler. Dabei darf sich auch jeder beteiligen, aber durch die kleinere Community, stehen dort nur etwa 300 Formulas zur Verfügung. Zudem gibt es im Vergleich zu Puppet und Ansible hierbei pro Anwendung nur eine Formula. Bei Puppet und Ansible stehen somit zu bestimmten Anwendungen deutlich mehr Varianten von unterschiedlichen Entwicklern zur Verfügung.

Gemeinsamkeiten und Unterschiede

Bei allen Tools ist die Skriptsprache so gehalten, dass diese lesbar und verständlich sind. Insgesamt gibt es auch hier Gemeinsamkeiten aber die Syntax ist doch bei allen drei Tools unterschiedlich.

Beispiel: Installation des NTP-Pakets (unabhängig von Linux-Distribution) und Einfügen eigener NTP-Server in Ansible

1. Ausschnitt aus Vars-File oder Inventory:

2. Ausschnitt aus Playbook/Role:

Ausschnitt aus Template ntp.conf.j2:

Dabei orientiert sich Puppet noch an der Ruby-Basis, während Ansible (s.o.) alles im YAML-Format einfach hält, solange die Einrückungen richtig sind. Sehr einfache Beispiele sind in den Code-Beispielen zu finden.

Beispiel: Installation des NTP-Pakets (unabhängig von Linux-Distribution) und Einfügen eigener NTP-Server in Puppet

1. Ausschnitt aus Hiera:

2. Ausschnitt aus ntp-Module:

2. Ausschnitt aus Template ntp.conf.epp:

Beispiel: Installation des NTP-Pakets (unabhängig von Linux-Distribution) und Einfügen eigener NTP-Server in Saltstack

1. Ausschnitt aus Pillars:

2. Ausschnitt aus ntp-state:

3. Ausschnitt aus Template ntp-client.conf:

Neben ähnlicher Verwendung des Codes sollte man aber beachten, dass sich die jewilige Terminologie der Tools teilweise unterscheidet. So sind Module bei Ansible und Salt ein anderer Baustein des Konstrukts als Puppet. Dies kann somit bei einem Vergleich verwirrend wirken, wenn man eines der Tools kennt, da unter dem gleichen Namen unter Umständen etwas anderes gemeint ist.

Grundsätzlich ist der Einsatzzweck von allen drei Tools sehr ähnlich – nämlich die Konfiguration und das Management von Servern. Aber auch die kleinen Unterschiede führen dazu, dass bestimmte Szenarien eine bestimmte Form von Tools bevorzugt. So gibt es zum Beispiel Szenarien, in denen ein Client-basiertes Tool besser geeignet ist – und andere in denen ein Tool über SSH mit einer vorgeschriebenen Reihenfolge die Aufgaben besser lösen kann.

Client-basierte Tools überprüfen in regelmäßigen Zeitabständen ob die Konfiguration in dem Zustand vorliegt, wie der jeweilige Master es vorgibt. Das bedeutet wenn am Master einzelne Änderungen für alle, eine Gruppe oder einzelne Hosts eingepflegt werden, dauert es, bei Puppet zum Beispiel maximal 30 Minuten, bis alle Server diese Änderungen umgesetzt haben.

Zusätzlich werden Änderungen, die lokal erzeugt werden, zum Beispiel weil ein User „kurz mal ´was ausprobiert“, bei jedem Durchlauf wieder rückgängig gemacht. Zum Ärgernis des jeweiligen User kann dies Sekunden nach seiner Änderung sein, oder auch nach dem entsprechenden maximalen Zeitintervall, zu dem der Client die Konfiguration erneut überprüft.

Vorteile von regelmäßigen Durchläufen

Dadurch ist eine gewisse Persistenz der Konfiguration gegeben, was für eine Grundkonfiguration eines Servers hilfreich ist, insbesondere auf Systemen, auf denen Benutzer solche Konfigurationen abändern könnten, aber eigentlich nicht sollen. Zudem lassen sich darüber gut die angelegten Benutzer, ihre Gruppen und deren SSH-Keys verwalten, so dass diese auf allen Systemen die gleichen IDs verwenden. Das ist zum Beispiel für Service-Accounts hilfreich, die lokal bestehen und nicht von einem Identity Management versorgt werden.

Tools wie Ansible, die gezielt ausgelöst werden, eignen sich somit deutlich besser für Aufgaben, bei denen die Reihenfolge eine Rolle spielt. Bei der Installation eines Kubernetes-Clusters muss zuerst ein Master installiert werden, an den sich dann weitere Server verbinden, um das Cluster-Netzwerk aufzubauen. Eine Aufgabe, für die mehrere Server Tasks abarbeiten und deren Voraussetzungen zunächst auf anderen Maschinen erfüllt sein müssen, ist die Umsetzung über Clients, die nur in bestimmten Intervallen Änderungen durchführen, schwierig umzusetzen.

Die SSH-basierten Tools werden daher häufig verwendet, um Anwendungen zu installieren und zu konfigurieren. Sie werden erst ein weiteres Mal ausgeführt, wenn Änderungen ausgerollt werden müssen. Im Gegensatz zur Persistenz von den Client-basierten Tools ist unter Umständen auch gewünscht, dass Änderungen an der Konfiguration vorgenommen werden dürfen und somit, dass das Configuration-Management-Tool nur einen Anfangszustand definiert.

Unverträglichkeiten und Kombinationen

Die Wahl des Tools darf nicht im Konflikt mit anderen Anwendungen stehen. Ein Kubernetes-Cluster verwaltet zum Beispiel dynamisch anhand der darauf laufenden Container, die Firewall-Regeln von „iptables“. Wenn Puppet diese Regeln ebenfalls verwaltet und die dynamisch erzeugten Regeln löscht oder überschreibt, sind die entsprechenden Dienste aus den Containern des Kubernetes-Clusters nicht mehr lauffähig oder erreichbar.

Zugleich aber ist ist eine Kombination von mehr als einem Tool nicht ausgeschlossen. Es kann durchaus Sinn machen, die Basiskonfiguration von Servern mit einem Tool wie Puppet umzusetzen, während die Anwendungen, die auf dem Server betrieben werden sollen, über eine Tool wie Ansible zu installieren und konfigurieren werden.

Da solche Konstellationen häufig mit unterschiedlichen Abteilungen eines Unternehmens verknüpft sind, müssen wie in dem Beispiel zu den Firewall-Regeln mit Kubernetes auch hier Vorkehrungen beziehungsweise Absprachen getroffen werden. Es sollte ausgeschlossen sein, dass zwei unterschiedliche Tools die gleiche Konfiguration bearbeiten. Ist so etwas der Fall „gewinnt“ langfristig gesehen das Tool mit periodischen Durchläufen über jenes, welches nur einmal ausgeführt wird.

Die Wahl

Die Wahl des richtigen Tools hängt somit von mehreren Faktoren ab.

• Zunächst spielt es eine Rolle, welche Ziele beziehungsweise Anwendungen mit dem Tool konfiguriert werden sollen. Dadurch kann sich bereits eine Präferenz ergeben: Ist es ein Client- oder ssh-basiertes Tool?

• Wenn noch kein Tool vorhanden ist, kann entscheidend sein, ob für die gewünschten Zwecke bereits viele Ressourcen in der Community vorhanden sind. Denn bei einer umfangreichen Infrastruktur und deren Konfiguration, ist der Zeitaufwand höher, wenn zunächst die passenden Module und Rollen zu schreiben sind, um alle Konfigurationen damit umzusetzen. Wenn auf eine aktive Community zurückgegriffen werden kann, in der vorgefertigte und dokumentierte Rollen verfügbar sind, kann dies umgekehrt den Zeitaufwand deutlich reduzieren.

• Außerdem spielen die Features eine Rolle. So kann zum Beispiel die Möglichkeit von Saltstack, Events zu überwachen und bei der Überschreitung von bestimmten Grenzwerten eine gewünschte Rollen oder Aktion auszulösen, ein deutlicher Mehrwert sein und die größere Auswahl von Community-Modulen übertrumpfen. Das dürfte insbesondere der Fall sein, wenn ohnehin sehr spezielle oder selbstentwickelte Software konfiguriert und einen Großteil der Module selbst geschrieben werden muss.

Grundsätzlich aber lassen sich die meisten Aufgaben mit jedem der drei Tools erreichen.

* Dr. Jonas Trüstedt arbeitet für die Atix Informationstechnologie und Consulting AG, München.

(ID:46292132)