Chef ist eine Infrastruktur-Automatisierungs- und Konfigurationsverwaltungstechnologie, die Systemkonfiguration als Code in einer Ruby-basierten DSL modelliert. Sie organisiert Richtlinien in Cookbooks und Recipes und ermöglicht idempotente, reproduzierbare Provisionierung über Server und Cloud-Instanzen. Chef integriert Cloud-Anbieter, Geheimnis- und Compli…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und verwandte Bausteine zu öffnen.
Technischer Baustein: kann automatisiert, integriert oder betrieben werden.
Konkretes Rädchen im System, das in größeren Zusammenhängen wirkt.
Chef automatisiert Infrastruktur, indem es Systemzustände als Code beschreibt und auf Servern sowie Cloud-Instanzen wiederholbar durchsetzt.
Chef entstand aus dem Bedarf, Server- und Deployment-Konfigurationen reproduzierbar zu verwalten und Abweichungen automatisch zu korrigieren. Adam Jacob entwickelte das Werkzeug zunächst für seine Beratungstätigkeit; 2009 wurde es angekündigt und mit Jesse Robbins, Barry Steinglass, Nathen Haneysmith und Joshua Timberman in der neuen Firma Opscode zum Produkt ausgebaut. Der frühe Projektname war „marionette“.
Chef arbeitet wie eine Soll-Ist-Maschine mit Kochbuch und Rezept. Ein Client liest ein Cookbook, dessen Recipes Ressourcen wie Pakete, Dienste oder Dateien beschreiben. Bei jedem Lauf prüft Chef den Zustand eines Nodes, vergleicht ihn mit dem Ziel und bringt abweichende Ressourcen wieder in den gewünschten Zustand. So bleiben wiederholte Ausführungen konsistent statt doppelt wirkend.
Chef verwaltet Systemzustände so, dass Konfigurationen dokumentiert, ausrollbar und überprüfbar bleiben.
Cookbooks bündeln zusammengehörige Richtlinien und machen sie als wiederverwendbare Einheit verwaltbar.
Recipes beschreiben konkrete Konfigurationsschritte und wie einzelne Ressourcen behandelt werden.
Ressourcen stehen für Zustände wie Pakete, Dienste, Dateien oder Benutzerkonten.
Mehrfache Läufe sollen denselben Sollzustand herstellen, ohne unnötige Nebenwirkungen zu erzeugen.
Chef ist sinnvoll, wenn viele Server oder Cloud-Instanzen dieselbe Konfiguration erhalten sollen, etwa bei Provisionierung, Deployment oder Compliance-Vorgaben. Es reduziert manuelle Abweichungen und macht Änderungen nachvollziehbar. Der Preis ist zusätzlicher Pflegeaufwand für Cookbooks, die Ruby-DSL und die Betriebslogik rund um Client/Server, Geheimnisse und Fehlerbehandlung; für kleine, selten ändernde Setups kann das schwerer wiegen als der Nutzen.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.