Chef, Puppet, Ansible: Wozu dient Konfigurations-Management?

Viele Admins stellen sich die Frage, wie sie Änderungen für instal­lierte Anwen­dungen, in der Konfigu­ration von Betriebs­systemen oder von Dien­sten (etwa der IIS) über dutzende oder gar hunderte Server ver­walten sollen. Hier kommen Tools für das Konfigu­rations-Manage­ment wie Chef, Puppet oder Ansible ins Spiel.

Große Unter­nehmen können heute ohne Lösungen für das Konfigurations-Management kaum ein sinnvolles Operations-Management betreiben, egal ob es sich bei den verwalteten Systemen um physische oder virtuelle Server im eigenen Rechen­zentrum oder in der Cloud handelt.

Im letzteren Fall ist die Wahr­scheinlich­keit höher, dass die Anzahl zu ver­waltender Systeme nicht nur größer ist, sondern auch stark fluktuiert (Auto Scaling), und hinsichtlich der Konfiguration (Betriebssystem, Anwendung) großen und häufigen Schwankungen unter­liegt.

Wozu Konfigurations-Management?

Während man Anpassungen mit langer Lebensdauer, wie das Austauschen von Treibern, Agenten oder Tools auch auf andere Weise automa­tisieren kann und für Betriebs­system-Patches auch spezialisierte Lösungen zur Verfügung stehen, stellt das Management vom Anwendungs-Releases eine große Heraus­forderung besonders in Devops-Szenarien dar.

Lösungen für das Konfigurations-Management konzen­trieren sich daher meist auf das Management von Applikationen, können sich aber je nach Konzeption auch um Betriebs­systeme und auch Hardware (physisch oder virtuell) kümmern.

Dabei möchte man zudem sicher­stellen, dass die ver­schiedenen Einstellungen immer in einem definierten und guten Zustand bleiben. Das Problem tritt insbesondere in der Cloud auf, wenn Nutzer Systeme in großem Maßstab erstellen und verwalten.

Entdeckt man etwa einen Fehler in einem laufenden Web-Dienst, der durch eine einfache Änderung der Konfigurations­datei behoben werden könnte, dann muss man sich mit der Frage auseinander­setzen, wie man eine solche Änderung auf sämtliche in der jeweiligen Flotte laufenden Instanzen mit möglichst geringer Ausfallzeit anwendet.

Anwendungen für Konfigurations-Management

Wurden die Änderungen dann vorgenommen, muss man zuverlässig verhindern, dass andere Admini­stratoren sie aus Versehen zurück­nehmen. Summa summarum lässt sich festhalten, dass IT-Infrastruktur jeglicher Art permanent verwaltet werden muss. Dazu gehören

• Paket­aktuali­sierungen
• Neue Software
• Neue Konfigu­rationen
• Neue Anwendungs­bereit­stellungen
• Umgebungs­spezifische Änderungen

Vieles kann man zwar mit Infrastructure as Code (IaC) und Automatisierung lösen, wie etwa mit Terraform oder CloudFormation in AWS. Trotzdem braucht es dann aber immer noch eine Strategie zur Installation und Wartung einzelner Instanzen bzw. Server.

Web-Server-Farmen als Admin-Herausforderung

Zu den alltäglichen Heraus­forderungen im Config-Management gehört etwa das Ändern einer vhost-Konfiguration auf jedem Web-Server in mehreren Umgebungen (Development, Stage, Produktion), das Instal­lieren eines Pakets auf bestimmten Hosts, um neuere Versionen zu testen oder das Ändern der LDAP-Konfiguration auf jedem laufenden Linux-Host.

Folgende Abbildung zeigt eine allgemeine Architektur mit einem nicht näher spezifizierten Configuration server im Kontext der AWS-Cloud für das Management von Web-Server-Instanzen (Windows oder Linux). Dies funktioniert so aber auch mit anderen Cloud-Anbietern (Azure, Google) oder on premises.

Typen von Änderungen

Änderungen sind dabei stets:

• idempotent (findet nur einmal statt, bzw. werden nicht noch einmal angewendet)
• erzwungen (nicht autorisierte Änderungen werden zurückgesetzt)
• verteilt (Updates können auf eine ganze Flotte von Servern übertragen werden)

Vergleich von Puppet, Chef und Ansible

Die derzeit populärsten Vertreter sind Chef, Puppet, Ansible und Salt Stack. Die wichtigsten Gemeinsam­keiten und Unterschiede dieser Tools zeigt folgende Tabelle:

Hierbei fallen besonders die Unterschiede zwischen den beiden Master-/Client-Konzepten bei Puppet und Chef auf der einen Seite sowie Ansible auf der anderen Seite auf.

Während Puppet und Chef eine entsprechende Agent-Komponente auf den verwalteten Knoten voraussetzen, braucht Ansible auf diesen lediglich SSH und Python. Ist eine SSH-Verbindung zum Zielsystem möglich - was für nahezu jedes Betriebs­system realisierbar ist - überträgt Ansible alle erforder­lichen Komponenten zur Laufzeit, führt sie auf den Zielsystem aus und entfernt sie anschließend wieder.

Das Verfahren riecht zwar hinsichtlich der zu erwartenden Geschwindig­keit nach Showstopper, in der Praxis ist davon aber nichts zu spüren, zumal bei Ansible der Aufwand zur Pflege der Agenten weg­fällt und die Updates für Ansible selbst nur bei der lokalen Installation ins Gewicht fallen.

Zwar ist Puppet das ältere System, Einsteiger kommen aber mit Ansatz der Chef-Rezepte meist schneller zurecht, als mit dem etwas schwerer verständlichen Puppet-Manifesten, zumal bei Chef pures Ruby zum Einsatz kommt.