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.
(Quelle: sdecoret / shutterstock.com)
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 Archi­tect - 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 Be­ratungshaus 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

Starr oder veränderbar

Eine weitere Grundsatzentscheidung betrifft die Art der IaC-Infrastruktur, sprich ob sie variabel (mutable) oder unveränderlich (immutable) sein soll. Der Vorteil des variablen Ansatzes: Eine Entwicklungsabteilung kann beispielsweise die Parameter der IaC-Umgebung an geänderte Anforderungen anpassen, etwa indem sie einen Server mit mehr Rechenleistung oder ein Storage-System mit einer grösseren Speicherkapazität konfiguriert. Doch dies kann dazu führen, dass inkonsistente Versionen einer IT-Infrastruktur entstehen und der Aufwand für die Versionskontrolle steigt.
Daher greifen Anwender vorzugsweise zu einer immu­table IaC-Infrastruktur. Das heisst aber nicht, dass diese inflexibel ist. Denn Infrastructure as Code heisst, dass Nutzer bei Bedarf mit geringem Aufwand eine neue, angepasste Umgebung erstellen können. Bedingung ist, dass das Unternehmen Zugang zu Cloud-Technologien und Ansätzen wie Software-
defined Data Center hat: «IaC setzt die Cloud-Technologie voraus», betont Andreas Jaekel, Head of PaaS Development bei IONOS & Strato. «Wo eine Cloud zum Einsatz kommt, werden mit ziemlicher Sicherheit auch Virtualisierung und Software-defined Networking verwendet.»
“Nach unserer Erfahrung muss der Einsatz von Infrastructure as Code für Anwender keinesfalls eine Herausforderung darstellen oder gar abschreckend sein.„
Sohini Roy, Produktmanagerin bei Canonical

Auch für «normale» Data-Center

