Früher wurde Infrastruktur manuell gemanagt. System-Admins konfigurierten die in einem Unternehmen benötigte Hard- und Software manuell. Mit dem Aufkommen von Cloud-Computing änderte sich der Job, es machte Ressourcen on demand verfügbar. Dadurch veränderten sich die Anforderungen an Systemadministratoren und deren Aufgaben fundamental.

Cloud-Computing-Angebote brachten eine dauerhafte Verfüg- und Skalierbarkeit von Ressourcen. Die Konfiguration fand größtenteils über interaktive Konfigurationstools statt – eine oder mehrere Personen nahmen Konfigurationsanpassungen manuell vor. Mit manuellen Anpassungen geht aber immer eine gewisse Fehleranfälligkeit einher, umso mehr, wenn mehr als eine Person involviert ist.

Infrastructure-as-Code wird manchmal als das fehlende Puzzleteil, mit dem Infrastrukturmanagement wirklich automatisiert werden kann, bezeichnet. Dev-Insider schreibt dazu: „Beim IaC-Prinzip abstrahieren Konfigurationsmanagement-Tools die Konfiguration einzelner Hardware- und Software-Komponenten.“

Infrastructure-as-Code beschreibt also die Praxis, eure Software-Laufzeit-Umgebung, die Netzwerkeinstellungen und -parameter in einem textbasierten Format zu beschreiben. Das heißt, Management und Bereitstellung von Ressourcen werden über maschinenlesbare Konfigurationsdateien automatisiert. Bekannte Konfigurations- und Orchestrierungstools sind zum Beispiel Terraform, AWS Cloudformation, Puppet, Chef, Saltstack, Ansible, Juju, Docker, Nix OS oder Azures Resource Manager. Welche ihr nutzt, ist abhängig vom jeweiligen Use-Case.

Nach dem IaC-Prinzip wird die Konfiguration der Infrastruktur eines Unternehmens in einem textbasierten Format beschrieben, deren Inhalt maschinell lesbar ist. Damit liegt die Konfiguration in Form einer Source-Code-Datei vor, die ihr ganz einfach – wie jeden anderen Code auch – editieren, kopieren und verteilen könnt. Von den damit einhergehenden Vorteilen profitiert aber nur, wer sich an die folgenden Best Practices hält.

Was wäre IaC ohne C? Haltet alle Infrastruktur-Spezifikationen in den Konfigurationsdateien fest – ausnahmslos, egal, ob die sich Ansible Playbooks, Chef Recipes oder AWS Cloud Formation Templates nennen. In diesen Dateien ist genau festgehalten, welche Cloud-Komponenten verwendet werden, wie sie zusammenhängen und wie die gesamte Umgebung konfiguriert ist. Im Idealfall führt das dazu, dass eure Infrastruktur schnell und nahtlos deployed werden kann – ohne dass irgendwer manuelle Anpassungen vornehmen muss.

Die Konfigurationsdateien sind eure Doku, die per Default immer up to date ist, deshalb solltet ihr im besten Fall keine weitere brauchen. Davon ausgenommen sind Setup-Anweisungen oder grafische Diagramme, die vielleicht benötigt werden, um zusätzliche Deployment-Prozesse festzuhalten. Die auf ein Minimum zu begrenzen, ist eine gute Idee – jede Doku, die ihr selber schreibt, müsst ihr auch selber updaten.

Diese Dateien könnt und solltet ihr in einem Version-Control-System eurer Wahl speichern und bei Bedarf versionieren. Dank Version-Control werden alle diese Operationen trackbar. Das heißt: Wie bei jedem anderen Software-Projekt auf GitHub, GitLab oder Bitbucket könnt ihr genau nachverfolgen, wer wann was wie geändert hat.

Prinzipien, die für die Entwicklung von Software funktionieren, lassen sich auch wunderbar auf euren Infrastruktur-Code anwenden. Konfigurations-Dateien sollten, wie jeder andere Code auch, verschiedene Tests durchlaufen – Unit-, Regressions- und Integrationstests zum Beispiel. Das könnt ihr natürlich nach Bedarf automatisieren, sodass mit jeder Änderung einer Datei ein Test getriggert wird. Auch aus Gründen der Security ist Testing und Monitoring eurer Infrastruktur ein Thema, das nicht außer Acht gelassen werden sollte.

Software, die aus kleinen, modularen Units besteht, und unabhängig von den restlichen Teilen einer Codebase deployed werden kann, kennt ihr – ganz großes Thema in der Software-Entwicklung. Das Konzept lässt sich auch auf IaC anwenden. Auch Infrastruktur-Code kann in einzelne separate Module oder Stacks zerlegt und automatisiert zusammengesetzt werden. So kann zum Beispiel Zugriff auf einzelne Komponenten geregelt werden. Eine modulare Infrastruktur reguliert zudem Tragweite der Änderungen, die an einzelnen Komponenten vorgenommen werden können – werden dabei Fehler gemacht, sind sie leichter zu finden und zu beheben.

Code, den ihr für euren Infrastruktur-Stack schreibt, sollte – nach Möglichkeit – einmal geschrieben, mehrfach verwendet und nicht verändert werden. Werden Konfigurationsänderungen nötig, zieht ihr nach dem Immutability-Konzept den kompletten Stack neu auf. So kann das Risiko einer sogenannten Konfigurationsverschiebung – gemeint ist eine Situation, in der verschiedene Server aufgrund verschiedener zu unterschiedlichen Zeitpunkten durchgeführter manueller Updates mit verschiedenen Konfigurationen und Versionen laufen – minimiert werden. Das vereinfacht die Suche nach etwaigen Fehlern und ist auch sicherheitstechnisch von Vorteil.

Zum Weiterlesen:

• Die besten Tools für die Automatisierung der IT-Infrastruktur
• Cloud-Hosting: Die wichtigsten Anbieter 2019 im Überblick
• Container-Virtualisierung: Docker und Kubernetes erfolgreich einsetzen