Konfigurationsmanagement: Warum Ansible?

Manuelle Administration

Schritt für Schritt, Befehl für Befehl, auf jeder Maschine einzeln – funktioniert für wenige Systeme, skaliert aber nicht.

• Fehleranfällig bei vielen Servern
• Undokumentiert, da nur als Terminal-Historie existent
• Nicht reproduzierbar auf einem zweiten System

Puppet (2005)

Einer der ersten ernstzunehmenden Vertreter der Kategorie.

• Eigene deklarative Sprache (Puppet DSL)
• Client-Server-Modell mit zentralem Puppet-Master
• Pull-Prinzip: Agent fragt in Intervallen aktiv beim Master nach
• Mächtig, aber spürbare Lernkurve durch eigene DSL

Chef (2009)

Gleiches Grundprinzip wie Puppet, andere Sprachbasis.

• Konfiguration als "Recipes" in "Cookbooks" – echter Ruby-Code
• Attraktiv für Entwickler mit Ruby-Hintergrund
• Verlangt Programmierkenntnisse auch für einfache Aufgaben
• Ebenfalls Client-Server-Modell mit Agent

SaltStack (2011)

Fokus auf Geschwindigkeit und Skalierung.

• Eigene Nachrichten-Bus-Architektur (ZeroMQ)
• Sowohl Push- als auch Pull-Modell möglich
• Agent ("Minion") auf jedem verwalteten System nötig
• Sehr schnell bei sehr großen Fleets, aber zusätzliche Infrastruktur-Komponente

Ansible (2012)

Bewusster Gegenentwurf zu Puppet und Chef.

• Agentenlos – nur SSH und Python auf der Gegenseite nötig
• YAML statt eigener DSL oder Ruby-Code
• Push-Modell: Control Node verbindet sich aktiv zu den Zielsystemen
• Kein zusätzlicher Dienst, kein Master-Server zwingend erforderlich
• Geringe Einstiegshürde, dadurch heute Marktführer im Ad-hoc- und Playbook-Bereich

Gemeinsame Prinzipien

Trotz unterschiedlicher Wege verfolgen alle genannten Werkzeuge dieselben Grundideen.

• Deklarativ statt imperativ: Zielzustand beschreiben, nicht Einzelschritte
• Idempotenz: Wiederholte Ausführung verändert nichts, wenn Zielzustand bereits erreicht
• Infrastructure as Code: Konfiguration als versionierbarer Text, nicht als Befehlshistorie