Open Source im professionellen Einsatz
Linux-Magazin 01/2016
© alphaspirit, 123RF

© alphaspirit, 123RF

Zwei Welten treffen aufeinander: Puppet und Ansible

David gegen Goliath

Automatisierung gehört im Rechenzentrum zum guten Ton. Puppet gilt als Platzhirsch und darf von sich behaupten, bei Unternehmen wie Google im Einsatz zu sein. Ansible ist eine schlanke Alternative.

816

"Früher war alles besser." Das geflügelte Wort steht dafür, dass der Mensch gern in Erinnerungen an die vermeintlich gute alte Zeit schwelgt. Systemadministratoren bilden da keine Ausnahme: Gerne erinnert sich mancher an die Zeit zurück, in der IT-Setups noch aus einer überschaubaren Anzahl von Servern bestanden, deren händische Verwaltung problemlos möglich war. Diese Zeiten sind vorbei: Die großen Hoster zum Beispiel haben Tausende Hosts unter ihren Fittichen und betreuen viele der Rechner im Auftrag ihrer Kunden.

Mit Handarbeit ist da kein Blumentopf mehr zu gewinnen: Längst haben Werkzeuge für Konfigurationsmanagement und Automatisierung die Kontrolle in vielen Rechenzentren übernommen. Wohl jeder Admin kennt die einschlägigen Lösungen: Puppet [1] und Chef [2] sind die Goliaths ihrer Art und halten zusammen ein stattliches Stück vom großen Automatisierungskuchen.

Für Puppet gilt allerdings auch, dass viele Admins dem Werkzeug regelmäßig Tod und Teufel an den Hals wünschen: Zu komplex soll es sein und zu weit habe es sich von seinen ursprünglichen Idealen fortbewegt. Da kommt ein junger Wilder wie Ansible [3] gerade recht: Dieses Tool verspricht eine bessere Automatisierungslösung zu sein, die deutlich leichter zu durchdringen ist und dabei keine Funktionalität vermissen lässt. Der folgende Artikel stellt Puppet als Vertreter der hergebrachten Automatisierer und Ansible als den Underdog gegenüber und streicht Gemeinsamkeiten wie Unterschiede heraus. Wofür ist Ansible tatsächlich zu gebrauchen? Kann es Puppet ernsthaft gefährlich werden?

Selbst in den schon beschworenen goldenen Zeiten, als jeder Server noch eine echte Handaufzucht war, konnte es nötig sein, die Konfigurationsdateien einzelner Dienste auf mehreren Servern synchron zu halten. Diverse Bastellösungen auf Basis von Rsync oder SCP legen davon Zeugnis ab. Sogar eigene Werkzeuge entstanden für diesen Zweck: Die Wiener HA-Spezialisten von Linbit etwa entwickelten Csync2 – ein Tool, dessen einzige Aufgabe war, Dateien in HA-Clustern auf demselben Stand zu halten.

Dass all diese Ansätze nur Krücken waren, wurde schnell offensichtlich. Als 2005 die erste Version von Puppet erschien, wirkte das von den Entwicklern gegebene Versprechen revolutionär: Konfigurationsdateien, die an zentraler Stelle hinterlegt und gepflegt werden, ließen sich mit Puppet auf eine beliebige Anzahl von Servern verteilen.

Auch Puppet war mal Underdog

Bald konnte Puppet nicht nur Dateien ausrollen, sondern auf den betroffenen Servern gleich auch einzelne Befehle aufrufen, zum Beispiel um Pakete nachzuinstallieren. Die Puppet-Entwicklung ging mit riesigen Schritten voran: Die eigene Deklarationssprache DSL erlaubte es, generische Module zu verfassen, die einzelne Aufgaben erledigten. Fertige Module konnten Admins mit der Öffentlichkeit teilen und so einen Beitrag zur Welt der Open-Source-Systemadministration leisten.

