© ktsdesign, 123RF

Chef gehört zu den ältesten Automatisierungslösungen. Die neue Version 2.0 will sich zum universellen Administrationsroboter auch für Cloudumgebungen mausern. Das Linux-Magazin stellt sie auf den Prüfstand.

Seit Ansible und Saltstack in den Fokus der großen Distributoren rücken und ganze Open-Stack- und Ceph-Setups problemlos selbstständig auf die Beine stellen, gelten diese beiden Lösungen als heiße Themen in Sachen Automation. Vor ein paar Jahren war das noch anders: Von beiden war noch nicht die Rede, stattdessen buhlten damals Puppet und Chef um die Gunst der Admins.

Sind die nun heute bereits Geschichte? Weit gefehlt: Puppet und Chef erfreuen sich nach wie vor einer großen Fangemeinde und beide Tools werden auch nach wie vor aktiv weiterentwickelt. Davon zeugt etwa die neue Version 2.0 von Chef Automate, die im Mai 2018 im Rahmen der Chef-Konferenz offiziell ihre Premiere vor Publikum feierte.

Wie üblich geizt der Hersteller nicht mit Versprechungen: Chef Automate 2.0 macht alles viel besser, viel schneller, viel bequemer und natürlich auch noch viel automatischer als seine Vorgänger. Das Linux-Magazin hat die Neuerungen in Version 2.0 von Chef Automate unter die Lupe genommen.

Was Chef Automate ist

Vielen Admins dürfte Chef in der einen oder anderen Form bereits begegnet sein, und die meisten denken intuitiv an Chef selbst, also jenes Tool, das für die Automation zuständig ist. Tatsächlich ist Chef bis heute der Kern der Lösung – doch Chef Automate umfasst deutlich mehr Komponenten.

Das Mitte 2016 erstmals vorgestellte Werkzeug sollte den App-Automatisierer um verschiedene Funktionen erweitern; entsprechend optimistisch spricht auch der Hersteller von einer Plattform, die Continuous Automation ermöglicht. Die augenfällige sprachliche Nähe hin zu Continuous Integration und Continuous Delivery ist dabei kein Zufall.

Drei Werkzeuge gehören mittlerweile zu Automate. Alle sind Open-Source-Software und tun prinzipiell auch unabhängig voneinander ihren Dienst: Zum Automatisierer Chef selbst kommt Inspec, ein dereinst von einer deutschen Firma gebautes Werkzeug, um Compliance-Maßnahmen auf Systemen automatisiert zu überprüfen. Außerdem umfasst Automate auch Habitat, das ist ein CI/CD-Framework, mit dem Entwickler ihre Applikationen vollständig automatisiert entwickeln, bauen und verteilen können. So ergibt sich eine komplette Automations-Toolchain.

In Version 2.0 kommt noch eine Komponente hinzu, nämlich Chef Workstation – sie soll viele Funktionen der großen Lösung Chef auf den lokalen Rechner bringen und damit Entwicklern wie Admins das Leben erleichtern.

Neben diesen Komponenten halten verschiedene Dashboards und Analyse-Werkzeuge als Kleber alles zusammen. Sie bereiten den Zustand der gesamten Umgebung grafisch auf und zeigen dem Admin auf einen Blick, was los ist. Bemerkenswerterweise ist dieser Kleber das, was Automate von der simplen Kombination der drei zuvor beschriebenen Komponenten abhebt. Und gerade jener Teil ist es, der in Chef 2.0 einen fundamentalen Umbau erlebt.

Dafür gibt es klare Gründe. Laut eigener Aussage ist Chef als Firma eine interessante Diskrepanz aufgefallen: Wer heute sich mit Devops beschäftigt, hat meist ein gesteigertes Interesse daran, neue Features und Funktionen schnellstmöglich in Produktion zu bringen.

