Infrastructure-as-Code: Automatisiert, sicher und fehlerfrei - warum es mehr ist als nur ein Buzzword
Wer sich mit IT Themen wie Provisionierung, GitOps, DevOps, DevSecOps, Kubernetes und co auseinandersetzt, fällt zwangsläufig irgendwann über das Thema “Infrastructure-as-Code”.
Nun ist es so, das hinter diesem Begriff deutlich mehr steckt, als man zum Anfang denkt.
Durch diese Erkenntnis stellt sich schnell die Fragen:
Was ist Infrastructure-as-Code (IaC) und wofür brauch ich das?
Was ist Infrastructure-as-Code (IaC)?
Infrastructure-as-Code (IaC) ist die Fähigkeit automatisiert IT-Infrastrukturen über Versionskontroll-Werkzeuge zu verwalten und bereitzustellen ohne das ein manueller Eingriff auf den jeweiligen Zielsystemen notwendig ist.
Mit wachsenden Anforderungen an die IT-Projekte, wachsen auch die Infrastrukturen. Somit erreicht man schnell den Zustand, dass viel Hardware vorliegt (Router, Switches, Server, IoT Edge Geräte, u.v.m.), welche schnell einen unterschiedlichen Zustand der Konfigurationen erhalten.
Diese Infrastrukturen manuell zu pflegen, Aktualisierungen vorzunehmen, Anpassungen an den Konfiguration vorzunehmen und vieles mehr ist ab einen gewissen Punkt viel zu kostenintensiv und zu fehleranfällig. Zudem kommt der Aspekt DevSecOps noch hinzu.
Was ist DevSecOps und was hat DevSecOps mit IaC zu tun?
Unter DevSecOps fallen viele Themengebiete. Im Kontext IaC wird der Fokus auf die Aspekte: Integrität, Nachverfolgbarkeit und Härtung gelegt.
Integrität und Nachverfolgbarkeit definiert, dass es einfach und schnell ersichtlich sein soll, wer welche Konfiguration auf welchem System angepasst oder abgelegt hat. Zudem soll klar sein in welchem Zustand sich welche Konfiguration befindet. Unter manueller Pflege ist dies ein enormer Aufwand um konkret herauszufinden, welche Zeile von welchem Nutzer, wie angepasst wurde.
Was hat nun Härtung mit dem Thema zu tun?
Mit Werkzeugen für Infrastructure-as-Code, wie zum Beispiel: Ansible oder Terraform, lassen sich klare Prozesse etablieren. Damit können dann die Nutzer konkret eingeschränkt werden, sodass diese nicht mehr irgendwelche Dateien anpassen können oder der gleichen. Dies führt direkt zu einer Härtung der Systeme. Sollte in Nutzer kompromittiert sein, so ist das System zwar gefährdet, jedoch nicht direkt schwerwiegend. Die Werkzeuge Ansible und Terraform erhalten ebenfalls entsprechende Nutzer, welche nur einen fest definierten Rahmen an Rechten erhalten.
Wo ist der Haken an Infrastructure-as-Code bzw. welche Nachteile habe ich mit Infrastructure-as-Code?
Grundlegend muss vorabgesagt sein, dass die Vorteile von Infrastructure-as-Code deutlich den Nachteilen überwiegen.
Die Nachteile von Infrastructure-as-Code sind überschaubar.
Nachteil: Fundiertes Wissen ist notwendig
Infrastructure-as-Code benötigt fundierte Kenntnisse über Werkzeuge wie Ansible, Terraform und der gleichen. Beide Werkzeuge haben eine gewisse Komplexität und benötigen entsprechend Zeit um sich mit den Themen auseinanderzusetzen.
Hier können Schulungen gut helfen die Themen besser zu vermitteln. Mit unserem Partner IT-Schulung.com führen wir entsprechende Schulungen durch.
Ansible: ▷ Ansible Seminar | Ansible Seminare | Ansible Schulungen
Terraform: ▷ Terraform Seminar | Terraform Seminare | Terraform Schulungen
Nachteil: Änderungen der Prozesse - Konfigurationen dürfen nicht mehr kurz auf dem System anpassen
Das System ist kurz ausgefallen oder man möchte einmal kurz was an einem Live System testen? Nun das sollte dann nicht mehr gemacht werden. Gerade wenn man etwas länger an den Systemen arbeitet um was zu testen, kann es schnell dazu kommen, dass mit einem neuen Rollout der Konfigurationen, entweder der Rollout Prozess gestört wird oder die Änderungen welche man testen will kurzerhand überschrieben werden.
Konfigurationen die man testen will muss man somit lokal auf seinem Computer durchführen oder an einem Gerät durchführen, welches nicht vom Rollout Prozess betroffen ist.
Zusammenfassung der Nachteile
Die Nachteile für den Einsatz von IaC sind primär Themen der persönlichen Umstellung und Fortbildung. Kurze “Quick-Fixes”, welche schnell einmal auf den Systemen gemacht werden, gehören somit der Vergangenheit an und dürfen somit nicht mehr durchgeführt werden, denn nichts hält länger als ein gutes Provisorium. Diese Nachteile sind technisch gesehen keine riesen Probleme und lassen sich zügig lösen.
Welche Vorteile habe ich durch Infrastructure-as-Code?
In kleinen Infrastrukturen können die Kosten der Implementierung die Vorteile schnell überwiegen, jedoch möchten wir gerne auf die nachfolgenden Vorteile aufmerksam machen. Die Vorteile bringen in den ersten Schritten keinen monetären Mehrwert. Diese sparen im Nachgang entsprechend Geld und entsprechenden Aufwand.
Vorteil: Integrität und Nachverfolgbarkeit
Infrastructure-as-Code muss immer zwingend mit einem Versionskontroll-Werkzeug verwendet werden, hierzu bietet sich GIT oder SVN an. Wir empfehlen klar GIT.
Durch die Verwendung eines Versionskontroll-Werkzeugs haben wir eine klare Einsicht, welcher Nutzer, welche Änderungen vorgenommen hat. Wurden die Git Commit Messages sauber und sinnvoll gepflegt, so ist auch erkenntlich, warum welche Änderung vorgenommen wurde.
Hier empfiehlt es sich eine konkrete Guideline aufzustellen, wie im Unternehmen oder im Projekt mit Git gearbeitet werden soll.
Sind die Benutzer auf den jeweiligen Systemen soweit korrekt eingestellt, dass diese entsprechende Dateien nicht anpassen können, so ist immer gewährleistet, dass die Änderungen in der Versionskontrolle der aktuelle IST-Zustand auf den jeweiligen Systemen ist.
Vorteil: Einfachere Verwaltung und Duplizierung
Durch die Verwendung einer Versionskontrolle muss nicht auf dem jeweiligen System die entsprechende Konfiguration gesucht werden. Die Konfigurationen sind alle schnell und einfach ersichtlich bzw zu finden. Somit kann Zeit gespart werden entsprechende Anpassungen vorzunehmen.
Des Weiteren können über ein Repository auch mehrere Systeme angesprochen werden, das heißt wir können die selben Konfigurationen auf verschiedene Systeme in einem Zug ablegen.
Durch entsprechende Möglichkeiten der Abstraktion lassen sich Konfigurationen sehr einfach soweit anpassen, dass generische Konfigurationselemente, welche für alle Systeme gleich gelten sollen, als Beispiel spezielle Content-Security-Policies (CSP) für Webserver, so ablegen, dass diese auf allen Servern entsprechend verteilt werden. Während wieder spezifische Konfigurationen, wie z.B. konkrete V-Host Konfigurationen mit Domain, SSL Zerifikat u.s.w., in einem dafür vorgesehenen Pfad abgelegt werden, sodass diese nur auf den gewünschten Server verteilt werden.
Dies spart für zukünftige Anpassungen der Infrastruktur Zeit und Geld. Es müssen somit nicht mehr mehrere Konfigurationen anpassen, sondern es müssen nur noch die generischen Konfigurationselemente angepasst werden und die Änderungen werden auf allen Servern direkt verteilt.
Vorteil: Automatisierung
Mit sog. CI/CD Pipelines, z.B. Gitlab-Runner, Jenkins oder Bamboo, können Prozesse automatisiert werden. Das heißt Änderungen welche in dem Repository der Versionskontrolle abglegt werden, werden von der Pipeline erfasst und nach vorgegebenen Prozessen entsprechend behandelt.
Diese Behandlung kann ein mehrstufiger Prozess sein oder auch ein relativ einfacherer Prozess in dem dieser die Änderungen lediglich auf die entsprechend konfigurierten Systeme transferiert und ggf. die Dienste neustartet.
Ein mehrstufiger Prozess, welchen wir im übrigen empfehlen, kann unter Umständen auch schon einige Prüfungen vornehmen. Hierbei können neben Code-Prüfungen auch Funktionale Prüfungen erfolgen. Als Beispiel: Webserver Konfigurationen lassen sich, bis zu einem gewissen Maße, mittels dem Werkzeug Goss innerhalb eines Docker Containers auf Funktionalität prüfen.
Ebenfalls können über weitere Plugins und eigene Bash-Skripte auch Security Checks durchführen um die Infrastruktur einem kurzen Checkup zu unterziehen.
Der jedoch wichtigste Aspekt des Vorteils ist es, dass der einzelne Nutzer die Änderungen nicht manuell auf alle Systeme transferieren muss. Auch hier kann der Automatismus dem Nutzer unter die Arme greifen und entsprechend dafür sorgen, dass die Änderungen auf alle ihm bekannten Systeme transferiert werden.
Vorteil: Härtung
Kein System ist zu hundertprozentig sicher, immer wird es Lücken und Möglichkeiten geben. Als Betreiber von IT-Systemen ist das natürlich ärgerlich und unschön. Was wir als Betreiber von solchen Systemen also machen müssen, sind folglich die “Goldenen Regeln der Berechtigungen” zu beherzigen. Das heißt im Klartext, nur der, welcher zwingend ein Zugang zum jeweiligen System braucht, bekommt einen entsprechenden Zugang und das auch direkt nur mit den minimalsten Berechtigungen. Nicht jeder muss Lesen, Schreiben und Ausführen. Oft reicht auch einfach nur Lesen.
Mit Infrastructure-as-Code können wir allen Nutzern auf Produktive Systeme, die Berechtigung zum Schreiben und Ausführen nehmen und lediglich die Berechtigung zum Lesen lassen, denn das Schreiben, das platzieren der Änderungen, sowie das Ausführen gewisser Operationen und Systeme überlassen wir ganz dem Nutzer, welcher für unser Infrastructure-as-Code-Werkzeug gedacht ist.
Dank der Möglichkeit mit der Automatisierung können wir sogar ein Schritt weitergehen und vielen den Zugang in Gänze nehmen. Der einzige, welcher einen Zugang benötigt, ist der Nutzer für unser Infrastructure-as-Code-Werkzeug.
Je weniger Zugang zum System haben, desto weniger Nutzer können kompromittiert werden und eine pot. Gefahrenquelle darstellen.
Vorteil: Weniger Fehler
Sofern ein adäquater Prozess zur Code-Review und ggf. zum automatisiertem Testen der Konfigurationen etabliert wurde, kann mit Infrastructure-as-Code schnell Fehler merklich die Anzahl an Fehlern reduziert werden. Hierbei geht es nicht darum die entsprechenden DevOps Entwickler:innen unter Generalverdacht zu stellen, jedoch sind Fehler menschlich und sollten wenn möglich so gering wie möglich ausfallen.
Durch entsprechende Werkzeuge, welche vorab, bevor die Änderungen auf dem jeweiligen Server abgelegt und danach ausgeführt wird, auf Plausibilität und Funktionalität geprüft wird, kann entsprechende Ausfälle und Probleme erheblich reduzieren.
Zusammenfassung der Vorteile
Auch wenn Infrastructure-as-Code in kleinen Infrastrukturen anfangs mehr Aufwand und Kosten bedeutet, bietet sie langfristig entscheidende Vorteile. Zunächst steigert sie Integrität und Nachverfolgbarkeit, da Änderungen über Versionskontrolle wie Git klar dokumentiert und nachvollziehbar werden. Mit entsprechenden Guidelines und Benutzerrechten spiegelt der Versionsstand immer den aktuellen IST-Zustand wider.
Zudem erleichtert sie die Verwaltung und Duplizierung von Konfigurationen: Alle Einstellungen sind zentral verfügbar, generische Elemente lassen sich für alle Systeme verteilen, während spezifische Anpassungen gezielt abgelegt werden. Das spart Zeit und Aufwand bei zukünftigen Anpassungen.
Ein weiterer Pluspunkt ist die Automatisierung: CI/CD-Pipelines können Änderungen automatisch prüfen, testen und ausrollen, inklusive Security-Checks und Funktionstests. So entfällt die manuelle Pflege auf allen Systemen.
Härtung der Systeme wird erleichtert, da Nutzern nur die minimal nötigen Berechtigungen eingeräumt werden, während Infrastructure-as-Code-Werkzeuge Schreib- und Ausführungsrechte übernehmen.
Schließlich reduziert Infrastructure-as-Code Fehler, da Code-Reviews und automatisierte Tests die Anzahl menschlicher Fehler deutlich senken und Ausfälle vermeiden helfen.
Wie funktioniert Infrastructure-as-Code?
Infrastructure-as-Code beschreibt genauso wie gängiger Softwarecode Funktionsweisen und Architekturen. Unter Infrastructure-as-Code ist natürlich der Blick ein anderer, während wir in der Software-Entwicklung uns auf Architekturen wie Event-Driven-Design oder der gleichen fokussieren, ist unter Infrastructure-as-Code natürlich mit der Architektur eine andere gemeint. Hier beziehen wir uns auf Architekturen wie Single-Node (Einzelne Software ohne Replikation und Hochverfügbarkeit) oder Multi-Node (Cluster Betrieb - Replikation und Hochverfügbarkeit inklusive), solche Multi-Node Infrastrukturen erreichen schnell eine gewisse Komplexität und sollten somit umgehend in entsprechenden Repositories abgelegt werden.
Das heißt, wenn Änderungen an einer Infrastruktur vorgenommen werden sollen, so muss die Änderungen in das dafür vorgesehene Repository geschrieben und auf den jeweiligen Versionskontroll-Server transferiert werden. Sobald dies getan wurde, greift die entsprechende CI/CD Pipeline, welche dann vordefinierte Prozesse vornimmt, z.B. Statische Code Analyse um pot. Fehler in der Schreibweise zu ermitteln.
Mit der Ausführung der Werkzeuge, Ansible oder Terraform werden die Änderungen auf das jeweilige Zielsystem transferiert und der Dienst, sofern es so konfiguriert wurde, wird entsprechend neugestartet, sodass die Änderungen wirksam werden.
Beide Werkzeuge können deutlich mehr als Konfigurationen an definierte Orte ablegen und Dienste neustarten. Wir betrachten in diesem Blog-Beitrag jedoch nicht die konkreten Funktionsweisen der beiden Werkzeuge.
Nach erfolgreichem Neustarten der Dienste können noch Aufräum-Aktionen vorgenommen werden, wie z.B. Cache Ordner oder Log Ordner leeren um ein sauberes System zu erhalten.
Ansätze von Infrastructure-as-Code
Wenn wir von der Entwicklung von Infrastructure-as-Code Strukturen reden, müssen wir auch die uns die entsprechenden Ansätze genauer anschauen.
Grundlegend gibt es für Infrastructure-as-Code zwei Ansätze.
Deklarativ
Der Deklarative Ansatz ermöglicht es dass lediglich die Ressourcen und Einstellungen beschrieben werden um den konkreten Endzustand zu erhalten. Das bedeutet Werkzeuge wie Ansible stellen, wie ein Framework, Funktionen zur Verfügung, welche genutzt werden können um z.B. gewisse Dienste zu installieren oder zu verwalten. Das heißt der Deklarative Ansatz beschreibt nicht im einzelnen was gemacht werden muss um den jeweiligen Zustand zu erhalten, sondern dieser beschreibt eine grobe Struktur und Werkzeuge wie Ansible setzen dies aus den verwendeten Funktionen eigenständig zu einem Imperativen Ansatz zusammen.
Imperativ
Der Imperative Ansatz beschreibt konkret welche Schritte gemacht werden müssen um den Zustand zu erreichen. Das heißt wir definieren die konkreten Befehle welcher nach einander ausgeführt werden sollen, z.B. ssh my-user@my-server.my-tld && apt install nginx .
Zusammenfassung
Der Imperative Ansatz ist gerne mal Komplex und unübersichtlicher als der Deklarative Ansatz. Jedoch kann es gerne mal dazu kommen, dass der Imperative Ansatz notwendig ist, denn bei der Bereitstellung von Infrastrukturen kommt es nicht nur darauf an, was konkret gemacht wird, sondern auch wann was in welcher Reihenfolge ausgeführt wird. Werkzeuge wie Ansible und Terraform unterstützen grundlegend beide Ansätze und können auch in Kombination, bis zu einem gewissen Grad, verwendet werden.
Welche Rolle spielt Infrastructure-as-Code in DevOps?
Der Prozess DevOp ist im allgemeinen dafür gedacht, dass die Zusammenarbeit zwischen Softwareentwicklungs- und IT-Betriebsteams kontinuierlich verbessert wird. Dabei ist das primäre Ziel, den Lebenszyklus der Anwendungsentwicklung zu verkürzen und die kontinuierliche Bereitstellung hochwertiger Software zu gewährleisten. DevOps-Teams integrieren Betriebsaktivitäten mit Entwicklertools und Code-Commits, sodass Anwendungen extrem schnelle Release-Zyklen haben können.
Somit ist klar definiert, dass Automatisierungen notwendig sind um die entsprechenden Ziele zu erreichen. Die Automatisierung kann jedoch grundlegend nur erfolgen, wenn auch der dahinter liegende Code entsprechend strukturiert ist und es entsprechend erlaubt.
Im allgemeinen nutzen DevOps-Teams Infrastructure-as-Code für verschiedene Zwecke:
- Komplette Umgebungen schnell einrichten, von der Entwicklung bis zur Produktion
- Für konsistent reproduzierbare Konfigurationen zwischen Umgebungen sorgen
- Nahtlos in Cloud-Anbieter integrieren und die Infrastrukturressourcen je nach Bedarf effizient nach oben oder unten skalieren
Zusammenfassung
Infrastructure-as-Code ist mehr als nur ein Buzzword. Infrastructure-as-Code ist die gemeinsame Sprache für Softwareentwickler und den Betrieb. Mit Infrastructure-as-Code lassen sich zügig Infrastrukturen und Softwares ausliefern, sodass die Release-Zyklen massiv reduziert werden können. Infrastructure-as-Code ist ein unverzichtbarer Teil der Informatik. Ob es interne Infrastrukturen wie Router, Switches, IoT Edge Geräte oder der gleichen sind oder ganze Software-Lösungen in der Cloud, mit Infrastructure-as-Code lässt sich all dies abstrahieren und effizient verwalten - vorausgesetzt das notwendige Wissen ist vorhanden.