Ratgeber

Was ist eigentlich Infrastructure-as-Code und was müsst ihr dabei beachten?

(Foto: Verticalarray/Shutterstock)

Infrastructure-as-Code ist eines der Buzzwords, das im Zusammenhang mit Infrastruktur-Management mittlerweile zum Standard-Vokabular gehört. Was dahinter steckt und welche Best Practices dabei empfohlen werden. 

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.

Nix mehr verpassen: Die t3n Newsletter zu deinen Lieblingsthemen! Jetzt anmelden

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.

Dann kam IaC

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.

Best Practices

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.

Codify your Infrastructure – und zwar lückenlos

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.

Keine weitere Doku

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.

Version-Control nutzen

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.

Fortlaufende Tests sind Pflicht

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.

Modularität

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.

Immutabilität, wenn möglich

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:

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung