© Dean Drobot / 123RF.com

Der Automatisierer Chef entlehnt seinen Wortschatz teils der Küchenwelt. Für viele wiederkehrende Aufgaben enthalten seine Kochbücher gute Rezepte, nach denen der Admin sich mit überschaubarem Aufwand ein passendes Menü anrichtet.

Chef existiert bereits seit 2009 und ist eines der bekanntesten Systeme für das Configuration Management. Ursprünglich hieß die Herstellerfirma Opscode, später benannte sie sich in Chef um. Seit Ende 2020 gehört Chef nun zum US-amerikanischen Software-Unternehmen Progress, das seinem breiten Portfolio von Entwicklungstools damit eine DevOps-Lösung hinzugefügt hat. Viele bekannte Firmen setzen auf Chef [1], um ihre Infrastruktur oder sogar Teile ihrer Cloud zu managen. Facebook, Uber, SAP und die Deutsche Bahn sind prominente Beispiele dafür.

Chef ist überwiegend in Ruby geschrieben und basiert auf einer Client-Server-Architektur mit verschiedenen optionalen Komponenten [2]. Es lässt sich für einfache Use Cases auch stand-alone nutzen. Rund um Chef existiert eine robuste Toolchain für Software-Qualität, Testing und Software Lifecycle Management, die von einer aktiven Community und Chef selbst stetig weiterentwickelt wird. Das Portfolio umfasst mittlerweile 4 000 frei nutzbare sogenannte Cookbooks für die Konfiguration von Software und mehrere Hundert Plugins und Zusatzwerkzeuge. Im Gegensatz zu anderen Tools richtet sich Chef dabei allein auf das Management von Betriebssystemen und Applikationen, nicht aber auf die Provisionierung von VMs oder Cloud-Infrastruktur.

Grundlegende Begriffe

Zunächst gilt es, einige grundlegende Begriffe zu klären, auf denen die nachfolgenden Erläuterungen aufbauen. Die Bezeichnung Chef – deutsch: Küchenchef – stammt aus der Gastronomie. Entsprechend wurden die Namen vieler Tools mit einem Augenzwinkern an die Küchenwelt angelehnt, und selbst Neueinsteiger erhalten auf Anhieb einen guten Überblick. So gibt es Kochbücher (Cookbooks), die Rezepte (Recipes) enthalten sowie einen Supermarkt, in dem die Community weitere Cookbooks kostenfrei bereitstellt.

Zusätzlich zu den von Chef selbst gepflegten Cookbooks ergänzen weit über 100 von den Sous-Chefs gepflegte Cookbooks das Ökosystem. Diese Gruppe von Freiwilligen aktualisiert und erweitert kontinuierlich sämtliche betreuten Projekte und hält zudem wöchentlich öffentliche Treffen im Chef Community Slack ab. Weiter gibt es Rollen (Roles), die Rezepte aus Kochbüchern nutzen und miteinander verbinden. Diese Roles können von einem Node genutzt werden. Als Node bezeichnet man zum Beispiel eine virtuelle Maschine, einen Server oder generell ein beliebiges System, auf dem sich Software installieren oder konfigurieren lässt.

Das alles wird über ein Tool namens Knife gehandhabt. Zu dessen Funktionen zählen unter anderem das Hochladen von Cookbooks, das Auflisten von Ressourcen und das Nutzen des Supermarkts. Damit der Überblick auf einem Node nicht verloren geht, gibt es zusätzliche das kleine Hilfsmittel Ohai, mit dem sich jederzeit die aktuelle Konfiguration eines Systems auslesen und beliebig nutzen lässt.

Bei Bedarf ergänzen eigene Attribute die von Ohai gesammelten Informationen. Diese Attribute setzt man wie Variablen ein, um Einfluss auf die Ausführung zu nehmen. Die Verbindung zwischen Roles, Attributes, Run Lists und Cookbooks stellen sogenannte Policy Files her. Ein Policy File enthält alle nötigen Informationen für alle Umgebungen und lässt sich in Git versionieren.

In den Recipes kommt eine Domain-spezifische, leicht verständliche Sprache zum Einsatz, die Chef DSL. Gibt es einmal keine Möglichkeiten, sie zu verwenden, besteht die Möglichkeit, auf Ruby als Programmiersprache zurückzugreifen. Dies ist jedoch meist nicht nötig.

Komponenten

Eine typische Chef-Umgebung enthält je nach gewünschtem Umfang [3] verschiedene Komponenten. Das Minimum, um Chef nutzen zu können, ist der Chef Infra Client, der dabei die Rolle der aktiven Komponente spielt. Führt man ihn lokal auf einem Node aus, benötigt er eine sogenannte Run List, die wenigstens ein Recipe beinhaltet.