Letztlich ist ja gerade das eines der zentralen Versprechen von Devops überhaupt: Statt über Wochen und Monate eine neue Funktion im stillen Kämmerlein zu entwickeln, die dann als große Release samt entsprechenden Querelen ausgerollt wird, folgt man dem Prinzip der Trippelschritte und rollt Features in Produktion aus, sobald sie verfügbar und getestet sind. Viele Unternehmen, die sich dem Thema Devops zuwenden, haben vorrangig dieses Ziel.

Dass zwischen Theorie und Praxis viel Interpretationsspielraum ist, zeigt sich in den IT-Abteilungen täglich aufs Neue. Denn vom hehren Ziel der schnellen Releases bleibt in der Devops-Praxis oft nicht so viel übrig. Am Ende steht ein Betriebsmodus, der zwar bestimmte agile Komponenten hat, in weiten Teilen aber doch nicht jene Flexibilität bietet, die man sich bei der Einführung erhoffte. Und Chef untermauert diese Behauptung mit konkreten Zahlen, nach denen mehr als 50 Prozent der Firmen, die Devops-Prinzipien eingeführt haben, enttäuscht von den Resultaten sind.

Vom System zur App

Chef führt das zum Teil auf die Toolchains zurück, die die Unternehmen für ihre Projekte verwenden. Gerade bei Chef lohnt es sich, im Hinblick auf dieses Thema vor der eigenen Haustür zu kehren: Der Automatisierer Chef existiert zwar bereits seit neun Jahren und leistet gute Dienste. Bisher – und daran hat auch Chef Automate vor zwei Jahren nichts geändert – ging Chef aber stets vom System als kleinster zu pflegenden Einheit aus. Die Dashboards etwa, die in Chef Automate zur Verfügung standen, gaben Auskunft über den Zustand einzelner Systeme. Nicht möglich war es hingegen, das Ausrollen von einzelnen Applikationen zu überwachen.

Sonderlich gut mit anderen Lösungen aus dem CI/CD-Umfeld war Chef Automate auch nicht verwoben – klare Vorteile waren jedenfalls nicht auszumachen. Das hat zum Teil historische Gründe: Als die Chef-Entwicklung vor etlichen Jahren begann, lag der Fokus der Maintainer darauf, eine Automationslösung für jene lästigen Alltagsaufgaben der Systemadministration zu finden, die bis zum damaligen Zeitpunkt massenweise händisch oder durch zusammengestückelte Skripte erledigt worden waren.

Die Idee, dass Automatisierer im CI/CD-Kontext eine Rolle spielen könnten, entwickelte sich erst in dem Augenblick, als mit dem Aufkommen von Docker & Co. Container in den Mittelpunkt des Interesses rückten. Denn in solchen Szenarien muss man die Applikation eigentlich nicht mehr per Automatisierer ausrollen. Stattdessen kann man den Automatisierer nutzen, um die Applikation gleich passend als Container zu provisionieren. Doch eben hierbei war mit Chef bisher kein Blumentopf zu gewinnen – in Version 2.0 der Software soll das ausdrücklich anders werden.

Komplette Umgestaltung

Chef Automate 2.0 deklarieren seine Entwickler als “vollständig neu geschrieben”. Anders als zuvor kommt nun Go zum Einsatz, und das ist nicht die einzige tiefgreifende Veränderung: Im Unterschied zu früher setzt Chef Automate 2.0 nun selbst auf eine Mikro-Architektur, bei der mehrere Komponenten zusammenspielen.

Im Klartext bedeutet das: Die einzelnen Komponenten von Chef Automate 2.0 sind nun im besten Cloudstil API-Schnittstellen nach dem REST-Prinzip, die sich von außen über standardisierte Protokolle ansteuern lassen. Gleichzeitig stülpt Chef seinen verschiedenen Automate-Komponenten eine Unified Control Plane über: Unter einer einheitlichen Oberfläche soll der Admin künftig alle Abläufe kontrollieren.

