Fällt der Begriff Automatisierung, sind hierzulande meist dieselben Begriffe und Schlagworte zu hören: Wer sich mit dem Thema schon länger beschäftigt, ist oft Verfechter von Puppet. Wer etwas weniger lange dabei ist, hat in der Regel mit Ansible angefangen. Und ab und zu findet sich hierzulande auch mal einen Verfechter von Chef – allerdings nicht annähernd so häufig wie die Fans der Konkurrenz. Das ist durchaus bemerkenswert: Chef gibt es deutlich länger als Ansible und es konnte frühzeitig Dinge, von denen bei Puppet noch gar nicht zu träumen war. Dass Chef hierzulande nicht so erfolgreich geworden ist wie Puppet oder Ansible, mag daran liegen, dass das Werkzeug seine kommerziellen Ursprünge in den USA hat und dort auch zuerst vermarktet worden ist.

Puppet hingegen war hierzulande frühzeitig kommerziell aktiv, auch weil seine Vertreter regelmäßig Konferenzen in ganz Europa beehrten. Und als Chef genug Momentum aufgebaut hatte, um auch in anderen Bereichen der Welt kommerziell erfolgreich zu werden, war bereits Ansible als unmittelbare Antwort auf die sehr komplex gewordenen Umgebungen Puppet und Chef im Anmarsch. Obgleich es aus Sicht von Red Hat nahegelegen hätte, sich Chef einzuverleiben, griffen sie lieber bei Ansible zu – wohl auch, weil sie sich von dem Tool versprachen, dass es besser zur eigenen Firmenstrategie passe oder sich zumindest besser an diese anpassen lassen.

Gerade weil Chef in Sachen Automation in Europa oft unter den Tisch fällt, stellt dieser Artikel Chef und das darauf basierte Chef Automate vor. Wir gehen auf die wichtigsten Funktionen ein, heben Alleinstellungsmerkale hervor und vermitteln so einen Überblick darüber, was Chef kann und was eben nicht. So viel sei schon jetzt verraten: Wer sich mit Automatisierung beschäftigt und auf der Suche nach einem passenden Tool für eine bestimmte Aufgabe ist, sollte Chef auch heute noch auf dem Radar haben, anstatt es von Anfang an auszuschließen.

Zurechtfinden im Chef-Portfolio
Immer wieder fallen im Laufe dieses Artikels die Begrifflichkeiten "Chef" sowie "Chef Automate" (oder einfach "Automate"). Das sorgt freilich für einige Verwirrung: Wenn Chef ein Automatisierer ist, was ist dann eigentlich Chef Automate? Auch ein Automatisierer? Eine Art Konkurrenzprodukt gar aus dem eigenen Hause – das übrigens ebenfalls schlicht "Chef" heißt? Nein, so stimmt das nicht. Der Kern und quasi die Urzelle des gesamten Sortiments der heutigen Firma "Chef" ist der gleichnamige Automatisierer "Chef Infra". "Chef Infra" hieß früher einfach nur "Chef", bis die Lösung anfing, sich in diverse weitere Komponenten auszudifferenzieren.

Chef Infra implementiert im Orchester der Chef-Werkzeuge das Prinzip Infrastructure-as-Code. Es ist eine komplette Automatisierungsumgebung, mit der sich von einem System aus auf anderen Systemen Ereignisse auslösen lassen, so wie jeder mit Automatisierung vertraute Admin es jeden Tag etliche Male erledigt. Obendrein erlaubt Chef Infra das automatische, zentrale Verwalten von Konfigurationsdateien auf Basis einer definierten Template-Sprache. Chef Infra steht unter einer freien Lizenz und ist quelloffene Software. Wenn von "Chef" die Rede ist, meinen die meisten Admins bis heute tatsächlich "Chef Infra", was stets für Verwirrung sorgt.

Die Klassifizierung als Open-Source-Software gilt für Chef Automate grundsätzlich auch. Trotzdem sieht der Hersteller Automate als einen Zusatz für Chef Infra in seinem Portfolio. Während nämlich Chef wie beschrieben das zugrundeliegende Automatisierungswerkzeug liefert, bietet Automate zusätzliche Funktionen wie eine automatisch abfragbare API, eine GUI sowie eine Brücke zu anderen Werkzeugen des Herstellers, die sich mit Chef klug verzahnen lassen. Der Artikel geht auf jene Werkzeuge am Ende noch im Detail ein.

Der Kern: Chef Infra
Wer sich mit Chef beschäftigt, beschäftigt sich im ersten Schritt idealerweise mit Chef Infra. Das ist die Keimzelle des gesamten Produkts, also jener Teil, der von Anfang an vorhanden war. Chef Infra selbst teilt sich in mehrere Teile auf. Der "Chef Server" bildet den Kern der Umgebung – er ist sowohl für Befehle aus Richtung des Administrators zuständig als auch die Anlaufstelle für Clients, die auf den Zielsystemen die Inhalte der Automation umsetzen. Damit ist auch klar: Chef folgt einem Server-Client-Prinzip, auf den Zielsystemen gibt es also Agenten, die "Chef Client" heißen. Die Zielsysteme heißen in Chef ganz banal "node", wobei eine Node beinahe alles sein kann: ein physischer Host, eine virtuelle Instanz, die API einer Cloud (etwa AWS), ein Netzwerkgerät und ganz grundsätzlich jede Form von Infrastruktur, die sich potenziell mit Chef befeuern lässt.

