Ruby als Rückgrat
Das wird auch und vor allem in der Art und Weise deutlich, wie Cookbooks und Recipes in Chef implementiert sind. Praktisch alle Automatisierer setzen hier auf eine eigene deklarative Skriptsprache oder verwenden gleich JSON oder – wie im Beispiel von Ansible – YAML. Die deklarative Skriptsprache (DSL) von Puppet bietet den unschlagbaren Vorteil, dass Admins sie schnell verstehen, wenn sie in ihrem Leben zumindest schon mal Bash-Skripte verfasst haben – was wohl auf die meisten zutrifft. Chef hingegen geht einen anderen Weg, denn hier bildet Ruby das Rückgrat der gesamten Automation. Chef selbst ist zwar auch eine deklarative Skriptsprache auf Basis von Ruby – aber eine sehr dünne.

Das heißt letztlich auch, dass Cookbooks, die auf den Nodes der Umgebung bestimmte Dienste ausrollen sollen, ebenso in Ruby verfasst sein müssen wie Recipes und andere Metadaten für die Verwendung in Chef. Auch hier liegt einer der Gründe dafür, dass Chef sich am Markt nicht so durchsetzen konnte wie einst Puppet oder heute Ansible und Salt. Denn wer mit Chef gut und effizient automatisieren möchte, muss letztlich sattelfest in Ruby sein, was für viele Administratoren ein Problem darstellt.

Ruby zu lernen, ist natürlich keineswegs unmöglich. Vor dem Hintergrund sehr geschäftiger Arbeitstage weigern sich aber viele Administratoren schlicht, den Aufwand zu investieren, den Chef ihnen an dieser Stelle abverlangt – gerade auch, weil es potente Alternativen gibt.

Umfassender Community-Support
Den "Chef Supermarket" hat der Artikel zwar bereits erwähnt, doch ist es an dieser Stelle nötig, auf den Online-Speicher nochmal im Detail einzugehen. Denn der Supermarket enthält eine beeindruckende Menge fertiger Cookbooks für die meisten Einsatzbereiche. Für sämtliche Standardwerkzeuge auf allen Standardsystemen findet sich hier in der Regel eine fertig implementierte Automation. Und bei einzelnen Services ist nicht Schluss: Mittlerweile sind im Supermarket auch eine Vielzahl von Cookbooks verzeichnet, die das Bearbeiten von Ressourcen in Clouds ermöglichen. Direkt aus Chef heraus ist es so möglich, Ressourcen in AWS an den Start zu kriegen.

Schmückendes Beiwerk
Bevor sich dieser Artikel mit Chef Automate als Add-on zu Chef Infra beschäftigt, befassen wir uns mit den anderen Teilen des "Chef Enterprise Automation Stacks" – denn ohne zu wissen, was sonst noch zum Chef-Werkzeugkasten gehört, ergibt Chef Automate als losgelöste Komponente keinen Sinn. Der Stack besteht aus den Komponenten Chef Infra, Chef InSpec, Chef Habitat und schließlich Chef Automate. Natürlich hat der Hersteller sich als Ziel auf die Fahnen geschrieben, die einzelnen Teile seines Automationsstacks möglichst gut miteinander zu verzahnen. Wer genauer hinschaut, stellt jedoch fest: Jede der Komponenten im Chef-Universum hat eine konkrete Daseinsberechtigung, und die einzelnen Teile grenzen ihre eigenen Funktionen gut gegeneinander ab.

Chef Infra ist zwar Teil dieses Stacks, kam im Rahmen dieses Artikels aber bereits ausführlich zur Erwähnung. Das ist bei Chef Habitat sowie Chef InSpec anders. In Form von Chef Habitat etwa hat der Hersteller ein Produkt am Markt, das die enge Integration und Verzahnung mit CI/CD-Ansätzen ermöglicht.

Dazu ist etwas Hintergrundwissen hilfreich. Längst vertreten die  diversen Hersteller in Sachen Automatisierung die Auffassung, dass diese nicht mehr darauf beschränkt ist, einzelne Dienste auszurollen und sie mit einer Konfigurationsdatei zu versehen, um sie schließlich zu starten. Container und andere Deployment-Mechanismen treiben Admins hier seit Jahren vor sich her. Denn, so die Idee: Wer seine Anwendung gleich in Form eines Containers ausliefert, kann sie mit den passenden Konfigurationsdateien ab Werk versehen, sodass der Admin nur noch ein paar Variablen setzen muss, wenn er den jeweiligen Container startet.

Das befreit den Admin "en passant" auch von der gefürchteten Abhängigkeitshölle der gängigen Paketsysteme wie RPM oder Dpkg. Wenn jede Anwendung ihre eigene Userland-Umgebung mitbringt, gehören Abhängigkeiten der Vergangenheit an. Die großen Distributoren haben längst erkannt, dass dieses Betriebsmodell für sie viel nützlicher ist, weil es ihnen viel Arbeit erspart, wenn jede Anwendung auf jedem System laufen kann, solange es dort nur eine funktionale Laufzeitumgebung für Container gibt. Denn MariaDB etwa muss dann nur noch einen Container für MariaDB pflegen, der in Red Hat Enterprise Linux ebenso nutzbar ist wie in SUSE Linux Enterprise Server oder Ubuntu Linux. Dass jeder große Distributor heute eine "Core"-Distribution pflegt, die außer eines Kernels und einer Laufzeit für den Betrieb von Containern nicht viel enthält, sollte Admins jedenfalls zu denken geben.

Gefahr für Automatisierer
Für die gängigen Automatisierer ist das de facto eine Gefahr für das eigene Geschäft – denn wenn alle Welt Container nutzt, um Anwendungen auszurollen, gibt es für Chef, Puppet & Co. eigentlich keinen Bedarf mehr. Die grundlegende Systemkonfiguration lässt sich per Anaconda oder AutoYaST2 auch ohne ein zusätzliches Werkzeug auf das System bringen. Habitat ist Chefs Antwort auf die drohende eigene Bedeutungslosigkeit. Praktisch handelt es sich eher um ein Entwickler- denn Admin-Werkzeug, das mit Chef Infra, Chef InSpec sowie Chef Automate jedoch eng verzahnt ist.

Im Kern bietet Chef Habitat Admins und Entwicklern die Möglichkeit, eine komplexe, aber vollständige Pipeline für Continuous Integration und Continuous Delivery herzustellen – und dabei beschränkt es sich nicht auf Container. Die "Builder"-Komponente enthält dabei alle Informationen über die von Chef verwalteten Pakete und Container. Diese erzeugt es auf Basis der so genannten "Plans"; ein Plan beschreibt im Wesentlichen eine Anwendung und die Zielumgebung, in die hinein sie auf Basis eines Plans ausgerollt werden soll. Weiterhin stehen externe Trigger zur Verfügung. Verwaltet ein Unternehmen eine Anwendung etwa in GitHub, kann ein Git-Commit in das Repo dazu führen, dass Chef Habitat entlang der konfigurierten Build-Pipeline den Container oder das Paket neu erstellt und automatisch zum Download anbietet.

Die Entwickler selbst beschreiben Habitat als Werkzeug, um eine Anwendung und die für sie nötige Automation so zu koppeln, dass sie stets überall verfügbar sind. Mittlerweile bietet Habitat zudem die Möglichkeit, die automatisiert ausgerollten Anwendungen zentral zu betreiben. Wer also etwa eine Applikation in Form eines Docker-Containers erstellt, rollt diesen aus Habitat heraus automatisch in einer Wunschplattform aus und steuert dort auch den Lifecycle des neuen Containers. Wie bei Chef Infra und Chef Automate auch geht das mit einer recht steilen Lernkurve einher.

dr/ln/Martin Loschwitz

Im dritten Teil der Workshopserie schauen wir uns die Funktionsweise von Chef Automate im Detail an. Im ersten Teil gaben wir einen Überblick über das Chef-Portfolio und stellten die Unterschiede zu Puppet heraus.