Die Zahlen, mit denen Chef in diesem Kontext hantiert, lesen sich durchaus beeindruckend: Mehrere Zehntausend Knoten soll Chef Automate 2.0 steuern und bearbeiten können – wobei es künftig komplett irrelevant sein wird, wo diese laufen: Ob echtes Blech oder VMs in einer Public Cloud – Chef Automate 2.0 versteht sich auf den Umgang mit sämtlichen Layouts.

Komplett neu entworfen haben die Chef-Entwickler die Schnittstelle, welche die meisten Nutzer für ihre tägliche Arbeit mit Automate 2.0 nutzen dürften: Das Webinterface (Abbildung 1), über das sie Chef Automate steuern. Hier verrät dem Admin eine Art Newsticker schnell und übersichtlich, welche Aktionen in der Plattform gerade stattfinden – geht etwas schief, erscheint hier auch eine deutliche Warnung. Trending-Graphen und eine eigene Query-Sprache gehören in Automate 2.0 ebenfalls zum Lieferumfang.

Abbildung 1: Runderneuert präsentiert sich das GUI von Chef Automate 2.0 – aber die Änderungen unter der Haube sind ebenso massiv.

Hinzu kommen in Chef Automate 2.0 diverse Compliance-Funktionen, auf die der Artikel später noch eingeht. Der Hersteller folgt hier dem Mantra “Detect, Correct, Automate” – künftig soll Chef Automate unter einer einheitlichen Oberfläche Compliance-Verstöße so früh wie möglich erkennen helfen. Auch das gehört zum Control-Plane-Ansatz.

Applikationen im Vordergrund

Wer sich Chef Automate 2.0 anschaut, muss eigentlich aus zwei unterschiedlichen Perspektiven an die Sache herangehen. Einerseits die diversen schon beschriebenen Änderungen in der Architektur, allen voran der Umstieg auf REST-APIs. Andererseits die Frage, die sich vor diesem Hintergrund stellt: Was soll das? Hier gibt der Hersteller eine klare Antwort: War Chef Automate bisher ein Tool für das Managen großer Serverfarmen, rückt in Version 2.0 die Applikation in den Mittelpunkt.

Durch die offenen, klar definierten APIs lässt sich Chef Automate künftig etwa deutlich besser an externe Dienste wie Jenkins oder Github anbinden. Wer also beispielsweise Code in Github pusht, kann in Chef Automate 2.0 angeben, dass es aus diesem automatisch neue Container-Abbilder baut, die sich bei Bedarf sogar automatisch ausrollen lassen. Lifecycle-Management geht also deutlich über die Grenzen des Betriebssystems hinaus, das in bisherigen Versionen von Chef Automate die logische Grenze der Chef-Zuständigkeit war.

Gleichzeitig haben die Entwickler Chef Automate auch fit für den Umgang mit Cloudumgebungen gemacht, allen voran für die Platzhirsche AWS, Azure sowie Googles GCP.

Chef Workstation

Da passt es ins Bild, dass Chef Automate 2.0 auch erstmals ein Produkt namens Chef Workstation einführt. Wer bisher Chef Automate nutzen wollte, fing in der Regel mit dem Setup eines Chef-Servers an, eines eigenen Stücks Hardware also, dessen einzige Aufgabe darin bestand, Masterinstanz für die vielen Clients des Setups zu sein. Obendrein war es notwendig, den Client für Chef auf den Zielsystemen auszurollen, denn Chef basiert auf dem Prinzip der Server-Agent-Kommunikation. Das ganze Brimborium setzt einiges an Planung voraus und dauert eine ganze Weile.

Chef Workstation macht damit Schluss: Die Lösung ist eine Art Mini-Chef-Server mit allen notwendigen Werkzeugen, der sich auf dem lokalen System des Administrators ausrollen lässt. Chef Target hat dabei das Zeug zur Revolution: Bisher setzte Chef schließlich fest darauf, dass auf den Zielsystemen der bereits beschriebene Chef-Agent lief.

