Chef, Puppet, Ansible: Wozu dient Konfigurations-Management?
Viele Admins stellen sich die Frage, wie sie Änderungen für installierte Anwendungen, in der Konfiguration von Betriebssystemen oder von Diensten (etwa der IIS) über dutzende oder gar hunderte Server verwalten sollen. Hier kommen Tools für das Konfigurations-Management wie Chef, Puppet oder Ansible ins Spiel.
Große Unternehmen 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 Rechenzentrum oder in der Cloud handelt.
Im letzteren Fall ist die Wahrscheinlichkeit höher, dass die Anzahl zu verwaltender Systeme nicht nur größer ist, sondern auch stark fluktuiert (Auto Scaling), und hinsichtlich der Konfiguration (Betriebssystem, Anwendung) großen und häufigen Schwankungen unterliegt.
Wozu Konfigurations-Management?
Während man Anpassungen mit langer Lebensdauer, wie das Austauschen von Treibern, Agenten oder Tools auch auf andere Weise automatisieren kann und für Betriebssystem-Patches auch spezialisierte Lösungen zur Verfügung stehen, stellt das Management vom Anwendungs-Releases eine große Herausforderung besonders in Devops-Szenarien dar.
Lösungen für das Konfigurations-Management konzentrieren sich daher meist auf das Management von Applikationen, können sich aber je nach Konzeption auch um Betriebssysteme und auch Hardware (physisch oder virtuell) kümmern.
Dabei möchte man zudem sicherstellen, dass die verschiedenen 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 Konfigurationsdatei behoben werden könnte, dann muss man sich mit der Frage auseinandersetzen, 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 Administratoren sie aus Versehen zurücknehmen. Summa summarum lässt sich festhalten, dass IT-Infrastruktur jeglicher Art permanent verwaltet werden muss. Dazu gehören
- Paketaktualisierungen
- Neue Software
- Neue Konfigurationen
- Neue Anwendungsbereitstellungen
- Umgebungsspezifische Ä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 Herausforderungen im Config-Management gehört etwa das Ändern einer vhost-Konfiguration auf jedem Web-Server in mehreren Umgebungen (Development, Stage, Produktion), das Installieren 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 Gemeinsamkeiten und Unterschiede dieser Tools zeigt folgende Tabelle:
| Puppet | Chef | Ansible | |
|---|---|---|---|
| Kommerzielle Version | Puppet Enterprise | Chef Automate | Ansible Tower |
| Skriptsprache | Custom DSL auf Basis von Ruby | Pures Ruby | YAML |
| DSL-Stil | deklarativ | Deklarativ | imperativ |
| Mechanismus | Puppet-Master synchronisiert Änderungen auf die verwalteten Puppet-Knoten | Chef-Workstation pusht/pollt Änderungen zum/vom Chef-Server, der sie an die verwalteten Knoten pusht | Controller-Maschine verteilt Änderungen per SSH an den angegeben Knoten, sofern dieser SSH und Python ausführt. |
| Zentralisierte Kontrolle | Per Puppet Master | Per Chef Server | Jeder beliebige PC kann Ansible Controller sein. |
| Script-Terminologie | Manifeste und Module | Cookbooks und Rezepte | Playbooks und Rollen |
| Taskausführungs-Order | Nicht sequentiell | Sequentiell | Sequentiell |
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 Betriebssystem realisierbar ist - überträgt Ansible alle erforderlichen Komponenten zur Laufzeit, führt sie auf den Zielsystem aus und entfernt sie anschließend wieder.
Das Verfahren riecht zwar hinsichtlich der zu erwartenden Geschwindigkeit nach Showstopper, in der Praxis ist davon aber nichts zu spüren, zumal bei Ansible der Aufwand zur Pflege der Agenten wegfä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.
Keine Kommentare