Infrastructure as Code ist jedoch nicht einer Public oder Private Cloud vorbehalten. «Ich selbst verwende IaC in einer abgemilderten Form auf meinem Notebook», berichtet beispielsweise Gerald Pfeifer von SUSE. «Es gibt keinen Grund, IaC auf eine Public Cloud zu beschränken.» Jede Infrastruktur im IT-Umfeld kommt seiner Einschätzung nach für diese Technologie infrage. Allerdings gibt es dabei einige Dinge zu beachten, betont Georg Ember von IBM: «Alles, was für Cloud-Computing entwickelt wurde, und dazu gehört IaC, lässt sich auch ‚On-prem‘, also in einem Firmen­rechenzentrum einsetzen. Das hängt aber von der verwendeten Hardware ab.» So kommen in Unternehmens-Data-Centern oft andere Systeme zum Einsatz als in einem Cloud-Rechenzentrum. 
Beispiele sind grosse virtuelle Server, virtualisierte Speichercontroller (SVC) und Tape-Technologien. «Will ein Unternehmen selbst entwickelte IaC-Konzepte durchgängig verwenden, also parallel im eigenen Data-Center und in einer Pu­blic Cloud, ist es ratsam, eine Software-definierte Ebene (SDE) zu verwenden. Diese kann von VMware stammen oder Red Hat kann sie mit OpenShift beisteuern.»
Die SDE sollte sich in beiden Umgebungen ähnlich verhalten und sich möglichst auf dieselbe Weise installieren und warten lassen.
Anbieter von Plattformen und Tools für Infrastructure as Code (Auswahl)
Anbieter Produkt Details
AWS AWS CloudFormation Tool für Modellierung und Implementierung von Infrastrukturressourcen in Clouds; Automatisierung durch Bereitstellung von Infrastruktur-Ressourcen in wiederholbarer Form; Bereitstellung von Ressourcen über mehrere Accounts und Regionen hinweg möglich; seit Mai 2020 in AWS CodeDeploy integriert, um inkrementelle Datenverkehrsmigrationsstrategie umzusetzen
AWC Cloud Development Kit (CDK) Software-Entwicklungs-Framework für die Definition von Software-Stacks und der dazugehörigen Hard-ware-Ressourcen; Support von Python, Java, Javascript, .NET, Typescript; CDK erzeugt aus dem Sourcecode ein Template für AWS CloudFormation
Canonical Cloud-Init Open-Source-Software für den Start von Services auf VM-Hosts in Cloud-Umgebungen; Beispiele: Einrichten von Directories, Nutzern und speziellen Software-Paketen; Automatisierung durch mehrfach verwendbare Workloads und Templates
Juju Implementierungs-Tool für Infrastruktur in Public und Private Clouds; Skripte, mit denen sich einzelne Infrastruktur-Komponenten implementieren lassen; inklusive rollenbasierter Zugriffskontrolle (RBAC); keine Software-Agenten nötig
Chef Chef Effortless Infrastructure Engine Tool für Configuration Management; integrierte Compliance- und Security-Funktionen, etwa Sicherheitstests; grosser Funktionsumgang, aber relativ komplexe Architektur; vor allem bei CI/CD-Fachleuten beliebt; Anbindung an andere IaC-Plattformen wie Terraform möglich
Google Google Deployment Manager Cloud-Service für die automatische Bereitstellung und das Management von IT-Ressourcen auf der Google Cloud Platform; Anforderungen, etwa bezüglich Datenbanken oder Servern, werden in Konfigurationsdatei definiert und mit Deployment Manager erstellt und verwaltet; Unterstützung von Confi Files (YAML) und Templates (Python, Jinja2); Funktion für Simulation der Auswirkungen von Implementierungen und Änderungen
Hashicorp Hashicorp Terraform IaC-Framework für automatisiertes IT-Ressourcenmanagement; Funktionen für Planung und Erstellen von IaC-Templates; weitreichende Automatisierungs- und Versionierungsfunktionen; Nutzung derselben Konfigurationen in unterschiedlichen Umgebungen; Basis: Hashicorp Configuration Language (HCL); kein Einsatz von Clients/Server erforderlich; unterstützt Cloud-Umgebungen aller Art
Packer Werkzeug, mit dem sich Virtual-Machine-Images erstellen lassen, inklusive aller Anwendungen, Libraries und Konfigurationseinstellungen; Einsatzfeld vor allem Erstellen von Images kompletter IT-Systeme
Vagrant Open-Source-Tool für Erstellen und Management von Virtual Machines; Einsatzgebiet: Software-Verteilung in Entwicklungsumgebungen; Basis sind deklarative Konfigurations-Files; ähnliche Vorgehensweise bei dem Aufsetzen von Docker-Containern
IBM IBM Cloud Schematics Bereitstellung der IaC-Plattform Terraform als Cloud-Service; auch Einsatz in Unternehmensrechenzentren möglich; Organisation von IBM-Cloud-Ressourcen mit Hilfe von Arbeitsbereichen, die mit Github-Repositories verbunden sind; Nutzung eigener IaC-Templates oder von Standard-Terraform-Vorlagen
IBM/Red Hat Ansible Management von Infrastrukturinstanzen in Cloud-Umgebungen mit Playbooks; diverse Orchestrierungsaufgaben (Einspielen von Hotfixes/Updates im laufenden Betrieb); Option, eigene Module zu entwickeln
Inedo Otter Tools für automatisierte Bereitstellung und Konfigurationsmanagement von Servern; Basis: mehrfach verwendbare Konfigurations-Templates; kontiniuierliches Prüfen von Servern auf Konfigurationsänderungen; Dashboard mit Überblick über Status aller Server; hohe Skalierbarkeit; Speicherung von Log-Daten für Audits
IONOS Cloud Data Center Designer Grafischer IaC-Editor für das Zusammenstellen eines virtuellen Rechzenzentrums in der IONOS-Cloud; Zusammenstellen von Infrastrukturkomponenten mittels Drag and Drop auf einem Whiteboard, etwa Servern, Storage, Firewalls, Switches und Load-Balancing-Systemen
Microsoft Azure Resource Manager Implementierungs- und Management-Service, der auf Azure-Services zugeschnitten ist; Option: Verwaltung von Ressourcen in Form von Gruppen statt als individuelle Infrastruktur-Services; Einsatz deklarativer Templates auf Basis von JSON anstelle von Skripten; zentrales Dashboard für Monitoring von Releases und Builds
Northern Tech CFEngine Tool für Konfigurationsmanagement mit langer Historie; unterstützt Verwaltung komplexer IT-Infrastrukturen; Compliance-Funktionen; sowohl als Open-Source- als auch kommerzielle Software verfügbar; automatisches Einspielen von Updates und Änderungen; basiert auf Software-Agents
Pulumi Pulumi SDK Open-Source-Tool (Software Development Kit) für Aufsetzen, Implementierung und Verwaltung von Infrastrukturressourcen in Cloud-Umgebungen; Unterstützung von Kubernetes, Containern und Serverless Computing; in Public, Private und Hybrid Clouds verwendbar; unterstützte Programmiersprachen: Node.js, Python, .NET Core, Go
Puppet Puppet Werkzeug auf Basis von Client-/Server-Modell für Konfigurationsmanagement; Software-Agenten auf Zielsystemen erforderlich; Überprüfung des Sicherheits- und Compliance-Status von Konfigurationen und der Auswirkung von Code-Änderungen; große Community
Saltstack Saltstack Enterprise Tools für automatisierte Verwaltung und Konfiguration von IT-Infrastrukturen; Basis: Python; erhältlich als kostenfreie Open-Source-Version und kostenpflichtige Enterprise Edition; Basis: Client-/Server-Modell; SSH-Modus für Betrieb ohne Software-Agenten; über Salt Cloud Unterstützung von IT-Ressourcen in Cloud-Umgebungen
SUSE SUSE Manager System- und Infrastrukturverwaltung für Linux-Systeme in Unternehmens-Data-Centern und Cloud-Umgebungen; Automatisierung von Bereitstellung, Patching und Konfiguration von Linux-Servern, Containern und Virtual Machines
Anbieter von Plattformen und Tools für Infrastructure as Code (Auswahl)
Anbieter Produkt Details
AWS AWS CloudFormation Tool für Modellierung und Implementierung von Infrastrukturressourcen in Clouds; Automatisierung durch Bereitstellung von Infrastruktur-Ressourcen in wiederholbarer Form; Bereitstellung von Ressourcen über mehrere Accounts und Regionen hinweg möglich; seit Mai 2020 in AWS CodeDeploy integriert, um inkrementelle Datenverkehrsmigrationsstrategie umzusetzen
AWC Cloud Development Kit (CDK) Software-Entwicklungs-Framework für die Definition von Software-Stacks und der dazugehörigen Hard-ware-Ressourcen; Support von Python, Java, Javascript, .NET, Typescript; CDK erzeugt aus dem Sourcecode ein Template für AWS CloudFormation
Canonical Cloud-Init Open-Source-Software für den Start von Services auf VM-Hosts in Cloud-Umgebungen; Beispiele: Einrichten von Directories, Nutzern und speziellen Software-Paketen; Automatisierung durch mehrfach verwendbare Workloads und Templates
Juju Implementierungs-Tool für Infrastruktur in Public und Private Clouds; Skripte, mit denen sich einzelne Infrastruktur-Komponenten implementieren lassen; inklusive rollenbasierter Zugriffskontrolle (RBAC); keine Software-Agenten nötig
Chef Chef Effortless Infrastructure Engine Tool für Configuration Management; integrierte Compliance- und Security-Funktionen, etwa Sicherheitstests; grosser Funktionsumgang, aber relativ komplexe Architektur; vor allem bei CI/CD-Fachleuten beliebt; Anbindung an andere IaC-Plattformen wie Terraform möglich
Google Google Deployment Manager Cloud-Service für die automatische Bereitstellung und das Management von IT-Ressourcen auf der Google Cloud Platform; Anforderungen, etwa bezüglich Datenbanken oder Servern, werden in Konfigurationsdatei definiert und mit Deployment Manager erstellt und verwaltet; Unterstützung von Confi Files (YAML) und Templates (Python, Jinja2); Funktion für Simulation der Auswirkungen von Implementierungen und Änderungen
Hashicorp Hashicorp Terraform IaC-Framework für automatisiertes IT-Ressourcenmanagement; Funktionen für Planung und Erstellen von IaC-Templates; weitreichende Automatisierungs- und Versionierungsfunktionen; Nutzung derselben Konfigurationen in unterschiedlichen Umgebungen; Basis: Hashicorp Configuration Language (HCL); kein Einsatz von Clients/Server erforderlich; unterstützt Cloud-Umgebungen aller Art
Packer Werkzeug, mit dem sich Virtual-Machine-Images erstellen lassen, inklusive aller Anwendungen, Libraries und Konfigurationseinstellungen; Einsatzfeld vor allem Erstellen von Images kompletter IT-Systeme
Vagrant Open-Source-Tool für Erstellen und Management von Virtual Machines; Einsatzgebiet: Software-Verteilung in Entwicklungsumgebungen; Basis sind deklarative Konfigurations-Files; ähnliche Vorgehensweise bei dem Aufsetzen von Docker-Containern
IBM IBM Cloud Schematics Bereitstellung der IaC-Plattform Terraform als Cloud-Service; auch Einsatz in Unternehmensrechenzentren möglich; Organisation von IBM-Cloud-Ressourcen mit Hilfe von Arbeitsbereichen, die mit Github-Repositories verbunden sind; Nutzung eigener IaC-Templates oder von Standard-Terraform-Vorlagen
IBM/Red Hat Ansible Management von Infrastrukturinstanzen in Cloud-Umgebungen mit Playbooks; diverse Orchestrierungsaufgaben (Einspielen von Hotfixes/Updates im laufenden Betrieb); Option, eigene Module zu entwickeln
Inedo Otter Tools für automatisierte Bereitstellung und Konfigurationsmanagement von Servern; Basis: mehrfach verwendbare Konfigurations-Templates; kontiniuierliches Prüfen von Servern auf Konfigurationsänderungen; Dashboard mit Überblick über Status aller Server; hohe Skalierbarkeit; Speicherung von Log-Daten für Audits
IONOS Cloud Data Center Designer Grafischer IaC-Editor für das Zusammenstellen eines virtuellen Rechzenzentrums in der IONOS-Cloud; Zusammenstellen von Infrastrukturkomponenten mittels Drag and Drop auf einem Whiteboard, etwa Servern, Storage, Firewalls, Switches und Load-Balancing-Systemen
Microsoft Azure Resource Manager Implementierungs- und Management-Service, der auf Azure-Services zugeschnitten ist; Option: Verwaltung von Ressourcen in Form von Gruppen statt als individuelle Infrastruktur-Services; Einsatz deklarativer Templates auf Basis von JSON anstelle von Skripten; zentrales Dashboard für Monitoring von Releases und Builds
Northern Tech CFEngine Tool für Konfigurationsmanagement mit langer Historie; unterstützt Verwaltung komplexer IT-Infrastrukturen; Compliance-Funktionen; sowohl als Open-Source- als auch kommerzielle Software verfügbar; automatisches Einspielen von Updates und Änderungen; basiert auf Software-Agents
Pulumi Pulumi SDK Open-Source-Tool (Software Development Kit) für Aufsetzen, Implementierung und Verwaltung von Infrastrukturressourcen in Cloud-Umgebungen; Unterstützung von Kubernetes, Containern und Serverless Computing; in Public, Private und Hybrid Clouds verwendbar; unterstützte Programmiersprachen: Node.js, Python, .NET Core, Go
Puppet Puppet Werkzeug auf Basis von Client-/Server-Modell für Konfigurationsmanagement; Software-Agenten auf Zielsystemen erforderlich; Überprüfung des Sicherheits- und Compliance-Status von Konfigurationen und der Auswirkung von Code-Änderungen; große Community
Saltstack Saltstack Enterprise Tools für automatisierte Verwaltung und Konfiguration von IT-Infrastrukturen; Basis: Python; erhältlich als kostenfreie Open-Source-Version und kostenpflichtige Enterprise Edition; Basis: Client-/Server-Modell; SSH-Modus für Betrieb ohne Software-Agenten; über Salt Cloud Unterstützung von IT-Ressourcen in Cloud-Umgebungen
SUSE SUSE Manager System- und Infrastrukturverwaltung für Linux-Systeme in Unternehmens-Data-Centern und Cloud-Umgebungen; Automatisierung von Bereitstellung, Patching und Konfiguration von Linux-Servern, Containern und Virtual Machines