Eben diesen ersetzt »chef-target« jedoch. Solange der Admin irgendeine Möglichkeit hat, sich mit seinen Zielsystemen etwa per SSH direkt zu verbinden, kann er auf diesen unmittelbar Chef-Code ausführen. Ein Hauch von Ansible weht an dieser Stelle, was manchen eingefleischten Chef-Admin durchaus verwirren dürfte.

Am Ende zahlt sich die Mühe allerdings aus: Wer Chef ausprobieren möchte oder auf der Suche nach einer schnellen Variante ist, um Chef in einem kleinen Setup auszurollen, kommt mit der Workstation schnell ans Ziel. Und mehr noch: Systeme, die per Chef Workstation ausgerollt worden sind, lassen sich danach problemlos unter die Fittiche von Chef Automate nehmen. Damit richtet sich das Tool vorrangig an Devops-Entwickler, die eine entsprechende Umgebung aufsetzen und später in den regulären Betrieb übernehmen wollen.

Compliance im Blick

Seit einiger Zeit legt man im Hause Chef den Fokus verstärkt auf Compliance. Gerade in großen Unternehmen ist das wichtig: Hier finden Admins oft ein starres Regelwerk vor, das teils auf öffentlichen Standards, teils auf hauseigenen Vorschriften beruht.

Automation bietet allerdings ein sehr gutes Sprungbrett, um Compliance nicht nur nachträglich zu aktivieren, sondern sie zum integralen Bestandteil des gesamten Deployment-Szenarios zu machen, sei es bei der Wartung physischer Maschinen oder beim Ausrollen von Applikationen in Form von Containern. Nicht zuletzt deshalb dürfte Chef sich Inspec einverleibt haben, ein ursprünglich von der deutschen Firma Vulcanosec gebautes Werkzeug, um die Einhaltung von Compliance-Standards automatisiert zu überwachen.

Inspec war im Linux-Magazin in früheren Versionen bereits Thema [1] und hat unter Beweis gestellt, dass es ausgesprochen mächtig ist. Dabei ist es gar nicht sonderlich kompliziert: Auf Basis einer speziellen Syntax definiert der Admin Kriterien, die auf einem System erfüllt sein müssen. Gleichzeitig weist er in seiner Inspec-Konfiguration Punktwerte für Abweichungen vom Standard zu. Im Anschluss prüft Inspec automatisch, ob die Bedingung erfüllt ist, und schlägt Alarm, falls ein bestimmter Punktwert überschritten ist (Abbildung 2).

Abbildung 2: Inspec spielt in Automate 2.0 eine wichtige Rolle – Admins und auch Entwickler überprüfen mit dem Tool ihre Compliance-Konformität.

Chef verleibte sich Inspec seinerzeit ein, weil Inspec sich hervorragend als Ergänzung zu einer kompletten Automationslösung wie Chef Automate nutzen lässt. Das Ziel ist dabei klar: Compliance-Verstöße und Sicherheitsprobleme sollen bereits auf der Ebene der Automationslösung abgefangen werden, noch bevor diese auf den produktiven Systemen ausgerollt werden. Checkt ein Admin also etwa eine Konfigurationsdatei oder Code in ein Git-Verzeichnis ein, der gegen geltende Compliance-Regeln verstößt, weigert sich Chef Automate kurzerhand, mit dem Rollout zu beginnen.

Gleichzeitig überwacht Inspec auch die laufenden Systeme: Nimmt ein administrativer Einfaltspinsel etwa auf einem Server eine manuelle Änderung der Konfiguration vor, die das System möglicherweise Sicherheitsrisiken aussetzt, geht im Chef-Automate-Dashboard das rote Lämpchen an (Abbildung 3).

Abbildung 3: Wer einen entsprechenden Schatz an Inspec-Tests aufgebaut hat, kann seine Systeme umfassend im Hinblick auf Compliance überwachen.

Compliance für die Cloud