Die zentrale Verwaltung von Run Lists übernimmt der Chef Infra Server, der Nodes registriert und verknüpft. Das hat weitere Vorteile wie die zentrale Verwaltung als Source of Truth von Cookbooks, Run Lists, Environments, Roles, Attributes und Policy Files. In der Vergangenheit fungierte der Server dabei auch als Reporting-Tool; so ließ sich schnell ein Überblick über die abgelaufenen Chef Infra Client Runs gewinnen.

Da das Unternehmen die immer weiter wachsende Weboberfläche für Chef Infra Server bereits abgekündigt hat, entschloss sich Chef dazu, Chef Automate auf den Markt zu bringen. Chef Automate diente zunächst nur als reines Reporting-Tool für Veränderungen der Infrastruktur. Es hat sich in den letzten Jahren jedoch so stark weiterentwickelt, dass es – um viele Funktionen erweitert – die Weboberfläche vom Chef Infra Server ablösen soll. Hinzugekommen sind unter anderem eine REST-API, Single Sign On und die Integration als Quelle für die CMDB von ServiceNow (Abbildung 1).

Abbildung 1: Chef Automate startete als Reporting Tool, ist inzwischen aber auf dem Weg, den Chef Infra Server abzulösen.

Im Lauf der Zeit hat sich Automate so weit entwickelt, dass man es sogar als zentrale Compliance-Monitoring-Plattform mit mehr als 400 mitgelieferten Benchmarks nach Industriestandards nutzen kann. Es bietet außerdem die Möglichkeit, direkt mit den APIs von AWS, Azure und GCP zu kommunizieren und diese automatisch abzufragen oder auch per SSH beziehungsweise WinRM mit den Zielumgebungen und -systemen. Die kontinuierliche Überprüfung übernimmt Chef InSpec.

Neben den in Automate enthaltenen Compliance-Profilen bietet der Hersteller mit dem Produkt Chef Compliance mittlerweile auch passende Cookbooks an, die ermittelte Probleme automatisch lösen. Diese Remediation-Pakete sind offiziell vom Center for Internet Security (CIS) zertifiziert und sorgen ohne zusätzlichen Entwicklungsaufwand für mehr IT-Sicherheit.

Über den Chef Supermarket kann man die interne Chef Community unterstützen oder öffentliche Cookbooks nutzen. Er vermittelt den Überblick, welche Cookbooks es bereits gibt – so muss man das Rad nicht neu erfinden. Die Entwicklung neuer Cookbooks und Policy Files wie auch der Betrieb einer Chef-Umgebung bedarf keiner aufwendigen Installation von zusätzlichen Komponenten wie Ruby oder weiterer Tools. Man installiert lediglich die sogenannte Chef Workstation. Nach der Initialisierung mit einem kurzen Befehl stehen alle benötigten Komponenten und Pakete bereit und lassen sich sogleich nutzen. Speziell für Windows gibt es dafür sogar ein eigens erstelltes Docker-Image.

Verwendung von Chef

Chef Infra arbeitet mit einem auf dem Node installierten Agent, der nach dem Pull-Prinzip periodisch beim Chef Infra Server anfragt, ob es aktuellere Cookbooks, Run Lists oder Attributes für ihn gibt. Falls nicht, startet das beim vorherigen Lauf lokal gecachte Cookbook erneut, um den gewünschten Systemzustand (Desired State) zu überprüfen und gegebenenfalls wiederherzustellen (Test & Repair). Sofern der Chef Infra Server neuere Informationen besitzt, werden nur die aktualisierten Komponenten heruntergeladen.

Der Client identifiziert sich dabei per Zertifikat über das HTTPS-Protokoll beim Server, sodass es sich erübrigt, für jedes einzelne System Firewall-Freigaben zu konfigurieren, wie das bei Push-basierten Systemen üblich ist. Dieses Vorgehen sorgt für sehr sichere Verbindungen und zugleich für eine sparsame Ressourcennutzung auf dem Chef Infra Server, der bereits als Stand-alone-Installation rund 100 000 Nodes verwalten kann.

Die zuvor erwähnten Cookbooks folgen, wie auch bei anderen Tools üblich, einer standardisierten Struktur, die je nach Komplexität der Aufgaben variiert (Abbildung 2). Dabei sind zumindest zwei Teile fakultativ: Die Datei »metadata.rb«, die Angaben wie den Namen und die Version des Cookbooks enthält, sowie ein oder mehrere Recipes im gleichnamigen Unterverzeichnis (Abbildung 3), die den Desired State spezifizieren (Listing 1).

Abbildung 2: Ein komplexeres Cookbook von Chef gliedert sich auf diese Weise.

Abbildung 3: Ein minimales Cookbook von Chef verwendet diese Struktur.