Puppet selbst wuchs und wuchs. Diverse wichtige Features hielten im Laufe der Entwicklung Einzug, etwa die Möglichkeit, die Konfiguration aus externen Quellen zu beziehen. Die ENCs – das steht für External Node Classifiers – existieren heute in verschiedenen Formen und Geschmacksrichtungen von unterschiedlichen Herstellern. Eigentlich ist also alles bestens im Puppet-Land. Wie erklärt sich dann aber die offene Abneigung vieler Admins gegenüber dem Tool?

Mit der Zeit wurde Puppet immer komplexer

Der mit Abstand am häufigsten formulierte Vorwurf an Puppet ist, dass sich das Werkzeug von seinen ursprünglichen Zielen wegbewegt hat und im Rechenzentrum eine eierlegende Wollmilchsau sein will. Die hohe Komplexität lasse Puppet, so seine Kritiker, für die effektive Nutzung unbrauchbar werden. Wo eigentlich die Reduktion von Komplexität das Ziel von Automatisierung sei, füge Puppet noch Komplexität hinzu. Die schon erwähnten Puppet-Module sind dafür ein gutes Beispiel: In der Anfangszeit von Puppet gab es für die meisten Probleme genau ein Modul. Wer also mit Puppet Rsyslog installieren wollte, fand dafür im Netz genau eine Lösung.

Der Haken an der Sache: Die Entwickler entwarfen Module mit Blick auf exakt ein Einsatzszenario. Entsprechend schlecht fügen sie sich in andere Setups ein. Bald griffen Forks vorhandener Module um sich: Wer eine Modifikation eines vorhandenen Moduls für seine lokale Installation benötigte, forkte es und veröffentlichte den Fork im Anschluss selbst. Wer heute nach Puppet-Modulen für Rsyslog sucht, ist erst mal damit beschäftigt, sich durch die einzelnen Alternativen zu ackern und das beste Modul für den eigenen Zweck zu finden. Schon die Frage, welche Linux-Distribution ein Puppet-Modul unterstützen soll, entscheidet oft über Wohl und Wehe.

Das Puppet-Projekt hat selbst versucht, diesem Treiben Einhalt zu gebieten: Puppetforge [4] gilt als autoritative Quelle für Puppet-Module und zeichnet auch solche Module gesondert aus, die Puppet selbst pflegt. Allerdings kann auch jeder andere Nutzer seine Module auf Puppetforge hochladen. Letztlich trägt Puppetforge zur Verwirrung also eher bei, als sie zu verhindern.

Dann ist da noch das leidige Thema der Modulpflege: Diverse Module, die sich im Netz finden, sind älteren Datums und funktionieren auf neueren Systemen oft nicht oder nicht mehr richtig. In jedem Einzelfall muss der Admin selbst herausfinden, ob das bei einem bestimmten Modul so ist oder nicht.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Ansible 2.0

    Mit einer überarbeiteten und schnelleren Engine geht die neue Version 2.0 der in Python geschriebenen Orchestrierungssoftware Ansible an den Start. Reicht das für eine Pole Position?

  • Perl-Snapshot

    Das überlichtgeschwinde Provisionierungstool Ansible eignet sich nicht nur für Konfigurations- und Releasemanagement mittelgroßer Serverfarmen, sondern auch für den Hausgebrauch, zum Restaurieren von Anpassungen auf dem Linux-Desktop daheim.

  • Netzwerkautomation

    Mit den richtigen Werkzeuge verwalten Admins ihre Infrastruktur nicht nur automatisch, sondern auch effektiv. Sogar das Thema Devops macht vor der Netzwerkinfrastruktur nicht halt, auch wenn es sich gerade dort erst zögerlich durchsetzt.

  • Chef und Puppet

    Puppet und Chef gelten als Allheilmittel für große IT-Architekturen, in Devops-Szenarien führt an den Konfigurationsmanagern kaum ein Weg vorbei. Doch der Teufel steckt im Detail und wer nicht aufpasst, steigt schnell in ein veritables Fettnäpfchen.

  • Cloudverwaltung

    Cloudumgebungen sind in vielen Unternehmen dabei, die eigene IT abzulösen. Wer am Ende mehrere Clouds effizient verwalten muss, der braucht die richtigen Werkzeuge. Dieser Beitrag stellt sie vor.

comments powered by Disqus

Ausgabe 07/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.