Im Rahmen der DevOps-Bewegung setzt sich die Erkenntnis durch, dass das Konfigurieren von Servern ähnlich wie das Entwickeln von Software behandelt werden sollte. Testbare, wiederholt ausführbare Programme ersetzen die manuelle Konfiguration. Dieser Artikel zeigt am Beispiel Chef, wie dieses Paradigma umgesetzt wird.
Ein typischer erster Arbeitstag in einem neuen Projekt: Es handelt sich um ein ganz „gewöhnliches“ Java-EE-Projekt. Ich bekomme Zugangsdaten für eine Versionsverwaltung und ein Wiki-System. Ich habe Glück, der Code lässt sich sofort bauen. Nun würde ich meine nagelneuen Artefakte gerne deployen und in Aktion sehen. Das bedeutet zunächst: Wiki-Seiten wälzen. Dort finde ich Verweise auf den verwendeten Application-Server und Fragmente für die Konfiguration. Ich wühle mich also durch die Downloadseiten des Herstellers, um die korrekte Version zu finden, und editiere dann die Konfigurationsdateien. Für die verwendete Datenbank bekomme ich vom Kollegen ein Image für eine Virtualisierungssoftware. Allerdings, so warnt er mich, müsse ich einige Schemaänderungen noch per Hand nachpflegen. Etwas später habe ich die Migrationsskripte gefunden und führe sie aus. Per Hand deploye ich die neuen Artefakte und es entstehen merkwürdige Fehler. Die Fehlersuche mit dem Kollegen offenbart, dass ich noch einige obligatorische Verzeichnisse anlegen muss und die Konfigurationsdateien aus dem Wiki nicht ohne Änderungen zu der Datenbank im Image passen. Schlussendlich bin ich in der Lage, das Projekt zum Laufen zu bringen. Aber ob mein System wohl identisch mit dem des Kollegen ist? Oder der Testumgebung? Oder der Produktion? Und mit wie viel Aufwand für den Aufbau einer weiteren Staging-Umgebung muss man rechnen?
Kommt Ihnen das geschilderte Szenario bekannt vor? Wie aber lässt sich die Situation verbessern? Wir können uns einiges bei uns selbst abschauen: Der Quelltext des Projekts ließ sich ohne Probleme auschecken und erfolgreich bauen. Das hat vor allem zwei Gründe: Erstens verwalten wir Quelltext in einem Versionskontrollsystem (VCS) und Zweitens wird er regelmäßig automatisch gebaut und getestet. Wir können Änderungen vornehmen, ohne befürchten zu müssen, sie nicht mehr rückgängig machen können. Das VCS verrät uns bei richtiger Anwendung, wann, von wem und warum eine Änderung gemacht wurde; und jeder kann jederzeit den aktuellen Stand abrufen. Darüber hinaus ist durch die automatisierten Tests eine gewisse Qualität gesichert. Wenn es uns nun gelänge, alle Schritte zum Aufsetzen der Infrastruktur, hier also der Datenbank, des Applikationsservers und das Deployen der Anwendung mit einer ausführbaren Dokumentation zu versehen, könnte sie ebenfalls im VCS gespeichert und automatisch verifiziert werden.
Dieses Vorgehen wird als „Infrastructure as Code“ bezeichnet. Dabei geht es nicht vorrangig um das Einsetzen eines neuen Tools, sondern um einen Paradigmenwechsel. Das Einrichten von Systemen wird als Programmieren begriffen, und wir übertragen Vorgehensweisen aus der klassischen Entwicklung auf das Entwickeln von Infrastruktur. Lauffähige Systeme werden damit vom statischen Artefakt, das einmal eingerichtet wird, zum Ergebnis eines ausführbaren Programms. Das macht sie duplizierbar und versionierbar.
Einmal geschriebener Code kann in einem virtuellen Rechner auf dem Entwicklercomputer, in der Cloud oder auf echter Hardware ausgeführt werden. Dadurch gelingt es, Unterschiede zwischen Entwickler-, Test- und Produktivsystemen zu verringern. Darüber hinaus wird das lauffähige System zum Wegwerfartikel: Es kann jederzeit gelöscht, neu erstellt oder dupliziert werden. Das erlaubt es zum Beispiel, Systeme nur für die Laufzeit bestimmter Tests zu erstellen, und macht damit einen Hauptvorteil des Cloud Computing, also die kurze Provisionierungsdauer und Abrechnung nach tatsächlich genutzter Zeit, überhaupt erst in größerem Umfang nutzbar. Infrastruktur zu programmieren und versionieren statt nur zu konfigurieren hat Vorteile weit über den geschilderten Anwendungsfall des Einrichtens der Entwicklungsumgebung hinaus.
Um Infrastruktur zu programmieren, bedarf es einer Programmiersprache, die darauf zugeschnitten ist. Chef stellt eine solche domänenspezifische Sprache (DSL) bereit. Als Framework leistet Chef aber noch mehr: Es sammelt alle...