Open Source im professionellen Einsatz
Linux-Magazin 09/2014
© mch67, 123RF

© mch67, 123RF

Womit Admins bei Chef und Puppet rechnen müssen

Ferngesteuert

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.

596

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 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

  • Puppet vs. Ansible

    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.

  • 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.

  • Foreman

    Orchestrierungstools wie Chef, Puppet und Saltstack helfen sehr bei der einheitlichen Administration einer Systemlandschaft, aber sie erledigen nicht alles. Foreman ergänzt die Lücken und setzt allem eine einheitliche Oberfläche auf, die dem Admin das Leben ein ganzes Stück einfacher macht.

  • Puppenspiel

    Puppet erhebt den Anspruch, die nächste Generation an Konfigurationswerkzeugen zu repräsentieren. Es bietet eine Sprache, um Konfigurationen unabhängig vom verwendeten Betriebssystem zu beschreiben.

  • Puppet-Konfigurationsmanagement als Enterprise-Variante erhältlich

    In der Enterprise-Version vereinfacht sich vor allem die Installation des Pakets.

comments powered by Disqus

Ausgabe 11/2017

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

Stellenmarkt

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