# metadata.rb
```ruby
name 'webserver'
description 'Installs an Apache2 webserver'
version '1.0.0'

Damit das Anlegen eines neuen Cookbooks keine unnötige Arbeit erzeugt, gibt es den Befehl »chef generate cookbookName«. Da jede Organisation andere Anforderungen hat, lässt sich die Vorlage für den Befehl beispielsweise über ein zentral zur Verfügung gestelltes Gem-Paket anpassen.

Dabei sollte ein Cookbook immer einen klar abgesteckten Aufgabenbereich (“Installiere einen Apache 2 Webserver”) abbilden. Die Teilaufgaben des Cookbooks stellen die einzelnen Recipes dar – beispielsweise die Installation einer Software, deren Konfiguration, ein Upgrade oder die Deinstallation. Innerhalb der Recipes löst sich Chef von selbst erstellten Skripts und stellt mit der Chef DSL die Systemressourcen abstrakt dar (Listing 2).

```ruby
# recipes/default.rb
package 'apache2' do  # Ressourcentyp+Paketname
  version '2.4.43'    # Version des Pakets
  action :install     # gewünschte Aktion
end
```

Neben der Ressource »package« befinden sich in vielen Recipes noch die Komponenten »remote_file« (Download von Dateien), »file« (Definition von Dateien und gegebenfalls deren Inhalt) sowie »template« (für Datei-Templates mit Variablen und Logik). Chef wählt abhängig von der erkannten Plattform automatisch die richtige Vorgehensweise. Bei Drucklegung dieses Artikels unterstützte der Chef Infra Client insgesamt 167 verschiedene Ressourcen für 12 Plattformen und alle gängigen Architekturen.

Allerdings muss ein Cookbook nicht nur auf die Plattform reagieren können, sondern auch auf verschiedene Anwendungsfälle. Hierfür gibt es einerseits die automatischen Daten aus Ohai und andererseits beliebig definierbare Attribute, die das Verhalten dynamisch machen. So kann man die Version eines Pakets spezifizieren, sie nimmt aber bei Bedarf einen anderen Wert an. Der in Listing 3 vorgegebene Wert lässt sich in Recipes oder Templates über »node[‘apache2_version’]« nutzen.

```ruby
# attributes/apache2.rb
default['apache2_version'] = '2.0.1'
```

Für vertrauliche Daten wie Passwörter oder Zertifikate gibt es Integrationen mit Lösungen wie Chef Vault, AWS Secrets Manager oder HashiCorp Vault.

Die durch verschiedene Plattformen und die Nutzung von Attributen und Secrets bedingte hohe Dynamik der Cookbooks stellt hohe Anforderungen an die Qualität. Erfreulicherweise bietet Chef ein komplettes Ökosystem für Tests. Statische Code- und Stilanalyse übernimmt Cookstyle, Unit-Tests erfolgen mit ChefSpec, Integrationstests mit InSpec. Mit Test Kitchen gibt es zudem noch ein Tool, um Tests parallelisiert über mehrere Plattformen auszuführen. Dadurch gelingt Test-driven Development problemlos.

Insbesondere InSpec kommt dabei eine tragende Rolle zu: Damit geschriebene Tests lassen sich völlig unabhängig von Chef ausführen (Listing 4).

```ruby
# test/integration/default/apache2.rb
describe package('apache2') do
  it { should be_installed }
  its('version') { should eq '2.4.43' }
end
describe port(80) do
  it { should be_listening }
end
```

Sobald ein Cookbook geschrieben und ausgiebig getestet ist, lässt es sich optional im eigenen Chef Supermarket bereitstellen oder mit der Community öffentlich teilen. Die Aufgabe, die ein Node dabei übernehmen soll, definieren bei Chef die Policy Files (Listing 5). Sie enthalten notwendige Abhängigkeiten, die Reihenfolge der auszuführenden Recipes, Umgebungen (zum Beispiel »test«) und die Attributes.

```ruby
# Policyfile.rb
name 'webserver'
cookbook 'apache2', '~> 1.0'
run_list [
  'apache2::install'
]
default['apache2_version'] = '2.4.43'
# Webserver runs a newer version on test machines
default['test'] = {
  'apache2_version': '1.0.1'
}
```

Das Kommando »chef install« löst alle externen Abhängigkeiten auf, »chef push test webserver« übernimmt das Hochladen auf den Chef Infra Server. Sobald der Admin nun mit »knife node policy set server01 test webserver« einen Node dieser Policy zuordnet, ist das System komplett, und der Chef Client kann ausgeführt werden.

Ausblick

Wie jedes Software-Ökosystem entwickelt sich auch das von Chef kontinuierlich weiter. In den letzten Jahren wurde vor allem die Codebasis von Ballast befreit und um nützliche Funktionen aus Community-Projekten erweitert. Dazu gehören neben Dutzenden praktischer Hilfsfunktionen wie »vmware?« oder »windows_server_2019?« die stark verbesserte Windows-Unterstützung sowie der Support für ARM-Architekturen (IoT-Geräte, Apple M1, …).

Daneben kamen neue Funktionen hinzu, die sich teilweise noch in der Beta-Phase befinden. Ein Beispiel dafür ist die Option, Recipes in YAML zu schreiben. Momentan werden dabei aber weder Attribute noch komplexere Logik unterstützt – dies bleibt der Chef DSL vorbehalten. YAML soll diese keineswegs ersetzen, sondern lediglich einen einfacheren Ein- oder Umstieg ermöglichen (Listing 6).

#### Chef DSL
```ruby
package 'apache2' do
  action :install
  version '2.4.43'