Automatisiert, nachvollziehbar

Doch warum sollten sich Unternehmen überhaupt mit IaC beschäftigen? Handelt es sich tatsächlich um einen Ansatz, der Vorteile bringt? Eine klare Antwort darauf hat Kalki Rose, Cloud Architect bei der Digitalisierungsagentur Futurice. Er sieht in der Konzentration auf das Was statt das Wie durch Infrastructure as Code einen Vorteil. «Traditionell unterliegt die IT-Infrastruktur der Verantwortung spezialisierter Operations-Abteilungen, mit Experten für Netzwerke, Hardware, Software-Lizenzierung und -Verteilung sowie Sicherheit und Zugangsmanagement», so der Cloud-Spezialist. In Cloud-Umgebungen und der damit verknüpften Verwendung vorgefertigter Ser­vices sinke jedoch die Notwendigkeit, eine derart breite Expertise im eigenen Haus vorzuhalten. IaC gehe noch einen Schritt weiter: «Die Details verschwinden gewissermassen hinter wiederverwendbaren Bausteinen. Zusätzlich profitiert der Nutzer von Validierungs- und Dokumentationsmechanismen, der Nachvollziehbarkeit durch eine Versionskontrolle und vor allem von einem hohen Automatisierungs­potenzial.»
“Durch die hohe Flexi­bilität, die IaC bietet, lässt sich in Unternehmen eine Kultur des Experimen­tierens schaffen. „
Kalki Rose, Cloud Architect bei Futurice
Weitere Punkte führt Gerald Pfeifer von SUSE an: «Mit IaC erreichen wir Konsistenz und Reproduzierbarkeit, Skalierbarkeit und Agilität. Zusätzlich erleichtert die Technologie das Erstellen von Vorlagen und Richtlinien sowie deren gemeinsame Nutzung und Wiederverwendung.» Nutzer können zudem auf öffentlich zugängliche Anleitungen und Playbooks zugreifen, die sich an jeden Hypervisor oder die Infrastruktur von Cloud-Service-Providern anpassen lassen. Eine Quelle solcher Vorlagen ist beispielsweise Github. Auch innerhalb eines Unternehmens lassen sich solche «Kochrezepte» teilen und wiederverwenden.
Im Zeitalter der Digitalisierung, die wechselnde Anforderungen an IT-Ressourcen mit sich bringt, spielen ausserdem die Bereitstellungszeiten eine wichtige Rolle. Sie lassen sich laut IBM-IT-Architect Georg Ember verkürzen, wenn Systemtopologien bereits in Form von Vorlagen oder Code vorliegen. «Noch wichtiger ist, dass sich mit IaC alle Komponenten fehlerfrei, in der richtigen Reihenfolge, in der richtigen Version und für den richtigen Einsatzzweck bereitstellen lassen.» So können IT-Spezialisten etwa Virtual Machines für In-Memory-Datenbanken mit grossem Arbeitsspeicher ausstatten, VMs für Datenanalysen dagegen mit redundanten (Multipath) oder skalierbaren (Multi-Port) I/O-Adaptern.

