Die heutigen Anforderungen an IT-Infrastrukturen steigen kontinuierlich, während deren Umfang und die Abhängigkeit der Geschäftsprozesse ebenso zunimmt. Gleichzeitig geht die Schere zwischen Verfügbarkeit und Nachfrage an Fachkräften immer weiter auseinander. Damit rückt das Thema Automatisierung immer mehr in den Vordergrund. In diesem Kontext taucht dann auch immer wieder der Begriff „Infrastructure as Code“ als Lösungsansatz auf, im Folgenden als „IaC“ abgekürzt.
Aber zunächst – was versteht man unter IaC.
IaC beschreibt den Ansatz IT Infrastruktur Elemente automatisch zu erstellen und zu konfigurieren, statt dies manuell zu erledigen. Ausgangsbasis ist dabei eine textuelle Beschreibung aller Elemente, die unter Kontrolle von IaC verwaltet werden soll. Das gilt nicht nur für die einmalige Erstellung, sondern für den gesamten Lebenszyklus der Elemente.
Beim Thema IT-Automatisierung/IaC wird man immer wieder mit Fragen konfrontiert wie „Ich habe doch nur 10 VM’s, lohnt sich das überhaupt“, oder „Ein paar Server sind doch schneller manuell eingerichtet, statt sich wochenlang mit neuen Techniken für die Automatisierung zu befassen“. Diese Einwände sind natürlich berechtigt, denn Automatisierung soll ja kein Selbstzweck sein. Allerdings greift der Gedanke, Automatisierung spart Zeit, viel zu kurz. Vielmehr sind andere Aspekte genauso wichtig, oder sogar noch wichtiger. Dazu zählen Folgende, die aus Sicht des Autors eine wesentlich wichtigere Rolle im IT-Alltag spielen.
Im Folgenden möchte ich das ausführlicher erläutern.
Mitarbeiter im IT-Betrieb sind keine Roboter, es sind Menschen mit sehrunterschiedlichen Aus- und Vorbildungen. Sie können sich auch sehrdeutlich in Punkten wie Verantwortungsbewusstsein und Sorgfalt unterscheiden, sind auch nicht jeden Tag gleichermaßen leistungsbereit. Das hat dann folglich auch Einfluss auf die Qualität ihrer Arbeit. Die Qualität der Umsetzung von IT-Infrastruktur hängt dann an der jeweiligen Person. Die Folge – Komponenten die eigentlich alle gleich aufgebaut sein sollten, unterscheiden sich am Ende dennoch. Hier lassen sich mit IaC erhebliche Verbesserungen erzielen. Im Mindesten, dass gleiche Komponenten am Ende auch immer gleich sind, und die Qualität auf einheitlichem Niveau ist.
Das ewig leidige große Thema im IT-Betrieb – Dokumentation! Eher selten vorhanden, und wenn doch, dann oft veraltet oder lückenhaft. Im Fall von Personalengpässen, oder zeitlich eng kalkulierten Projekten, fällt die Dokumentation meist als erstes dem Zeitdruck zum Opfer. Wie eingangs erwähnt stellt IaC eine eindeutige und vollständige Beschreibung der Infrastruktur dar und auch wie sie entsteht. Damit ist sie in diesem Sinne auch vollständig dokumentiert, zwar in einer speziellen Sprache, aber sie ist vollständig und immer aktuell.
Warum ist das so? Nun, eine Computersprache ist im Unterschied zu natürlichen Sprachen immer eindeutig. Auch die Algorithmen zur Umsetzung der Beschreibung in die Infrastruktur sind eindeutig. Damit ist IaC das ideale Instrument zur Dokumentation von Infrastruktur.
Falls, warum auch immer, die Beschreibung in der Spezialsprache nicht genügt, ist es wegen der Eindeutigkeit auch kein Problem diese automatisch in natürliche Sprache zu überführen.
Viele IT-Infrastrukturen leiden unter einen Wildwuchs an unterschiedlichen Lösungen, oft auch für das gleiche Problem. Da werden ohne Strategie und Vereinheitlichung mal eben schnell Systeme aufgesetzt und produktiv genutzt. Am Ende kann dies zur Unwartbarkeit der IT, mit unkalkulierbaren Risiken für das Unternehmen führen. IaC stellt schon aufgrund der Tatsache, dass eine Beschreibung der beabsichtigten IT-Elemente erstellt werden muss, eine gewisse Hürde für Spontanität dar. Es erfordert Planung und erzeugt auch einen nicht zu vernachlässigenden Aufwand, der zu mehr Strategie und Vereinheitlichung zwingt.
Ist die IaC Beschreibung erstellt, kann bei der Umsetzung, im Gegensatz zur Manuellen, keine Abweichung mehr entstehen. Das kann so weit gehen, dass dem umsetzenden IT-Mitarbeiter, aufgrund von fehlenden Zugriffsrechten, die manuelle Umsetzung nicht mehr möglich ist, und er nicht mehr vom Standard abweichen kann. Dadurch kann die Standardisierung erzwungen werden.
Um kein Missverständnis aufkommen zu lassen. IaC ist kein Ersatz für ein solides Backup der Infrastruktur. Aber getreu dem Motto „shit happens“ kann IaC im absoluten Katastrophenfall die Möglichkeit bieten, wenigstens die Infrastruktur effizient neu erstellen zu können. Was die Ausfallzeiten erheblich reduzieren kann, und im Extremfall den Unterschied zwischen Überleben oder Untergang des Unternehmens ausmachen kann.
Vom Fachkräftemangel allerorten ist auch die IT-Branche nicht verschont. Das Angebot ist begrenzt, die Nachfrage groß. Unter diesen Rahmenbedingungen ist es nicht selten, dass wichtige Know-how Träger das Unternehmen verlassen. Da ist es nicht mehr ausgeschlossen, dass plötzlich Teile der Infrastruktur nicht mehr wartbar sind, weil keiner mehr über das notwendige Wissen verfügt. Kombiniert mit einem undokumentierten Wildwuchs an Infrastruktur kann das schnell in einer Situation enden, die für das Unternehmen geschäftsgefährden ist. Hier schafft IaC, wie vorausgehend beschreiben, durch das vorhanden sein von Dokumentation und einheitlichen Standards wirksam Abhilfe.
Die ein oder andere IT-Abteilung verfügt schon über teilautomatisierte Lösungen in Form von selbst erstellten Scripts. In gewisser Weise können diese auch als IaC betrachtet werden. Ist IaC also im Grunde nichts anderes als der systematische Einsatz von Scripting zur Erstellung und Anpassung von IT-Infrastruktur?
Ja und Nein. Ja in dem Sinne, dass über die Eindeutigkeit der Scripte die Reproduzierbarkeit gewährleistet wird. Allerdings wird dieser Ansatz in der Praxis mit hoher Wahrscheinlichkeit, wegen des hohen Aufwands und Fehleranfälligkeit, wenig erfolgreich sein. Woran liegt das?
Um das zu verstehen muss man sich die Konzepte der verfügbaren IaC-Werkzeuge genauer ansehen. Ein wesentliches Merkmal von IaC-Programmen ist die Deklarative Beschreibungssprache. Darin liegt auch der fundamentale Unterschied zum Scripting, deren Sprachen Imperativ sind. Was bedeutet das?
Nun, während beim Scripting beschrieben wird „wie“ etwas gemacht wird, beschreibt der deklarative Ansatz „was“ gemacht werden soll. Daraus ergeben sich die folgenden Konsequenzen. Durch den Deklarativen Ansatz, also „Was“ soll gemacht werden, muss sich der Entwickler keine Gedanken darüber machen wie etwas in der Infrastruktur umgesetzt wird. Genau genommen hat er darauf auch gar keinen direkten Einfluss. Die gesamte Logik befindet sich im Programm und nicht in der Beschreibung. Nicht nur das – ein derartiger Ansatz stellt auch sicher, dass der Programmaufruf wiederholt ausgeführt werden kann.
Existiert keine Abweichung zwischen Beschreibung und tatsächlich vorhandener Infrastruktur geschieht schlicht weg nichts. Falls es Abweichungen gibt errechnet das IaC-Programm alle Aktionen die auszuführen sind damit der Soll Zustand erreicht wird. Darin liegt der größte und wesentliche Unterschied zwischen IaC und Scripting. Umgekehrt liegt beim Scripting der Vorteil der weitaus größeren Freiheiten und Möglichkeiten, erhöht aber die Komplexität. Das zeigt sich vor allem dann wenn man den gesamten Lebenszyklus eines Infrastruktur-Elements betrachtet. Erstellen, Ändern und wieder Löschen, alle Konstellationen müssen vom einen Script dann auch gehandhabt werden – und das für jedes einzelne Objekt.
Zusammenfassend kann man jedoch sagen, dass die eingeschränkte Flexibilität des deklarativen Ansatzes in der Praxis dadurch ausgeglichen wird, dass die existierenden Werkzeuge in der Regel eine Plugin Schnittstelle eingebaut haben und es ein OpenSource Ökosystem mit vielen Erweiterungen gibt. Wird man da wiedererwarten nicht fündig, schreibt man sich halt sein eigenes Plugin, vorausgesetzt die notwendigen Programmierkenntnisse sind vorhanden.
Dateien mit IaC Beschreibungen bilden die Quelle für die daraus entstehende Infrastruktur. Jede Änderung an der Beschreibung hat eine Änderung an der Infrastruktur während Ausführung des IaC-Programms zur Folge. Stellt man die Quelltexte unter Versionskontrolle, werden die Änderungen im Nachhinein nachvollziehbar und können auch wieder rückgängig gemacht werden. Mit Systemen wie GitLab/GitHub erhält man nicht nur einen zentralen Speicherort, sondern kann auch gleich Prozesse einführen die in der Softwareentwicklung vielfach erprobt sind, bis hin zum Vier-Augen-Prinzip.
Dabei wird mit mehreren Versionszweigen gearbeitet. Der Hauptzweig darf dabei nie direkt verändert werden. Stattdessen wird für jede Änderung ein Nebenzweig verwendet, der nach erfolgreichen Tests, mit Hilfe eines Merge-Requests, in den Hauptzweig übernommen wird. Für die Freigabe des Merge-Requests kann auch ein Vier-Augen-Prinzip erzwungen werden.
Geht man dann noch einen Schritt weiter und ersetzt den manuellen Aufruf des IaC Programms durch eine CI/CD Pipeline ergibt sich eine vollständige Reproduzierbarkeit und dauerhafte Nachvollziehbarkeit aller Veränderungen der Infrastruktur. Der Gesamtprozess für eine einzelne Änderung stellt sich dann wie folgt dar:
Da die Protokolle der Pipeline Läufe dauerhaft, mit Bezug zum auslösenden Commit, abgespeichert werden und jederzeit einsehbar sind, können alle Änderungen, sowohl an den Quelldateien als auch an den Infrastruktur Objekten selbst, jederzeit nachvollzogen werden.
Vielleicht ist es den Ein oder Anderen beim Durchlesen schon aufgefallen, IaC tangiert im Bezug auf Knowhow den Bereich der Softwareentwicklung. Bedeutet das in letzter Konsequenz, dass man IaC nur umsetzen kann wenn man über ausgeprägte Skills im Entwicklungsbereich verfügt?
Nicht unbedingt. Die deklarativen Sprachen von IaC-Produkten sind relativ leicht zu verstehen. Die Beschreibung von einer Ressource, wie zum Beispiel einer VM, ist schnell und einfach zu erstellen. Sie können aber oft sehr umfangreich sein. Warum das so ist soll im folgenden ausführlicher erläutert werden. Im Abschnitt „Deklarative Beschreibung vs Imperative Programmierung“ wurden die Vorteile des deklarativen Ansatzes erläutert. Ein großer Nachteil ist jedoch, dass für jede mögliche Ressource eine Logik mit samt aller möglichen Ausprägungen im IaC-Programm vorhanden sein muss. Entsprechend umfangreich können die Beschreibungen in der Praxis, aufgrund der vielen Möglichkeiten, werden.
Während der Tool-Hersteller möglichst viele Möglichkeiten abdecken will und muss, werden im Umfeld des Kunden nur eine Untermenge aller Möglichkeiten benötigt. Vielmehr will man auf der Kundenseite die Möglichkeiten sogar einschränken um Wildwuchs zu vermeiden. Die Lösung besteht nun darin die Ressourcen Definition in ein eigenes parametrisierbares Modul auszulagern, das immer wieder verwendbar ist. In dieser Modullogik werden dann die kundeninternen Standards umgesetzt. Dadurch werden die eigentlichen Beschreibungen im Umfang deutlich reduziert. Alle durch die Kundenumgebung vorgegebenen Standard Eigenschaften werden an einer zentralen Stelle im Modul festgelegt und gepflegt.
Je weiter man diese Methode treibt, desto mehr rückt das Thema Software Engineering in den Vordergrund. Darauf zu verzichten kann besonders in umfangreichen Kundenumgebungen zur Unwartbarkeit des Ganzen führen.
Gelangt man zur Erkenntnis, das kein Weg an einen Software Engineering getriebenen Weg vorbei führt, stellt sich so gleich die Frage ob man die nötigen Fachkompetenzen im eigenen Unternehmen etabliert oder über einen externen Dienstleister bezieht.
Die Ressourcen im eigenen Unternehmen zu etablieren gestaltet sich in vielen Fällen, vor allen in kleineren und mittelständigen, Unternehmen schwierig im Hinblick auf Auslastung, Redundanz und Verfügbarkeit am Arbeitsmarkt. Umgekehrt muss auch der Dienstleister mit einen ausreichend großen und kompetenten Team am Markt erst mal gefunden werden.
Das Linux Team der IF-Tech AG verfügt über ein starkes Team, mit zum Teil mehr als 20 Jahren Erfahrung im Linux und OpenSource Einsatz plus Software Entwickler Praxis, über die notwendigen Voraussetzungen, die Kunden in folgenden Punkten zu unterstützen:
Nachdem nun klar ist welchen Nutzen IaC für den IT-Alltag hat, stellt sich die Frage wie und mit welchen Werkzeugen man das umsetzen soll. Dafür gibt es, wie so oft, viele Wege und ebenso viele Werkzeuge. Die geeignete Auswahl ist dabei sehr stark davon abhängig welche Bereiche der IT-Infrastruktur man automatisieren möchte. Sie sind in der Praxis ja sehr vielfältig, angefangen von Netzwerkkomponenten, Servern und Virtualisierungslösungen bis hin zu öffentlichen Clouds und Endgeräten. Die eine IT-Infrastruktur gibt es ja nicht, und damit auch keine Lösung die alles gleich gut abdeckt, auch wenn der ein oder andere Hersteller gelegentlich das Gegenteil behauptet.
Im Folgenden soll daher anhand von drei Open-Source Programmen die einzelnen Schritte zur Umsetzung und deren Eigenschaften beschrieben werden. Der Fokus liegt dabei auf der Erstellung von VM’s in einer vSphere Umgebung. Die daraus abgeleiteten Erkenntnisse lassen sich dann auch auf andere Szenarien übertragen.
Ausgangsbasis dieser Lösung sind VM-Templates aus denen die neu zu erstellendenVM’s durch einen Clone Vorgang erzeugt werden. Das Template wird mit dem Programm „Packer“ erstellt, das nur eine minimale Grundinstallation eines Betriebssystems enthält. Zusätzlich enthält das Template ein Script, mit dessen Hilfe nach dem Clonen der VM, diese in Puppet integriert wird. Mehr dazu später. Zum Erstellen des Templates wird dabei Packer verwendet.
Die IaC Beschreibung der VM enthält einen Verweis auf ein Template aus dem die VM erzeugt wird, falls noch nicht vorhanden. Sobald die VM gestartet ist, wird das oben erwähnte Script ausgeführt. Dabei wird das System auf einen Stand gebrach, damit es den Puppet-Agent ausführen kann. Zusätzlich wird die VM an den Puppet Server angemeldet, so dass sie ab jetzt unter dessen Kontrolle steht. Sobald dies erfolgreich abgeschlossen ist, löscht sich das Script selbst. Im Fehler Fall wird es bei jeden Bootvorgang erneut ausgeführt.Der ganze Vorgang erfolgt durch einen Merge-Request, der OpenTofu ausführt.
Die VM steht in dieser Phase voll unter Kontrolle einer Puppet Umgebung. Der Puppet Agent ergänzt nun die VM mit zusätzlicher Software, integriert sie in eine AD, und passt die Konfiguration soweit an, dass sie der IaC Beschreibung entspricht. Ziel ist eine vollständig funktionale VM für den produktiven Einsatz, ohne manuelle Eingriffe.
Währen des gesamten Lebenszyklus muss eine VM auch immer wieder angepasst werden. Wird zum Beispiel mehr RAM benötigt, wird der Wert in der VM Beschreibung angepasst und die Änderung als Merge-Request verarbeitet. Analog erfolgt die Anpassung der Puppet Konfiguration (puppet hiera) mit anschließenden Merge Request.
Abschließend kann man konstatieren, dass IAC großes Potential für einen effizienten, nachhaltigen und sicheren IT-Betrieb hat. Auch aktuelle und zukünftige Anforderungen bezüglich Nachweispflichten bei Audits lassen sich damit wesentlich einfacher erfüllen. Dabei darf aber auch der technische und organisatorische Aufwand nicht unterschätzt werden. Abzuraten ist allerdings davon, einfach mal nebenbei IaC im Unternehmen einzuführen.
„*“ zeigt erforderliche Felder an
