Definition „Infrastructure as Code“ Was ist IaC?
Infrastructure as Code ist die Fortsetzung der Unix Philosophie mit DevOps-Mitteln. Das Administrationskonzept für IT-Infrastruktur macht die individuelle Installation und Konfiguration von Hard- und Software unabhängig von manueller Interaktion.
Anbieter zum Thema

Was bedeutet „Infrastructure as Code“?
Mit seiner Struktur und dem Kürzel IaC lehnt sich Infrastructure as Code an die im Cloud-Computing üblichen Begriffsbildungen wie SaaS und insbesondere IaaS an. Infrastructure as a Service beschreibt eine Form, Kunden bestimmte Computer-Ressourcen, also nach außen hin zur Verfügung zu stellen.
Infrastructure as Code hingegen bezieht sich auf die unternehmensinterne Organisation der Bereitstellung und Verwaltung entsprechender Ressourcen. Mit der Formulierung „as Code“ spezifiziert IaC eine bestimmte Sichtweise, die sich nicht unbedingt leicht erschließt.
Wie lässt sich ein System als Quelltext betrachten?
Der Schlüssel dazu sind spezielle Software-Werkzeuge, die Configuration Management Tools. Sie abstrahieren die konkrete Konfiguration einzelner Hardware- und Softwarekomponenten, sodass sich ihre Funktionen in allgemeiner Form definieren und auf unterschiedliche Installationen übertragen lassen.
Die Steuerung dieser Werkzeuge erfolgt allgemein mittels Programmiersprachen und ähnlichen Schnittstellen, die einer Bearbeitung und Verwaltung durch Werkzeuge der Software-Entwicklung offenstehen. Ein Fokus liegt dabei auch auf der Automatisierung der Konfigurationsprozesse.
Eine Werkzeugkategorie der DevOps-Toolchain
Der Begriff Infrastructure as Code (IaC) ist eng verknüpft mit DevOps. Dieses Konzept vereint Software-Entwicklung (Development) und Betrieb (Operations) zu einer Einheit, schließt also auch die Systemadministration mit ein.
Indem IaC die IT-Infrastruktur wie Code behandelt und dies durch geeignete Werkzeuge und Maßnahmen ermöglicht, macht das Konzept die Administration den üblichen Werkzeugen und Vorgehensweisen der Software-Entwicklung zugänglich, beispielsweise die Versionskontrolle. Das wiederum erleichtert die personelle Verknüpfung von Development und Operations zu DevOps. Im gängigen, siebenstufigen Modell der DevOps-Toolchain stellt IaC geeignete Werkzeuge für die sechste Phase, die Konfiguration bereit.
Welche Werkzeuge setzt IaC ein?
Das Cloud-Umfeld, die Virtualisierung und besonders Container-Architekturen wie Docker nutzen den Begriff Orchestrierung für den Prozess der Steuerung und Kontrolle der entsprechenden IT-Infrastruktur. Im Bereich der klassischen Systemadministration ist der Begriff Konfigurationsmanagement-Software für Orchestrierungstools der Cloud-Generation üblich.
Hierzu zählen beispielsweise Ansible, Chef, Salt und Puppet, aber auch ältere Werkzeuge wie CFEngine. Alle lassen sich für IaC einsetzen. Daran zeigt sich bereits, dass dieses Konzept nicht mit Cloud und DevOps aus dem Nichts entstanden ist, sondern seine Wurzeln in der Systemadministration hat.
Traditioneller Ansatz im neuen Gewand
Eine enge Beziehung zwischen Software-Entwicklung und Systemadministration hat gerade im Unix-Umfeld eine lange Tradition. Das Programmieren von Shell-Skripten und die Kenntnis von Skriptsprachen wie Perl oder Python gehören zum elementaren Handwerkszeug eines Systemadministrators. Üblich ist auch die Verwaltung von Konfigurationsdateien mit Versionskontrollsystemen.
Bis zur Einführung von Paketmanagement-Systemen in den 1990er-Jahren zählte zudem das Kompilieren von Anwendungsprogrammen oder sogar des gesamten Betriebssystems aus dem Quelltext zu den gängigen Aufgaben des Administrators. Weitere Ähnlichkeiten finden sich aber auch tiefer in den Konzepten.
Was haben IaC und die Unix-Philosophie gemeinsam?
Infrastructure as Code bevorzugt den Einsatz von Konfigurationsdateien, deren Inhalt von Maschinen direkt auswertbar ist, vor interaktiven Werkzeuge sowie physisch an Hardware-Komponenten vorzunehmenden Einstellungen.
Ähnliche Forderungen finden sich bereits in der ersten, 1978 von Doug Ilroy dokumentierten Version der Unix-Philosophie. Dort heißt es unter Punkt 2: „Don't insist on interactive input“ – „Bestehe nicht auf interaktive Eingaben.“ Auch Punkt 4: „Use Tools in preference to unskilled help to lighten a programming task“ – „Nutze Werkzeuge bevorzugt vor unerfahrener Hilfe, um eine Programmieraufgabe zu vereinfachen“ – lässt eine Präferenz für die Automatisierung erkennen.
Gemeinsamkeiten finden sich speziell auch in Punkt 3: „Design and build software, even operating systems, to be tried early“ – „Entwirf und baue Software sowie Betriebssysteme so, dass sie früh ausprobiert werden können.“; wenn sich auch die Interpretation von „early“ gewandelt hat. Hieß es 1978 noch „ideally within weeks“, erreichte die Einführung des DevOps-Konzepts 2009 bei flickr bereits 10 Auslieferungen am Tag.
Der „Continuous Delivery“-Ansatz verspricht sogar eine Softwarebereitstellung zu jedem beliebigen Zeitpunkt. IaC sichert in diesem Zusammenhang eine ausreichend schnelle und skalierbare Konfiguration der neu ausgelieferten Software, muss aber schon bei der Software-Entwicklung zumindest so weit berücksichtigt werden, dass der Einsatz durch das Softwaredesign nicht verhindert wird. Eine ausschließlich interaktiv konfigurierbare Applikation wäre beispielsweise unzugänglich für eine automatisierte Installation und Administration mittels Konfigurationsmanagementsoftware.
Kein DevOps ohne IaC – kein IaC ohne DevOps
Die Verknüpfung von Development und Operations für einen effizienteren Ressourceneinsatz erfordert Mittel, die eine Automatisierung von Bereitstellung und Management der IT-Infrastruktur ermöglichen. Geeignete Mittel sind in der Software-Entwicklung bereits vorhanden. Umgekehrt setzt die Interpretation von Infrastruktur als Quelltext eine enge Zusammenarbeit zwischen der Software-Entwicklung und dem Betrieb der IT-Infrastruktur voraus.
Einerseits muss das Betriebs-Team für die Bereitstellung und die Administration mit Werkzeugen der Software-Entwicklung vertraut sein. Andererseits die Entwicklung den Einsatz von Konfigurationsmanagement- und Automatisierungstools beim Software-Design vorsehen. Als Gewinn stellt die Umsetzung des Konzepts Infrastructure as Code gesteigerte Performance, Kostenreduktion und Risikominimierung durch den Ausschluss von Fehlerquellen in Aussicht.
(ID:45368704)