Vorteil Testumgebung

Von den kürzeren Bereitstellungszeiten profitieren nicht zuletzt Software-Entwickler und -Tester: «Sie können mit Hilfe von Infrastructure as Code produktionsnahe Testumgebungen problemlos erstellen; die Implementierung solcher Umgebungen ohne Ausfall eines Services wird zur Norm», betont Kalki Rose von Futurice. Zudem werde das Risiko minimiert, dass ein System ohne entsprechende Dokumenta­tion modifiziert wird und damit nicht wiederhergestellt werden könne (Snowflake-Effekt). Dieser höhere Freiheitsgrad kann Rose zufolge dazu beitragen, die Agilität eines Unternehmens zu erhöhen: «Durch die hohe Flexibilität lässt sich eine Kultur des Experimentierens schaffen.»
In einigen Online-Foren wird als Nachteil von IaC der hohe Aufwand genannt, der mit der Verwaltung der Code-Versionen verbunden ist. Das Gegenteil sei der Fall, so Rose. Der Aufwand für Code-Management und Fehleranalyse sei bei IaC deutlich geringer als bei herkömmlichen IT-Systemen. «Manuelle Änderungen, die sich über Jahre ansammeln, können selten verlässlich reproduziert werden, es herrscht beinahe eine Art Angst, solche Systeme anzufassen.» Dagegen ermöglicht es Infrastructure as Code, eine lückenlose Aufstellung aller Anpassungen zu erstellen. Tritt ein Fehler auf, lässt sich bei IaC ein Service isolieren und untersuchen. «Innerhalb von Minuten kann der Nutzer auf eine funktionierende Version zurückspringen», betont Rose.

Geld und Zeit sparen

Doch Agilität hin, Digitalisierung her: Letztlich steht bei IaC der geschäftliche Nutzen im Vordergrund, findet Sohini Roy, Produktmanagerin bei Canonical, dem Unternehmen, das hinter der Linux-Distribution Ubuntu steht. «IaC hat sicherlich ein grosses Potenzial in vielen Bereichen. Doch der wahre Nutzen besteht darin, dass Unternehmen damit Geld und Zeit sparen können.» Dies setze aber voraus, dass sich das Konfigurationsmanagement von Infrastrukturkomponenten und Anwendungen von speziellen Hosting-Umgebungen entkoppeln lasse, etwa Private, Public und Hybrid Clouds, aber auch Unternehmensrechenzentren und Bare-Metal-Server-Systemen.
Bewerkstelligen kann man das Roy zufolge mit IaC-Tools wie Juju von Canonical. Solche DevOps-Lösungen, die einfach zu handhaben und zudem sicher sind, unterstützen Nutzer dabei, Anwendungen in jeder IT- und Cloud-Umgebung zu implementieren und zu verwalten. «Nach unserer Erfahrung muss der Einsatz von Infrastructure as Code für Anwender deswegen keinesfalls eine Herausforderung darstellen oder gar abschreckend sein», bekräftigt Sohini Roy.

