Virtualisierung
26.08.2020, 05:59 Uhr
Coden statt konfigurieren
Mit Infrastructure as Code (IaC) wird die IT-Infrastruktur per Software bereitgestellt. Unterschieden wird bei IaC zwischen mehreren Varianten: imperativ, deklarativ und intelligent.
Programmieren und Skripte erstellen statt implementieren und konfigurieren. Das ist, vereinfacht gesagt, der Unterschied zwischen Infrastructure as Code (IaC) und der bislang üblichen Vorgehensweise beim Konfigurieren von IT-Systemen. «IaC bietet die Möglichkeit, Server, Storage und Netzwerke automatisch und damit auch qualitätsgesichert bereitzustellen», präzisiert Georg Ember, Certified IT Architect - Hybrid Cloud Solutions bei IBM. Eine Schlüsselrolle spielen dabei Ansätze wie Software-defined Data Center (SDDC) oder Software-defined Networking (SDN).
«Software-defined bedeutet, dass wir virtualisierte Hardware-Komponenten als Code definieren können. Und nichts anderes machen wir bei Infrastructure as Code», erklärt Lukas Höfer, Cloud Solutions Architect beim Münchner Beratungshaus Consol Software. «Ohne IaC wäre die Cloud, wie wir sie kennen, gar nicht möglich. Denn auch dort läuft im Hintergrund nahezu alles virtualisiert und das Deployment erfolgt mittels wiederholbarer Skripte, um Skalierbarkeit und Stabilität zu erreichen.»
“Mit Infrastructure as Code lassen sich alle Komponenten fehlerfrei, in der richtigen Reihenfolge, in der richtigen Version und für den richtigen Einsatzzweck bereitstellen. „
Georg Ember, Certified IT Architect Hybrid Cloud Solutions bei IBM
In der Praxis bedeutet dies, dass ein Software-Entwickler oder ein Fachmann aus dem Bereich Operations die IT-Infrastruktur, die eine Anwendung benötigt, in Form von Software definiert. Die Hardware-Anforderungen werden dabei in maschinenlesbarem Code abgebildet. In einem Skript oder Template ist aufgeführt, welche Server, Betriebssysteme, Storage-Ressourcen und Netzwerkverbindungen für eine Applikation bereitgestellt werden müssen. Über Programmierschnittstellen (APIs) spricht der Code diese Ressourcen an und reserviert sie quasi für die Applikationsumgebung. Ein Administrator muss somit nicht von Hand Server, Netzwerk-Switches und Speichersysteme inklusive der dazugehörigen Middleware konfigurieren.
Mehrere Varianten
Es gibt drei Stufen von Infrastructure as Code, erläutert Gerald Pfeifer, Chief Technology Officer (CTO) des Software-Unternehmens SUSE:
imperativ (prozedural): eine klassische Schritt-für-Schritt-Beschreibung wie ein Kochrezept
deklarativ: eine Beschreibung des erwünschten Zustands, unabhängig von den erforderlichen Schritten dorthin
intelligent: eine abstrakte Beschreibung von Zielen und Hintergründen.
«Die Entwicklung konzentriert sich derzeit auf die Optimierung deklarativer Methoden und geht verstärkt in Richtung intelligenter Systeme», so Pfeifer.
Um IaC-Vorlagen zu erstellen, können IT-Fachleute auf diverse Werkzeuge, Cloud-Services und Frameworks zurückgreifen. Bei deklarativen Tools und Plattformen wie Terraform, Salt und Puppet legt der User fest, welche IT-Infrastruktur erstellt werden soll. Das Framework ermittelt selbstständig, wie es diese Vorgaben umsetzen kann.
Zu den klassischen imperativen Werkzeugen zählen, neben Lösungen wie Chef und Ansible, Kommandozeilen-Tools, die jedem Administrator und Software-Entwickler vertraut sind. Microsoft bietet beispielsweise für das Konfigurieren von Infrastrukturkomponenten in seiner Azure-Cloud Lösungen an wie Azure CLI (Command Line Interface) und Azure Powershell. Der Fachmann erstellt damit Skripte, die in der vorgegebenen Reihenfolge abgearbeitet werden.
Im Vergleich zu deklarativen Tools kann bei imperativen Werkzeugen der Aufwand steigen, wenn eine IT-Infrastruktur erweitert oder angepasst werden muss, Stichwort Skalierbarkeit. Bei der deklarativen Variante erfolgt das automatisch. Daher gilt es im Vorfeld sorgfältig abzuwägen, welche Anforderungen die Nutzer an eine IT-Infrastruktur stellen und wie oft diese angepasst werden muss. Zudem sollte geprüft werden, ob Skripte weiterverwendet werden sollen, die aus der Zeit vor der Einführung von IaC stammen.
Vor- und Nachteile von Infrastructure as Code
Vorteile | Nachteile |
Automatisierung der Bereitstellung von Infrastrukturkomponenten | In manchen Fällen hoher Wartungsaufwand des Codes, speziell bei komplexen Templates oder einer grossen Zahl von Vorlagen |
Kurze Bereitstellungszeiten, speziell in grossen IT-Umgebungen | IT-Infrastrukturspezialisten verfügen möglicherweise über unzureichende Expertise in den Bereichen Programmieren und Entwicklungs-Tools |
Hohe Skalierbarkeit – von einem bis hin zu mehreren Hundert Servern | Software-Spezialisten benötigen Fachwissen auf Feldern wie Netzwerke, IT-Sicherheit, Disaster Recovery und so weiter |
Möglichkeit, IT-Infrastruktur in verteilten Teams zu entwickeln. Voraussetzung: strikte Versionskontrolle | Potenziell hoher Aufwand bei der Einarbeitung in Code, den andere Fachleute erstellt haben |
Wiederverwendbarkeit von IaC-Templates | Erhöhter Aufwand beim Übergang vom manuellen Infrastrukturmanagement zu IaC |
Weniger Fehler und Sicherheitslücken durch Reduzierung manueller Konfigurationsvorgänge | Umsetzung der Integration in vorhandene CI/CD-Pipelines |
Option, IaC in CI/CD-Pipelines einzubinden | Fehlfunktionen, wenn an der IT-Infrastruktur Änderungen vorgenommen wurden. Dies lässt sich teilweise durch „Selbstheilungsmechanismen“ der IaC-Tools beheben |
Vor- und Nachteile von Infrastructure as Code
Vorteile | Nachteile |
Automatisierung der Bereitstellung von Infrastrukturkomponenten | In manchen Fällen hoher Wartungsaufwand des Codes, speziell bei komplexen Templates oder einer grossen Zahl von Vorlagen |
Kurze Bereitstellungszeiten, speziell in grossen IT-Umgebungen | IT-Infrastrukturspezialisten verfügen möglicherweise über unzureichende Expertise in den Bereichen Programmieren und Entwicklungs-Tools |
Hohe Skalierbarkeit – von einem bis hin zu mehreren Hundert Servern | Software-Spezialisten benötigen Fachwissen auf Feldern wie Netzwerke, IT-Sicherheit, Disaster Recovery und so weiter |
Möglichkeit, IT-Infrastruktur in verteilten Teams zu entwickeln. Voraussetzung: strikte Versionskontrolle | Potenziell hoher Aufwand bei der Einarbeitung in Code, den andere Fachleute erstellt haben |
Wiederverwendbarkeit von IaC-Templates | Erhöhter Aufwand beim Übergang vom manuellen Infrastrukturmanagement zu IaC |
Weniger Fehler und Sicherheitslücken durch Reduzierung manueller Konfigurationsvorgänge | Umsetzung der Integration in vorhandene CI/CD-Pipelines |
Option, IaC in CI/CD-Pipelines einzubinden | Fehlfunktionen, wenn an der IT-Infrastruktur Änderungen vorgenommen wurden. Dies lässt sich teilweise durch „Selbstheilungsmechanismen“ der IaC-Tools beheben |