© mch67, 123RF

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.

Mit dem Wandel zur Cloud ging auch eine Veränderung im Design moderner IT-Lösungen in Unternehmen einher. Plante man früher eher kleine und überschaubare Setups, ist mittlerweile das große Ganze in den Mittelpunkt des Interesses gerückt: Setups aus Dutzenden Knoten, die aber administrativ wie eine wohlintegrierte Einheit funktionieren sollen.

Marionette und Chefkoch helfen beim Automatisieren

Eine Schlüsselrolle kommt dabei der Automatisierung zu. Bevor Admins wiederholt ein wenig Zeit investieren, um identische Aufgaben abzuarbeiten, investieren sie lieber einmal viel Zeit in deren später zeitsparende Automatisierung. Diese Ersparnis lässt sich in die Entwicklung neuer Funktionen stecken – auch das fällt unter den Begriff Devops.

In Sachen Konfigurationsmanagement von elementarer Bedeutung ist im Open-Source-Umfeld Software wie Puppet [1] und Chef [2] – Werkzeuge, die Admins bei der flächendeckenden, automatischen Administration von Servern gekonnt unterstützen. Die Tools stehen in direkter Konkurrenz zueinander [3]. Wer mindestens eine der Lösungen konsequent und richtig anwendet, erleichtert sich den Alltag signifikant.

Doch gibt es auch mehr als genug Fallstricke. Das fängt schon bei der Frage an, welche der beiden Lösungen Admins für ihr Setup wählen sollten, setzt sich bei grundlegenden Fragen bezüglich der Konfiguration fort und endet bei einigen unliebsamen Überraschungen, denen sich Chef- und Puppet-Admins gelegentlich ausgesetzt sehen.

Dieser Artikel ist eine Art Bestandsaufnahme: Er geht von den Erfahrungswerten des Autors aus und beleuchtet Fragen, die den praktischen Betrieb von Chef oder Puppet betreffen. Darüber hinaus beleuchtet er die Probleme, in die Admins verwickelt werden, wenn sie eine der Lösungen nutzen.

Am Anfang steht der bekannte Grundsatz: Drum prüfe, wer sich ewig bindet. Im Netz finden sich zahllose Vergleiche von Puppet und Chef [4], je nach Quelle gewinnt mal die eine, mal die andere Lösung. Für Administratoren, die vor der Einführung von Puppet oder Chef stehen, ist das ein quälender Zustand, denn eine Empfehlung für oder wider lässt sich pauschal nicht aussprechen, letztlich entscheidet die Abwägung im Einzelfall.

Deklarativ oder imperativ?

Vergessen wird dabei in schöner Regelmäßigkeit allerdings der Faktor der deklarativen Sprache. Das aber bezeichnet einen der Kernunterschiede zwischen Puppet und Chef: Denn während Chef im Wesentlichen imperativ arbeitet, ist Puppet deklarativ.

Ganz konkret bedeutet das: Bei Chef legt der Admin in entsprechender Reihenfolge im Cookbook fest, welche Befehle in welcher Reihenfolge wie abzuarbeiten sind. Im Puppet-Beispiel ist es stattdessen notwendig, einen gewünschen Zustand mittels Puppet-Manifest zu beschreiben und dann die Arbeitsschritte zu definieren, die zu diesem Zustand führen.

Ressourcen lassen sich über Abhängigkeiten verbinden. So bedeutet ein einzelner fehlerhafter Lauf des Puppet-Agenten auf einem System nicht zwangsläufig, dass der Knoten unerreichbar ist. Um Abhängigkeiten – auch über die Grenzen von Hosts hinweg – zu erfüllen, kann es nötig sein, mehrere Puppet-Aufrufe auf einem Host zu starten.

Letztlich hinterlässt der Puppet-Agent ein System stets konsistent, das kann aber durchaus bedeuten, dass nicht alle vorgesehenen Arbeitsschritte auf dem Host auch tatsächlich durchgeführt wurden. Wer als Admin eher die Arbeit mit Shellskripten gewohnt war, muss sich bei Puppet umstellen.

Ein Design-Unterschied dieser Größe ist zwar nur selten der entscheidende Grund für oder gegen Puppet oder Chef, doch trägt es zur Akzeptanz der Lösung auch innerhalb des Admin-Teams maßgeblich bei, wenn die Mitglieder des Teams sich nicht völlig umgewöhnen müssen. Und nach der Einführung einer der Lösungen ist es nicht ohne Weiteres möglich, auf eine andere umzusteigen; eine sorgfältige Evaluierung der Möglichkeiten bereits im Vorfeld ist also auf jeden Fall notwendig.