Höheres Reparaturpotenzial

Doch wie bei jeder Technologie sind auch bei IaC einige Herausforderungen zu bewältigen. «Die grössten Gefahren bei diesem Ansatz lauern, wie so oft, beim Anwender selbst», erläutert Andreas Jaekel von IONOS. „Denn wenn man eine Infrastruktur automatisiert, dann kann man sie auch ‚automatisch‘ zerstören. Somit ist das Katastrophenpotenzial höher. Das gilt allerdings auch für das Reparaturpotenzial.»
Für einen sorgfältigen Umgang mit IaC plädiert auch Gerald Pfeifer von SUSE: «Natürlich erlaubt es IaC auch, sich mit gnadenloser Effizienz und Skalierbarkeit ‚ins eigene Knie zu schiessen‘. Im schlimmsten Fall verbreiten sich Konfigurationsfehler in Windeseile und zerschiessen möglicherweise die eigene Infrastruktur. Doch das kann auch durch Tippfehler von Administratoren passieren.» Sein Rat: Die Nutzer sollten Änderungen von IaC-Vorlagen testen und schrittweise ausrollen.
“Mit IaC erreichen wir Konsistenz und Reproduzierbarkeit, Skalierbarkeit und Agilität. Zusätzlich erleichtert die Technologie das Erstellen von Vorlagen und Richtlinien sowie deren gemeinsame Nutzung und Wiederverwendung.„
Gerald Pfeifer, Chief Technology Officer bei SUSE
Wichtig ist zudem, die Mitarbeiter frühzeitig in ein IaC-Projekt einzubeziehen, unterstreicht Kalki Rose. «Der Zeitersparnis bei der Implementierung neuer Services steht ein umfassender Paradigmenwechsel gegenüber. Dieser erfordert Trainings und eine Sensibilisierung der Beschäftigten.»

Fazit & Ausblick

Allein der wachsende Druck, IT-Ressourcen immer schneller nach Bedarf und weitgehend automatisch bereitzustellen, spielt Infrastructure as Code in die Hände. Hinzu kommt, dass Unternehmen in immer stärkerem Mass auf agile Entwicklungsmethoden und Cloud-Computing zurückgreifen. Beide Ansätze lassen sich bestens mit IaC kombinieren. Diese Faktoren tragen dazu bei, dass IaC in den kommenden Jahren an Boden gewinnen wird, und dies nicht nur bei Grossunternehmen und im gehobenen Mittelstand.
Gerade Start-ups und kleinere Firmen können dank Infrastructure as Code den Aufwand reduzieren, der mit dem Aufsetzen und dem Management von Cloud- und herkömmlichen IT-Infrastrukturen verbunden ist. Erste Gehversuche können Anwender mit Hilfe von Open-Source-Lösungen wie Terraform starten.
Problematisch ist jedoch, dass es bislang keine universellen IaC-Tools und -Plattformen gibt. Dies tangiert vor allem Nutzer von Multi-Cloud- und Hybrid-Cloud-Umgebungen. Denn die IaC-Lösungen der grossen Cloud-Service-Provider wie AWS, Microsoft und Google sind auf deren Cloud-Umgebungen zugeschnitten. Auch bei Infrastructure as Code sollten Anwender daher im Vorfeld prüfen, ob das Risiko besteht, sich von einem Anbieter abhängig zu machen. Denn dies würde zulasten der Flexibilität gehen, die Nutzer durch IaC gewinnen.
Tipps für die Implementierung von IaC
Infrastructure as Code kann die Aufgabe erleichtern, IT- und Cloud-Infrastruktur bereitzustellen und zu verwalten. Damit sich dieser Effekt einstellt, sollten Nutzer einige Regeln beachten.
IaC-Code wie klassischen Anwendungscode behandeln: Das gilt auch für den Test von neuen Versionen und Updates sowie die Dokumentation von Änderungen.
Auf Automatisierung setzen: Je weniger Handarbeit bei der Implementierung von IaC-Vorlagen und dem Einspielen von Updates anfällt, desto geringer ist die Fehlerquote.
Die Nachvollziehbarkeit von Änderungen sicherstellen: Dies lässt sich mit einer Versionskontrolle erreichen.
Sicherheits- und Compliance-Konzepte integrieren: Das erfordert beispielsweise Zugangs- und Berechtigungsregeln sowie eine regelmässige automatisierte Kontrolle.
Wartungsaufwand nicht unterschätzen: Anbieter stellen häufig neue Treiber, Firmware-Ausgaben und Releases bereit. Diese zu testen und in IaC-Templates einzupflegen, erhöht den Aufwand beim Betrieb von IT-Infrastrukturen, die mit IaC erstellt werden.
Gegebenenfalls nur eine begrenzte Zahl von Infrastruktur­topologien (small, medium, large) und Schnittstellen bereitstellen: Dadurch reduziert sich der Managementaufwand der Infrastrukturen.
Ein Monitoring etablieren: Es sollte alle Komponenten des Stacks berücksichtigen, also Hardware-Komponenten, Middle­ware, Container und gegebenenfalls Anwendungen.
Die Mitarbeiter mitnehmen: Ängste vor Kontrollverlust nehmen, Schulungen durchführen, die Beschäftigten für die Besonderheiten von IaC (Vorteile, aber auch Risiken) sensibilisieren.