end
```
#### YAML
```yaml
resources:
- type: package
  name: apache2
  version: 2.4.43
```

Ein spannendes Thema, an dem die Entwickler seit geraumer Zeit arbeiten, ist der Chef Infra Target Mode, mit dem sich Chef Infra auch ohne Client-Installation ausführen lässt. Da der Transport-Layer modular ist, kann man Remote-Nodes damit nicht nur über SSH und WinRM ansprechen, sondern auch per AWS Systems Manager, VMware Tools oder sogar USB. Diese Funktion bietet zusammen mit der allgemeinen Erweiterbarkeit von Chef Infra und der bereits implementierten Remote-Inventarisierung über Ohai die Möglichkeit, Platform Support Packs zu schreiben, um Netzwerkgeräte oder auch REST-APIs (wie zum Beispiel Redfish-Server-Management-Module) zu konfigurieren. Offizielle Ressourcen hierfür sind jedoch bislang nicht geplant, es handelt sich um eine Option für fortgeschrittene Nutzer und Chef-Partner.

Mittlerweile folgt Chef dem Prinzip von Open Source, und so kann jeder Nutzer Vorschläge für Bugfixes oder neue Features auf Github einbringen. In wöchentlichen Triage-Meetings diskutieren die Entwicklern diese dann öffentlich. Zudem berichten sie, ebenfalls im Wochenturnus, im Chef Community Slack über Fortschritte, Releases und neue Features.

Auch wenn Open Source nun die treibende Kraft hinter den Chef-Produkten ist, gibt es die Lösung nicht gratis. Zeitgleich mit dem Strategiewechsel änderte Chef zum April 2019 sein Lizenzmodell. Für gemeinnützige Organisationen, Privatpersonen, für Lernzwecke und Experimente bleibt die Lösung seitdem kostenfrei [4]. Eine kommerzielle Nutzung setzt weiterhin kostenpflichtige Lizenzen voraus, die dann allerdings Support umfassen. Das derzeitige Minimum für eine solche Lizenz gestattet 100 Nodes, wobei von Chef autorisierte Managed-Service-Anbieter auch kleinere Kontingente inklusive Cloud-Hosting anbieten können.

Für alle anderen Zwecke müssen sich Nutzer noch etwas gedulden: Die Community arbeitet momentan an einer eigenen Distribution namens CINC (“CINC is not Chef” [5]), die später zwar ohne Hersteller-Support, aber dafür für alle kostenfrei zur Verfügung stehen soll. Derzeit sind die Pakete aber noch nicht zur produktiven Nutzung freigegeben.

Einige Eigenschaften bleiben außerdem der kommerziellen Version vorbehalten [6]. Dazu zählen etwa Compliance-Benchmarks, die CIS-zertifizierten Cookbooks für Hardening, das Desktop-Endpoint-Management sowie der ServiceNow-Connector von Chef Automate.

Fazit

Chefs Client-Server-Architektur ermöglicht ein dezentrales Ausführen der Aufgaben. Zudem macht der Einsatz von HTTPS als Protokoll die Firewall-Konfiguration einfach und dank Client-Zertifikaten sehr sicher. Die Kombination aus Configuration Management, Monitoring der Deployments via Chef Automate und integrierter Prüfungen auf Compliance sorgt zudem für exzellente Übersicht.

Der Einstieg in Chef fällt durch Tausende Cookbooks und zahlreiche Beispiele im Internet leicht, auch die Dokumentation ist stets aktuell und enthält Code-Snippets. Die Chef DSL macht Recipes leicht verständlich, Ruby-Wissen braucht man nur selten. Trotzdem skaliert die Software von Einzelsystemen bis hin zu komplexen Cloud-Umgebungen. Insbesondere beim Umsetzen von Projekten erweist sich die enge Einbindung der Community als großer Pluspunkt: Neue Features und Bugfixes werden oft binnen einer Woche in offizielle Releases integriert.

Einer der Hauptkritikpunkte an Chef ist sicherlich die Notwendigkeit eines Agents auf den Zielsystemen, die oft schon mit vielen anderen Hintergrundprozessen bestückt sind. Die zahlreichen Vorteile machen dieses Manko jedoch leicht wieder wett. (jcb/jlu)