In Chef Automate 2.0 haben die Chef-Entwickler das Zusammenspiel ihrer Plattform mit Inspec kontinuierlich ausgebaut. Die wohl größte Änderung besteht darin, dass Inspec nun auch Cloudumgebungen sowie die vom Admin vorgenommene Konfiguration auf Compliance-Probleme hin untersuchen kann. Bisher ließen sich mit Inspec nur lokale Systeme testen, nun bietet der Dienst jedoch eine Konfigurationsoption für die Zugangsdaten zu AWS oder Azure.

Trägt der Admin diese Zugangsdaten ein, loggt sich Inspec direkt in der Public Cloud ein und untersucht die vorgefundene Umgebung anhand der definierten Compliance-Kriterien. Ebenfalls vorhanden sind entsprechende Funktionen für Googles Compute Platform (GCP), die in der aktuellen Inspec-Version aber noch als Betastatus geführt werden.

Zugleich haben die Inspec-Entwickler den Funktionsumfang der Lösung in erheblichem Umfang erweitert. Als Ressource bezeichnen sie eine Art fertigen Check in Inspec, der verschiedene Kriterien überprüft, etwa die Konfiguration des Apache-Webservers. Über 30 neue Ressourcen sind in Chef Automate 2.0 für Inspec hinzugekommen, etwa Unterstützung für Cisco-I-OS-Geräte. Obendrein haben die Entwickler in Inspec ausgemistet und versprechen nun eine deutlich flottere Abwicklung der Tests.

Beeindruckend an Chef Automate 2.0 ist, wie nahtlos Inspec in die diversen Arbeitsschritte der Plattform integriert ist. Je nach Konfiguration überprüft Automate durch Inspec jeden einzelnen Schritt eines Prozesses; lässt der Admin das Tool auf ein Linux-System los, testet es dort automatisch, ob alle vorgeschriebenen Regeln umgesetzt sind.

Nutzt stattdessen ein Entwickler Automate für den Bau einer Applikation, kann Inspec jeden einzelnen Schritt der Container-Erstellung überprüfen und unterbrechen, falls ein Container entsteht, der Compliance-Vorgaben nicht folgt. De facto lassen sich Entwickler durch das Gespann aus Automate und Inspec also zur Einhaltung der geltenden Regeln zwingen – folgen sie den Vorgaben nicht, entsteht erst gar keine Applikation.

Viele fertige Tests

Besonders praktisch: Kombiniert der Admin Chef Automate 2.0 und Inspec in seinem Setup, profitiert er von vielen fertigen Tests, die Chef Automate beilegt. Auf gängigen Betriebssystemen lassen sich etwa Standard-Compliance-Tests von mehreren anerkannten Compliance-Organisationen ausführen, die auch als Grundstock für eigene Compliance-Vorgaben dienen können.

Im Hinblick auf die Open-Source-Eigenschaften von Inspec verhält Chef sich auch in Version 2.0 von Automate übrigens vorbildlich: Der gesamte Inspec-Quelltext steht nach wie vor frei auf Github zur Verfügung, sodass Inspec auch für jene Anwender nutzbar ist und bleibt, die Chef Automate nicht auch noch verwenden wollen.

Habitat geht jetzt auch lokal

Nicht unter den Tisch fallen soll in Chef Automate 2.0 auch die neue Version von Habitat, einem Framework für die Verwaltung der Releases einer Applikation. Wobei Applikation hier nicht die typische Applikations-Definition meint, sondern eher die Cloud-Microservices-Idee: Das Tool möchte Unternehmen dabei unter die Arme greifen, vorhandene Umgebungen in eine Mikroarchitektur zu überführen (Abbildung 4). Dafür stellt es eine ganze Kiste Werkzeuge bereit.

Abbildung 4: Habitat ist die Speerspitze von Chef Automate im Hinblick auf einen Applikations-zentrierten Ansatz.

Ein wichtiger Schlüssel zum Habitat-Erfolg ist seine große Flexibilität: Auf der einen Seite nimmt es Input etwa in Form von Git-Verzeichnissen entgegen, auf der anderen Seite gibt es fertige Abbilder von Containern aus und kann diese auch gleich beispielsweise in einem Kubernetes-Cluster ausrollen (Abbildung 5).

Abbildung 5: Praktisch: “Deploy everywhere” lautet das Habitat-Motto – passend dazu kann Habitat Dienste in Kubernetes ausrollen.

Entsprechend darf Habitat als die Speerspitze der Chef-Bemühungen um eine App-zentrische Automation gelten. In der neuen Automate-Version heben seine Entwickler vor allem zwei Habitat-Funktionen hervor: Einerseits lässt sich der Habitat Builder nun auch im Rechenzentrum des Kunden betreiben, sodass die Lösung für jene Kunden attraktiv wird, die aus Compliance-Gründen nicht auf Clouddienste zugreifen dürfen.

Andererseits kommt Habitat nun mit deutlich besserer Integration in andere Dienste daher. Der Broker für das Ausrollen von Applikationen in Kubernetes hat diverse Updates erhalten. Hinzu gesellen sich die Option, direkt in Azure auszurollen, sowie eine Schnittstelle zum Open Service Broker (OSB).

Zusammenspiel

Setzt man die vier Komponenten, die zu Chef Automate 2.0 gehören, in einen größeren Zusammenhang, ergibt sich ein solider Gesamteindruck: Tatsächlich gelingt dem Unternehmen in der neuen Version der Sprung weg von der reinen Lösung für Automation auf Infrastrukturebene hin zu einem Prinzip, bei dem physische und virtuelle Systeme sowie das Ausrollen von verpackten Applikationen gleichberechtigt sind.

Freilich: Wer Chef Automate weiterhin als Plattform für die Automation von großen Serverparks verwenden möchte, kann das natürlich weiterhin tun – und profitiert von den vielen Neuerungen im Hinblick auf die Benutzbarkeit und die Bedienerfreundlichkeit, die Teil von Automate 2.0 sind.

Wer in seinem Unternehmen hingegen vermehrt die Prinzipien von Devops praktizieren möchte, bekommt mit Chef Automate 2.0 hierfür ebenfalls einen starken Partner an die Hand: Die nahtlose Integration etwa von Inspec 2 oder Habitat lässt es am Ende irrelevant erscheinen, ob das Ziel ein Linux-System oder das Erstellen einer Applikation in Container-Form ist. Beide Prozesse bieten dem Nutzer dieselben Werkzeuge für Automation und das implizite Testen auf Compliance hin.

Nicht zu unterschätzen ist besonders die Chef Workstation: Zum ersten Mal bietet der Hersteller mit diesem Produkt die Möglichkeit, schnell und direkt in die Chef-Welt einzusteigen, ohne sich zuvor große Gedanken über das Setup und die dafür benötigten Dienste zu machen. Dass es kein Problem ist, Systeme später in Automate zu übernehmen, die per Workstation ausgerollt wurden, ist dabei nur das Sahnehäubchen auf dem Eis.

Kein Wort zu Preisen

Allerdings stellt sich im Hinblick auf Chef Automate aber auch die Frage, was der Spaß denn kosten soll. Der Hersteller selbst gibt sich zugeknöpft, wie es mittlerweile üblich ist: Per Website [2] lässt sich ein individuelles Angebot anfordern, eine grobe Übersicht über die aufgerufenen Preise findet sich aber auf der Chef-Website an keiner Stelle.

Immerhin: Für Chef Automate existieren sowohl die Möglichkeit, das Produkt im Rahmen einer Trial-Phase auszuprobieren, als auch eine ausgiebige Online-Dokumentation. Darin enthalten ist ein Workshop samt vorbereiteter VMs, der Nutzern zeigen soll, wie leicht es sich mit Chef Automate 2.0 arbeiten lässt. Jeder kann das Produkt also auf Herz und Nieren testen.