Das bedeutet freilich auch, dass für den Chef-Server diverse Voraussetzungen zu treffen sind. Einerseits sollte der Server redundant ausgelegt sein, sodass im Falle eines Falles die Automatisierung auch dann zur Verfügung steht, wenn Hardware aktuell kaputt ist – nämlich jene des Chef-Servers. Vor allem aber sollte der Server in Sachen Hardware gut bestückt sein, gerade in großen Umgebungen. Die Chef-Entwickler geben zwar an, dass bis etwa 10.000 Chef-Knoten ein halbwegs potenter Server mit Mehrkern-CPU und hinreichend viel RAM – etwa 128 GByte – ausreichen sollte. Wächst das Setup in größere Regionen, kann eine kleine Maschine allerdings zum Nadelöhr werden.

Chef funktioniert anders als Puppet
Dass sich die Hardware-Anforderungen des Chef-Servers zunächst in Grenzen halten, liegt auch an der Architektur von Chef. Was bei Puppet "Modul" und bei Ansible "Rolle" oder "Playbook" heißt, ist bei Chef "Cookbook" und "Recipe". Ein "Recipe", zu Deutsch also "Rezept", beschreibt, welche Cookbooks auf eine bestimmte Node anzuwenden sind. Die einzelnen Cookbooks enthalten dann die eigentlichen Anweisungen im Hinblick auf bestimmte Dienste. Will der Admin etwa auf einem CentOS-System den Zeitdienst "Chrony" als NTP-Ersatz ausrollen, braucht er dafür das passende Cookbook sowie ein Recipe, das Node und Cookbook logisch miteinander verknüpft.

Zu beachten ist, dass der Chef-Server zwar eine Bibliothek aller Cookbooks ("Bookshelf") enthält und diese verwaltet. Die Anweisungen, die ein Client bei sich lokal auf einer Node umsetzen soll, errechnet dieser sich anhand der Daten im Chef-Master jedoch selbst. Im Gegensatz dazu kompiliert Puppet im Server-Agent-Betrieb bekanntlich den gesamten Code, den der Client ausführen soll, was deutlich ressourcenintensiver ist. Diese Design-Schwäche haben die Chef-Entwickler also umgangen.

Stellt sich die Frage: Wie kommen die diversen Informationen, also die Cookbooks, die Recipes und die diversen anderen Metadaten auf den Server von Chef Infra? Hier kommen die "Chef Workstations" ins Spiel. Die sind normale Computer mit Clientprogrammen, die unmittelbar mit dem Chef-Server kommunizieren, etwa das Chef-CLI "chef". Auch der Zugriff auf den "Chef Supermarket" ist über die Chef-Workstation möglich; das ist ein Online-Store mit Cookbooks, die aus der Community stammen und von dieser entwickelt und gepflegt werden. Im Grunde ist der Begriff "Chef Workstation" etwas irreführend, denn diese Rolle kann jede Maschine innehaben, auf der der Admin die Chef-Werkzeuge installiert und die Credentials für den Zugang zum Chef-Server hinterlegt. Workstations kann es folglich viele gleichzeitig geben, völlig unabhängig voneinander.

Viele Tools auf den Workstations
Neben dem "chef"-CLI findet der Administrator auf einer Chef-Workstation eine Reihe zusätzlicher Werkzeuge. "knife" ist so etwas wie der direkte Draht des Admins zu einem spezifischen Knoten – soll das Verhalten oder die Konfiguration eines einzelnen Systems geändert werden, geht das entweder per Recipe und Cookbook oder auf dem kleinen Dienstweg mittels "knife". "chef-run" stößt in dasselbe Horn und ermöglicht es, auf einzelnen Nodes unabhängig vom "chef-client" den Inhalt von Cookbooks auszuführen.

Um dem Admin das Leben zu erleichtern, kommen die Chef-Workstations übrigens mit einem eigenen Werkzeug daher, das die Chef-Tools auf dem jeweiligen System stets aktuell hält. In Summe ist es daher weder schwierig, den Chef-Server aufzusetzen, noch eine Chef-Workstation an den Start zu kriegen. Administratoren sollten sich trotzdem darüber im Klaren sein, dass Chef mächtig ist – und mithin komplex.

dr/ln/Martin Loschwitz

Im zweiten Teil der Workshopserie geht es um die einzelnen Teile des "Chef Enterprise Automation Stacks". Einen genaueren Blick werfen wir dabei auf Chef Habitat.