Im Gespräch mit Lukas Höfer von Consol

Lukas Höfer: Cloud Solutions Architect bei Consol Software
Quelle: Consol
Die höhere Skalierbarkeit, Stabilität und Agilität sprechen für Infrastructure as Code, wenn ein Unternehmen neue Produktionsumgebungen entwickeln und implementieren möchte, erläutert Lukas Höfer, Cloud Solutions Architect beim Software- und Beratungshaus Consol Software.
Computerworld: Wie ist Infrastructure as Code im Zusammenhang mit Virtualisierung, Software-defined-Technologien und Cloud einzuordnen?
Lukas Höfer: Software-defined bedeutet, dass wir virtualisierte Hardware-Komponenten als Code definieren können. Und nichts anderes machen wir bei Infrastructure as Code. Ohne IaC wäre also 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.
Computerworld: Auf welche Nachfrage stösst Infrastructure as Code bei Anwendern, speziell in Deutschland?
Höfer: Bei unseren Kunden ist IaC ein grosses Thema. Ein Grund: Teilweise kann es schon helfen, sich vorgefertigter Templates zu bedienen, um schnell einen Prototyp auszurollen. Vor allem beim Aufbau einer Produktionsumgebung sind klar definierte Infrastruktur-Templates nicht zu ersetzen. Wenn alles exakt definiert ist und jede Komponente automatisiert bereitgestellt wird, lässt sich garantieren, dass jede Umgebung, von der Entwicklung bis zur Produktion, einheitlich ist; so werden stabile Produktionssysteme geschaffen. Und genau dies ist das Ziel unserer Kunden.
Computerworld: Welchen Mehrwert bringt Infrastructure as Code im Detail?
Höfer: Der Mehrwert zeigt sich deutlich, wenn man quasi per Copy and Paste innerhalb kurzer Zeit neue Systeme aufbaut. Im Vergleich dazu kann es aber sehr zeitraubend sein, Konfigurationen in Codes einzupflegen, die man mit wenigen Klicks im User Interface umsetzen könnte. Wir arbeiten allerdings häufig mit erfahrenen Kunden zusammen, die den Wert von Automation zu schätzen wissen. IaC bietet zudem vor allem Wiederholbarkeit: Wenn eine Task häufig identisch oder ähnlich ablaufen soll, lässt sich dies mit Code abbilden. Die Nutzung von Code bringt zudem mehr Stabilität im Vergleich zu einer manuellen Konfiguration. Und das führt letztlich dazu, dass man ein höheres Vertrauen in seine Infrastruktur und die darauf ausgeführten Deployments hat.
Computerworld: Für welche Anwendergruppen kommt IaC primär infrage?
Höfer: Klassischerweise stammt IaC ja aus dem IT-Betrieb, der die Infrastrukturbereitstellung und -wartung möglichst automatisiert und somit zeitsparend abwickeln möchte - und zwar nicht nur in der Cloud, sondern auch im klassischen Rechenzentrum. Aktuell boomt das Thema vor allem im Bereich DevOps, wodurch auch Entwickler sich immer mehr mit IaC auseinandersetzen müssen. So entstehen zum Beispiel neue IaC-Tools wie AWS SDK oder Pulumi, die es ermöglichen, die Infrastruktur in Sprachen wie Java oder Python abzubilden. Das kommt den Entwicklern sehr entgegen.
Computerworld: Kann IaC nur in Verbindung mit Cloud-Infrastrukturen eingesetzt werden oder funktioniert der Ansatz auch in Unternehmensrechenzentren?
Höfer: Manche Tools wie AWS CloudFormation oder AWS CDK oder auch Werkzeuge anderer Anbieter sind Provider-spezifisch. Anwendungen wie Terraform, Ansible oder Packer funktionieren aber mit einer Vielzahl von Virtualisierungs-Providern und werden schon lange On-Premise eingesetzt. Inzwischen gibt es auch die Möglichkeit, im eigenen Rechenzentrum auf Hardware der Cloud-Provider deren Tool-Stack auszuführen. Das lässt sich dann natürlich auch im eigenen Rechenzentrum mit deren IaC-Varianten managen.

Im Gespräch mit Martin Zeitler von Palo Alto Networks

Martin Zeitler: Director Systems Engineering Central Europe bei Palo Alto Networks
Quelle: Palo Alto Networks
Für Entwickler ist die Sicherheit ein zentrales Qualitätskriterium von Programmcode. Bei
In­frastructure as Code gilt das in besonderem Mass, weil fehlerhafte IaC-Vorlagen mit hohen Sicherheitsrisiken verbunden sind, warnt Martin Zeitler, Director Systems Engineering Central Europe beim IT-Security-Spezialisten Palo Alto Networks.
Computerworld: Herr Zeitler, Palo Alto Networks weist in seinem aktuellen «Unit 42 Cloud Threat Report» auf die Bedeutung von Sicherheitsregeln bei Infrastructure as Code hin. Wa­rum ist dieser Punkt so wichtig?
Martin Zeitler: Weil IaC-Templates, die Konfigurationsfehler enthalten, zu signifikanten Sicherheitsrisiken führen können. Das ist etwa der Fall, wenn ein Container-Template falsche Berechtigungen enthält, etwa Root-User anstelle eines Non-Root-Users. Ein weiteres Beispiel: Ein Entwickler erstellt mit Hilfe von Terraform eine Cloud-Umgebung. Darin wird jedoch der Netzwerkfilter, also beispielsweise die Network-Security-Group, nicht granular geöffnet. Das kann dazu führen, dass eine Datenbank für alle User offen im Internet erreichbar ist. Allgemein gesagt können solche Fehler dazu führen, dass IT-Systeme kompromittiert werden und Datenlecks auftreten.
Computerworld: Welche Fehler treten denn am häufigsten auf?
Zeitler: Laut dem Cloud Threat Report vom Frühjahr 2020 sind derzeit mehr als 199.000 unsichere IaC-Templates im Einsatz, mit Schwachstellen von mittlerem und hohem Schweregrad. Eine einzige Fehlkonfiguration reicht aus, um eine ganze Cloud-Umgebung zu kompromittieren. Erschwerend kommt hinzu, dass 43 Prozent der Cloud-Datenbanken nicht verschlüsselt sind und bei 60 Prozent der Cloud-Speicherdienste die Protokollierung deaktiviert ist. Dabei ist die Speicherprotokollierung von entscheidender Bedeutung, um das Ausmass des Schadens bei Cloud-Sicherheitsvorfällen zu bestimmen.
Computerworld: Wie lassen sich solche Risiken vermeiden?
Zeitler: Infrastructure as Code bietet Unternehmen den Vorteil, Sicherheitsstandards systematisch durchzusetzen. IT-Security-Teams haben beispielsweise dadurch die Möglichkeit, Sicherheit frühzeitig in den Software-Entwicklungsprozess einzubringen und in die Bausteine der Cloud-Infrastruktur eines Unternehmens einzubetten. So können Unternehmen im Rahmen eines Shift-Left-Ansatzes Entwicklern ermöglichen, in ihren integrierten Entwicklungsumgebungen (IDEs) IaC-Templates gegen Konfigurationsfehler einzusetzen. Aufgrund der Früherkennung lassen sich auf diese Art und Weise Fehler minimieren und deren Auswirkung deutlich begrenzen.
Computerworld: Könnten Sie kurz Shift Left erläutern?
Zeitler: Shift Left bedeutet, in der Software-Entwicklung frühzeitig den Aspekt Sicherheit mit einzubeziehen. Entwickler stehen diesem Ansatz durchaus nicht skeptisch gegenüber. Das Vorurteil, dass sich Entwickler nicht um Sicherheit kümmern, ist nachweislich falsch. Entwickler denken viel über die Software-Qualität nach. Wenn eine Shift-Left-Security-Strategie allerdings nur mit zusätzlicher Verantwortung einhergeht, wird sie wahrscheinlich nicht die Produktivität und den Workflow der Fachleute verbessern. Um eine Überlastung der Mitarbeiter zu vermeiden, muss nach unserer Meinung die Verschiebung des Sicherheitsansatzes von den «drei T» begleitet werden: Training, Tools und Teamwork.



Das könnte Sie auch interessieren