Wenn Infrastruktur zu Code wird. Wir System-Ingenieure bedienen uns immer häufiger bei den Konzepten und Werkzeugen unserer Kollegen Software-Entwickler.

Infrastruktur ist Code

Technologien wie Puppet und Facter ermöglichen es uns, das Zusammenspiel und die Konfiguration von Servern als Source Code zu beschreiben. Wir setzen nicht länger Server auf und konfigurieren sie manuell. Wir programmieren das gewünschte Verhalten und Puppet erledigt die Arbeit vor Ort. Mit diesem Vorgehen arbeiten wir eine Abstraktionsstufe höher und verwalten mit gleichem Aufwand deutlich komplexere Systeme.

With Great Power Comes Great Responsibility

Dieser Satz passt zu Puppet wie kein anderer. Die Möglichkeit, Änderungen an der Konfiguration automatisch an alle Server zu verteilen, kann verheerende Folgen haben, sobald sich Fehler einschleichen. Zum Glück ist Qualitätsmanagement nicht etwas, was wir neu erfinden müssen. Da unsere Infrastruktur ja inzwischen Code ist, liegt die Idee nahe, dass wir uns grosszügig bei den Konzepten und Werkzeugen der Software-Entwickler bedienen. Der Einsatz von Versionierungswerkzeugen wie Git oder Mercurial ist dabei erst der Anfang.

Staged Rollout

Eine einfache Methode um die Gefahr eines Ausfalls zu verringern, ist die Verwendung von Test- und Integrations-Umgebungen. Analog zur Software Entwicklung durchläuft eine Version zuerst das Testing, dann die Integration und landet, sollten über einen definierten Zeitraum keine Fehler auftreten, schliesslich auf den Produktions-Servern.

Puppet stellt zu diesem Zweck Environments zur Verfügung, in denen wir verschiedene Versionen der Konfiguration über den selben Master Server ausliefern können. Bei der Bereitstellung der Versionen hilft uns ein einfaches Hook Script im Versionierungssystem, das anhand einer Tag-Konvention die entsprechenden Versionstände für die verschiedenen Environments auscheckt.

Verteilte Versionierungssysteme nutzen

Um Puppet Manifeste und Provider effizient zu entwickeln, benötigen wir eine Arbeitsumgebung, in der wir den geschriebenen Code während der Entwicklung testen und debuggen können. Hier helfen uns die Möglichkeiten verteilter Versionierungssysteme enorm.

Die Idee ist folgende: Wir stagen eine Reihe von Servern, die ausschliesslich zum Testen während der Entwicklung bereit stehen. Diese Server haben jeweils einen eigenen Puppetmaster und ein initialisiertes Git Repository mit einem Hook Script, welches nur darauf wartet, dass wir unsere Konfiguration hochladen. Diesen Server – oder genauer das Git Repository darauf – können wir nun als neues remote Repository erfassen.

Wollen wir nun unser neustes Puppet Manifest testen, pushen wir die ganze Konfiguration direkt auf diesen Server. Das Hook Script checkt die neue Version aus und startet einen puppetd run. Erst wenn alles funktioniert und wir sicher sind, dass der Code das tut was wir möchten, dann pushen wir die Version auf den richtigen Puppetmaster und damit in die Testumgebung.

Und weiter…

Dies sind nur einige Beispiele dafür, wie sich Konzepte und Werkzeuge aus der Software-Entwicklung für das System-Engineering adaptieren lassen. Ich
bin der Überzeugung, dass wir nur gewinnen können, wenn wir uns grosszügig aus dem über die Jahre gewachsenen Erfahrungsschatz unserer Kollegen Programmierer bedienen. Schlussendlich werden beide Seiten davon profitieren und – so sieht es die Vision der Devops vor – allmählich zusammenwachsen.