Das typische Setup

Ist die Wahl auf ein Werkzeug gefallen, bedeutet das aber keineswegs, dass die Sorgen des Admin bereits gelöst sind, vielmehr geht die eigentliche Planung des Setups damit erst richtig los. Das Thema Ressourcen spielt dabei sowohl für Puppet als auch für Chef eine übergeordnete Rolle. Denn so einfach die Aufgaben, die Puppet und Chef wahrzunehmen haben, auf den ersten Blick auch wirken – beide Werkzeuge genehmigen sich für ihre Arbeit einen kräftigen Schluck aus der Ressourcen-Pulle – wie das folgende Beispiel zeigt.

Ein typisches Puppet-Setup geht von einem zentralen Server aus, der seine umliegenden Hosts im Stile von Satelliten mit Daten versorgt. Der Host heißt dann auch Puppet Master Server; an ihn wenden sich alle Agents auf den Rechnern, um Informationen über ihre eigene Konfiguration zu erhalten.

Um zu verstehen, wieso ein solcher Puppet Master Server unter Umständen zum Nadelöhr werden kann, ist ein kleiner Exkurs in die Puppet-Interna notwendig. Wer dem Puppet-Agent schon mal bei der Arbeit zugesehen hat, dem wird die Logzeile mit »Fetching Service Catalog« aufgefallen sein. Der Service Catalog ist im Grunde ein Verzeichnis aller Ressourcen, die durch Puppet auf dem jeweiligen Host zu verwalten sind.

Eine Ressource wiederum ist jeder einzelne Dienst, ob es sich dabei um eine zu installierende Konfigurationsdatei oder einen Dienst handelt, der speziell zu starten ist. Der Teufel steckt wieder mal im Detail, denn seinen Service Catalog generiert sich der Agent auf dem Zielserver nicht selbst. Erst erledigt das der Master-Server, dann lädt sich der Client den Katalog und arbeitet die Liste der Ressourcen ab.

In kleineren Installationen ist das kein Problem, denn hier verteilen sich die Anfragen der Puppet-Agents auf viel Zeit, die einzelnen Kataloge werden selbst bei entsprechender Größe nur wenig Last auf dem Master-Server verursachen. Die Master-Server größerer Setups fangen unter der Last vieler gleichzeitiger Anfragen aber schnell an zu stöhnen (Abbildung 1) – und zwar so schlimm, dass einzelne Clients häufig ihren Katalog gar nicht mehr herunterladen können, wenn gerade andere Clients ebenfalls Aufrufe des Puppet-Agenten laufen haben.

Abbildung 1: Bei Puppet entsteht ein großer Teil der Last auf dem Puppet-Server, weil dort die auszuführenden Arbeitsschritte als Katalog kompiliert und dann zusammen an den Client geschickt werden.

Lösungsvariante 1 sieht vor, den Puppet Master Server mit mehr Hardware zu bestücken. Viel CPU, ordentliche Mengen an RAM und eine SSD helfen dabei, den Nadelöhr-Effekt des Masters etwas abzumildern. Wer Chef nutzt, hat Glück, denn Chef ist konzeptionell völlig anders konstruiert: Hier generieren sich die Clients ihre Konfiguration gleich selbst, und zwar auch dann, wenn ein zentraler Chef-Server zum Einsatz kommt.

Problematisch: Master-less

Als Lösungsvariante 2 für Puppet kommt es in Frage, ein “Master-less Setup” zu bauen, das ganz ohne Master-Server auskommt. Der Vorteil ist, dass es logischerweise keine Zentralinstanz mehr gibt, die Performanceprobleme produziert. Doch ist dieser Ansatz mit einem dicken Sicherheitsproblem behaftet: Jeder Server speichert alle Teile der Puppet-Konfiguration, die ihn betreffen – unter Umständen also auch die Definitionen anderer Server, sicherheitstechnisch ein echter Alptraum.

Vernünftigerweise hat es sich in den letzten Jahren in der IT eingebürgert, Passwörter nicht im Klartext in Dateien zu speichern. Bei Puppet ist das in der Standardvariante aber gar nicht anders möglich; selbst Passwörter, die innerhalb von Puppet über das Facter-Framework [5] hinterlegt werden, sind unverschlüsselt gespeichert. Wer ein Puppet-Setup ohne Master betreibt, muss aber alle Konfigurationsdateien auch auf den Hosts haben, sodass sich auch dort fast alle Konfigurationsdateien finden werden. Für Einbrecher ist das ein Glücksfall: Wer eine Box knackt, erbeutet verschiedene Passwörter für viele verschiedene Dienste und kann sich so innerhalb des Netzwerks fast nach Belieben herumtreiben.

Chef litt bis vor einigen Versionen an einem ähnlichen Problem, mittlerweile ermöglichen es aber die Encrypted Data Bags [6], Informationen auf Server-Seite verschlüsselt abzulegen. Wer dagegen Puppet einsetzt, muss sich hier mit 3rd-Party-Software behelfen. Um die Daten ordentlich vor den Augen anderer zu schützen, braucht es Hiera und die Hiera-Erweiterung »hiera-eyaml« [7] von Tom Poulton.

Das allerdings beschreibt bereits ein spezifisches Puppet-Setup, das in den meisten Unternehmen weder vorhanden noch ohne gröbere Umbaumaßnahmen einzuführen sein dürfte. Wer ein klassisches Puppet ohne Hiera betreibt, steht in Sachen Verschlüsselung vorerst im Regen. Bei masterlosen Puppet-Setups gilt es insofern besonders, die betroffenen Systeme vor den Augen Unbefugter zu schützen.

Rollback

Puppet und Chef verfolgen ganz eigene Ansätze, wenn es um ein Rollback ausgeführter Handlungen geht. Bei Chef ist die Sache klar: Weil ja ein Cookbook im Wesentlichen eine Ansammlung von Befehlen ist, lässt sich logischerweise für jede Funktion auch eine Gegenfunktion definieren. Die Ruby-Extension von Chef sieht dafür auch eine eigene Syntax vor, die auf [8] erklärt ist.

Beherrscht ein Cookbook den Rollback-Parameter, lässt es sich so aufrufen, dass es bereits durchgeführte Änderungen rückgängig macht und einen vorherigen Zustand wiederherstellt. Viele Chef-Cookbooks nutzen diesen Rollback-Parameter bereits jetzt.

Idealvorstellung

Bei Puppet ist die Sache etwas komplizierter. Denn durch die schon genannte deklarative Art der Hostkonfiguration definiert Puppet ein Setup immer nur von dem gewünschten Zustand her; was wiederum dazu führt, dass Puppet im Anschluss an einen Aufruf auf einem System keine Ahnung mehr davon hat, wie der vorherige Zustand aussah, sondern nur noch weiß, wie der aktuelle Zustand sein soll.

Das bringt schwerwiegende Konsequenzen mit sich: Ein brauchbares Rollback ist mit Puppet im Grunde unmöglich. Um Konfigurationsänderungen ungeschehen zu machen, obliegt es dem Admin selbst, den gewünschten alten Zustand in Form eines Manifests in Puppet zu hinterlegen und es dann auf die betroffenen Hosts anzuwenden. Das kann im Extremfall zur kniffeligen Aufgabe werden: Überschreibt Puppet während eines Aufrufs Dateien, legt es nirgendwo ein Backup davon an. Das sollten Admins also jedenfalls händisch und vor dem Puppet-Deployment erledigen. Überdies ist es mittlerweile zur Best Practice geworden, eventuelle Änderungen erst mal durch eine Staging-Installation zu schicken, bevor sie ins wirkliche Leben starten.

Schreckliche Updates

Letzter und größter Stolperstein, der in diesem Artikel nicht fehlen darf, ist das Update von Komponenten, die zu einer automatisierten Installation gehören. Auf Puppet- wie auch auf Chef-Seite sind das zunächst offenkundig die fest verdrahteten Teile. Da hat besonders Chef bei Admins einen bleibenden Eindruck hinterlassen – keinen guten. Immer wieder kam es im Rahmen von Chef-Updates während der vergangenen Jahre zu Änderungen beim Chef-Server, die die Kompatibilität mit vorherigen Versionen beeinträchtigten. Schlimmstenfalls sitzt der Admin dann mit Schweißperlen auf der Stirn vor einem toten Server und fragt sich, was er jetzt tun soll.

Von Problemen beim Server- und Client-Upgrade blieb Puppet zwar bis jetzt weitestgehend verschont, doch das bedeutet keineswegs, dass beim Upgrade von Systemkomponenten nicht auch hier die Funken sprühen. Meist sind es bei Puppet nicht die Puppet-Komponenten selbst, die Ärger machen, sondern die Module aus dem Internet. Die unterliegen in der Regel nur einer Qualitätskontrolle durch ihre eigenen Autoren. Was der Benutzer sich als Zusatzmodul von Puppetforge installiert, ist daher vorsichtshalber als ungetestet zu betrachten (Abbildung 2).

Abbildung 2: Puppet-Module wie dieses für Open Stack Neutron unterliegen im Wesentlichen nur der Kontrolle der Entwickler. Bei Upgrades kann das zu ernsten Problemen führen.

Das Gleiche gilt für Updates, besonders wenn es sich um eher umfangreiche handelt: Die Puppet-Module für Open Stack geben Zeugnis von der Katastrophe, in die Admins schlimmstensfalls schlittern. Das Update von Open-Stack-Version Havana auf Icehouse brachte beispielsweise so viele neue Funktionen und Inkompatibilitäten mit, dass Manifeste für den Vorgänger praktisch unbrauchbar waren. Kombiniert mit den fehlenden Rollback-Mechanismen in Puppet erzwingt diese Art des Setups ein entsprechendes Staging-System, in dem Admins neue Module oder an die Situation angepasste Konfigurationen erproben können.

Qualität externer Module

Übrigens: Sowohl für Puppet als auch für Chef gilt, dass die Qualität so manches externen Moduls zu wünschen übrig lässt, und das nicht nur im Falle von Updates. Puppet-Nutzer erleben das immer wieder, wenn es darum geht, ein aus dem Internet stammendes Modul in einen der External Node Classifier zu integrieren; gemeint sind Front-Ends wie Foreman [9], das Puppet-Dashboard oder in letzter Zeit vermehrt das angesprochene Hiera.

Die UIs funktionieren sehr ähnlich: Über Klassen weisen Admins ihre Hosts einzelnen Funktionen zu. Aber damit das Prinzip im Ansatz funktioniert, müssen alle wesentlichen Funktionen eines Puppet-Moduls tatsächlich auch als Klasse verfügbar sein. Viele Puppet-Module gehen im Gegensatz dazu davon aus, dass die Hostkonfiguration über ein Site-Manifest (»site.pp« ) festgelegt ist, in dem sich Funktionen für Hosts unmittelbar aufrufen lassen – eine Funktion, die den grafischen Front-Ends aber meist fehlt (Abbildung 3).

Abbildung 3: Gelegentlich passiert es bei Puppet-Modulen oder Chef-Cookbooks auch, dass ganze Klassen oder Groups wegfallen – sehr zum Kummer der Admins bei Upgrades.

So kann es passieren, dass sich die Freude über ein gerade ausgegrabenes Puppet-Modul schnell in Frust verwandelt, gerade weil es ohne Wrapper-Klassen für seine Funktionen daherkommt. Im Zweifelsfalle lassen sich jene Wrapper über ein paar Edits übrigens leicht nachrüsten, ein Idealszenario ist das dennoch nicht. Bei Chef ist die Qualitätsstreuung überdies ähnlich hoch wie bei Puppet (Abbildung 4), auch wenn es viele US-Unternehmen gibt, die Chef eher mit Cookbooks unterstützen als Puppet mit Modulen.

Abbildung 4: Chef bietet keineswegs weniger Fallstricke als Puppet, aber es sind andere als die der Konkurrenz.

Fazit

Nicht jeder, der Chef oder Puppet einsetzt, befolgt automatisch Devops-Prinzipien. Doch ist ein weitgehend automatisiertes Setup dafür ein wichtiger Schritt. Der aber wartet manchmal mit ganz eigenen, bisweilen sehr spezifischen Problemen auf. Keiner der beiden Platzhirsche beim Konfigurationsmanagement mit Open-Source-Tools, ob Chef oder Puppet, taugt derzeit als universelles Allheilmittel – der Administrator ist immer noch gefordert, sowohl bei der Planung als auch im Alltag. Aber dann helfen beide Lösungen zweifellos dabei, Arbeitsschritte einzusparen.