Konfigurationsmanagement: Open-Source-Angebot für Chef erweitert

Redaktion JAXenter
© shutterstock.com/S_Photo

Mit dem Erscheinen des ersten Releasekandidaten für Version 12 des Konfigurationsmanagement-Werkzeugs Chef hat das Entwicklerteam eine Neuerung angekündigt: Das Open-Source-Angebot für das beliebte DevOps-Tool wird erweitert. Bei Netzwerken mit bis zu 25 Knoten kommen Nutzer der Apache-lizenzierten Distribution ab sofort in den Genuss von Features, die bislang nur Nutzern der Enterprise-Software vorbehalten waren.

Die neue Vereinheitlichung der Chef-Software löst die Hierarchie zwischen der freien und der Enterprise-Version auf. So enthält Chef 12 die Multi-Tenancy-Fähigkeiten und den rollenbasierten Zugang, der bislang nur den Nutzern der Enterprise-Distribution vorbehalten war. Auch die Reporting- und Analytics-Funktionen der Enterprise-Version stehen nun jedem zur Verfügung, der weniger als 25 Knoten in seinem Netzwerk unterhält. Bei größeren Infrastrukturen kann eine 30-tägige Probeversion in Anspruch genommen werden. Detaillierte Informationen zum neuen Lizenzmodell gibt es auf der Webpräsenz.

Zu den weiteren Tools und Funktionalitäten, auf die nun jeder Nutzer zurückgreifen kann, zählen u. a. das Chef Software Developement Kit, Chef Push (ein Push-Benachrichtigungsmechanismus) und eine Web-Management-Konsole:

Chef Infrastruktur

Chef: Konfiguration nach Rezept

Chef ist in Ruby und Erlang geschrieben. Vor sechs Jahren initiiert, assistiert das Werkzeug beim Automatisieren der Infrasktrukturverwaltung. Grund- und Vorlage sind dabei wiederverwendbare Infrastruktureinstellungen, auch „Rezepte“ (Recipes) genannt. In diesen kann der Nutzer die Konfiguration von Webservern, Datenbanken und Loadbalancern genau spezifizieren.

Diese Rezepte wiederum bestehen aus Ressourcen, die eine Infrastrukturkomponente, z. B. eine Datei, ein Template oder ein zu installierendes Paket beschreiben.

Auf dem Chef Server werden die Rezepte und weitere Konfigurationsdaten gespeichert, während der Chef Client auf jedem Knoten des Netzwerks installiert wird. Regelmäßig erkundigen sich die Clients via Polling beim Chef Server nach Updates, sprich: nach den neuesten Rezepten.

Open Source und Geschäftserfolg – was kommt zuerst?

Was führte das Unternehmen hinter Chef zu dieser Entscheidung? Ganz einfach: die Erkenntnis, dass, „wenn es um Automatisierung geht, letztlich diejenigen die Experten sind, die den Betrieb selbst führen“, wie Adam Jacob in einem Blogpost ausführt. Die Anforderungen von Unternehmen seien so speziell, das Wissen über betriebsinterne Eigenheiten so wertvoll, dass man es sich nicht leisten könne, den eigenen Infrastrukturen externe, anbieterspezifische Closed-Source-Lösungen überzustülpen, so Jacob sinngemäß.

Ohnehin stünden die Zeichen auf Open Source:

The era where we looked at doing perpetual software license deals, along with enormous consulting engagements so that experts could solve our problems for us, has passed. We know that it rarely works, and, importantly, we know that in the world we find ourselves today, these IT vendors just couldn’t possibly be experts in our problem. They don’t live in our proverbial houses.

Wieder einmal ein Hinweis darauf, dass wir im goldenen Open-Source-Zeitalter leben? Nun, es wäre sicher vermessen zu behaupten, dass quelloffene Software per se erfolgreicher sei als geschlossene. Im Fall von Chef war es der Erfolg der Technologie – Facebook und Splunk sind nur zwei prominente Nutzer –, der eine Erweiterung des Open-Source-Modells erst möglich machte. Obwohl sich hier trefflich über Henne und Ei diskutieren lässt, scheint das Beispiel doch eines zu zeigen: Am Anfang ist die Technologie. Diese muss sich behaupten und überzeugen, bevor Open-Source-Modelle fruchten können. Solide Software ist die Pflicht, Open Source die Kür. Erst, wenn eine kritische Masse von der Technologie überzeugt ist, kann sich beides gegenseitig verstärken.

Ein Negativbeispiel: Wer schlechte Software abliefert oder seinen Code nicht pflegt (so geschehen beim Heartbleed-Bug), dem nützt das Etikett „Open Source“ wenig. Im Gegenteil: In solchen Fällen wird „Open Source“ sogar zum Schimpfwort degradiert.

Open Source ist also weder Allheilmittel noch verantwortlich für allen schlechten Code dieser Welt. Pendelt sich die öffentliche Wahrnehmung irgendwo in der Mitte ein, so könnte es in Zukunft die Basis für viele erfolgreiche Geschäftsmodelle sein. Der strategische Schritt, die Chef-Software weiter zu öffnen, dürfte den positiven Kommentaren nach jedenfalls zu einem erheblichen Imagegewinn führen.

Aufmacherbild: single cook cap and blue desk von shutterstock.com / Urherberrecht: S_Photo

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: