Blaupausen für die IT-Infrastruktur – Infrastructure as Code mit Terraform & Azure

In der Cloud können sehr einfach und schnell neue Ressourcen wie virtuelle Maschinen, Storage Accounts und Web-Applikationen erstellt werden. Um die IT-Infrastruktur in der Cloud langfristig zu pflegen und zu verwalten, werden aber immer mehr Aufwände nötig. Schnell entsteht ein Chaos, wenn mehrere Personen daran arbeiten.

Was bringt Infrastruktur as Code?

Mit «Infrastructure as Code» (IaC) wird die Systemarchitektur in Konfigurationsdateien beschrieben.

Diese Dateien werden in einem Git Repository versioniert und historisiert, damit Änderungen nachvollzogen werden können.
Beispiel: Ein virtueller Server mit Namen, IP-Adressen und der Konfiguration von CPUs, RAM und virtuellen Festplatten wird beschrieben.
Mit «Pull Requests» können diese Änderungen von Kollegen geprüft und freigegeben werden – und werden erst danach auf die produktive Umgebung ausgerollt.
Beispiel: der Arbeitsspeicher wird erhöht – indem der Konfigurationswert angepasst wird. Diese Änderung wird vom Change Manager der Infrastruktur geprüft und anschliessend freigegeben.
Zusätzlich können automatische Prüfungen auf den Konfigurationsdateien ausgeführt werden, damit mögliche Konfigurationsfehler und Sicherheitslücken proaktiv gefunden und angepasst werden.
Beispiel: Auf dem Server sind Standard-Ports freigegeben, die nicht von aussen erreichbar sein müssen. Der Sicherheitsscanner schlägt vor, die Konfigurationsdatei anzupassen.

Fazit – Infrastruktur im Code ist empfehlenswert, da

Infrastruktur Komponenten können einfach «dupliziert» und neu erstellt werden.
Infrastruktur kann auf Knopfdruck erstellt und auch wieder gelöscht werden.
Änderungen sind nachvollziehbar und versioniert.
Änderungen können geprüft und freigegeben werden.

Wie funktioniert es (vereinfacht)

Die verschiedenen Komponenten der IT-Infrastruktur wie beispielsweise virtuelle Netzwerke, virtuelle Server, virtuelle Speichersysteme und andere Komponenten werden durch Textdateien in einem maschinenlesbaren Format beschrieben. Es gibt Vorlagen für die jeweiligen Typen.

Der System-Engineer erstellt die Konfigurationsdatei und definiert die benötigten Werte. Für nicht definierte Werte gelten die Standardwerte vom Cloud Anbieter oder Tool.

Alternativ kann auch die Konfiguration eines bereits existierenden Systems ausgelesen und in einer Konfigurationsdatei importiert werden. Dabei sind aber alle Konfigurationswerte ausgefüllt, das häufig zu vielen Informationen führt.

Mit dem IaC-Tool wird die Konfigurationsdatei geprüft. Etwaige Fehler oder Inkonsistenzen werden korrigiert. Ist alles korrekt, kann die Konfigurationsdatei auf die Umgebung angewendet und die Änderung durchgeführt werden.

Beispiel einer Azure Cosmos No-SQL Dokument-Datenbank und weitere Ressourcen mit Terraform

Beispiel einer Azure Cosmos No-SQL Dokument-Datenbank und weitere Ressourcen mit Bicep (als Modul)

Welche Technologien gibt es?

Es gibt verschiedene Lösungen, zu den bekanntesten zählen Pulumi und HashiCorp Terraform. Microsoft bietet mit ARM (Azure Resource Manager) und Bicep eigene Lösungen speziell für die Azure Cloudplattform an.

Die Technologien unterscheiden sich nach den unterstützten Cloud-Anbietern, der Lizenzierung und natürlich in der Funktionalität.

Für Multi-Cloud und herstellerübergreifende Infrastructure-as-Code ist Terraform von HashiCorp aktuell weit verbreitet. Wir setzen es in verschiedenen Kundenprojekten ein, um Infrastruktur auf Azure zu erstellen und zu verwalten.

Aufgrund von Lizenzanpassungen vom Hersteller HashiCorp, gab es im Jahr 2023 einen «Fork» mit dem Ziel, eine frei verfügbare (im Sinne von «open source» und freier Nutzung) Variante davon zu erstellen. Diese trägt den Namen OpenTofu und bietet ähnliche Funktionalität.

Beispiel – Kubernetes Cluster in bestehende On-Premises Umgebung integrieren

Für ein Kundenprojekt sollte in kurzer Zeit ein Kubernetes Cluster erstellt und ins bestehende On-Premises Netzwerk integriert werden.

Phase 0 – Initialisierung

Im Projektverlauf wurde Terraform evaluiert und eingeführt. Die Infrastruktur-Konfiguration wurde in einem git Versionsverwaltungssystem eingecheckt.

Änderungen von den verschiedenen Engineers konnten parallel durchgeführt, miteinander kombiniert, geprüft und anschliessend ausgeführt werden.

Phase 1 – Aufbau einer Testumgebung

Um den Aufbau ohne Beeinträchtigungen der normalen IT-Umgebung zu durchzuführen, wurde temporär eine separate Test-Umgebung auf Azure erstellt.

Schrittweise wurde die Infrastruktur aufgebaut:

Landing Zone in der Azure Umgebung mit VPN ins On-Premises Firmennetz und verschiedenen VLANs
Kubernetes Cluster (Azure Kubernetes Service) und die benötigten Firewall-Regeln
Umsysteme und weitere Komponenten

Die Änderungen wurden dann jeweils vom Cloud Architekt geprüft und mit dem bestehenden Infrastruktur-Code zusammengeführt.

Nach anschliessendem Sicherheitsreview konnten die Änderungen produktiv genommen werden.

Phase 2 – Go Live

Die produktive Umgebung wurde mit dem gleichen Code wie die Testumgebung erstellt. Die nicht mehr benötigte Testumgebung konnte anschliessend gelöscht werden.

Phase 3 – Änderungen im produktiven Betrieb

Gibt es Anpassungen aus dem laufenden Betrieb, wie beispielsweise neue Firewall-Regeln für Applikationen auf dem Kubernetes-Cluster, werden diese im Code beschrieben und separat getestet, mit 4-Augen-Prinzip geprüft und erst anschliessend auf die produktive Umgebung übernommen.

Zusätzlich wurden weitere Komponenten wie eine Container Registry sowie ArgoCD fürs Einspielen von neuen Container-Images im Kubernetes ergänzt.

Infrastructure-As-Code bei DevOps Entwicklung

Gerade im Kontext von DevOps – Entwicklung und Betrieb werden vom gleichen Team übernommen – spielt Infrastructure-as-Code die Vorteile aus.

Entwickler können die benötigte Systemkonfiguration selbst beschreiben und erstellen lassen. Änderungen sind automatisch sicht- und nachvollziehbar - und können vom Infrastruktur-Team geprüft werden.

Mit Helmcharts lässt sich auch die Infrastruktur wie Netzwerkverbindungen und Speicher in einem Kubernetes Cluster beschreiben und beispielsweise mit ArgoCD automatisch anwenden.

Auch diese Konfigurationsdateien werden «eingecheckt», versioniert und automatisch auf die Infrastruktur im Kubernetes-Cluster angewendet.

Infrastruktur-mit-Code für Multi-Cloud & Technologie-Neutralität

Ein wichtiges Kriterium in der Auswahl des IaC Tools ist, ob nur ein bestimmter Cloud Anbieter (wie Microsoft Azure oder Amazon Web Services) verwendet wird oder die Lösung für mehrere Cloud-Anbieter und Hersteller geeignet sein soll.

Terraform bzw. der Open-Source.Klon “OpenTofu” unterstützen verschiedene Public Cloud Anbieter wie Microsoft Azure, Google Cloud Platform (GCP) oder Amazon Web Services (AWS).

Relevant ist auch, ob vom jeweiligen Cloud-Anbieter alle benötigten Dienste unterstützt werden. Wird beispielsweise auf Azure ein neuer AI-Dienst von Microsoft veröffentlicht, muss der IaC-Anbieter diese Dienstleistung möglichst rasch implementieren.

Es gibt bei vielen Anbietern auch die Möglichkeit, beispielsweise über die API-Schnittstellen der Plattform nicht unterstützte Komponenten selbst zu erstellen.

Herausforderungen & Probleme

Die Konfigurationsdateien einer IT-Infrastruktur kann sehr schnell unübersichtlich werden. Es ist wichtig, dass die Module und Strukturierungsmöglichkeiten des Herstellers verwendet werden. Interne Namensrichtlinien und Vorgaben sollten definiert werden, damit die Infrastruktur einheitlich aufgebaut wird.

Es kann zu Inkonsistenzen zwischen den Konfigurationsdateien und der Realität kommen. Das kann manuelle Anpassungsarbeiten nach sich ziehen.

Eine kleine Änderung an der Infrastruktur über IaC kann langsamer und umständlicher sein, als die Änderung schnell direkt auf der Cloud Umgebung vorzunehmen.

Werden Teile der Infrastruktur von einem Cloud Anbieter und andere von einem bestehenden On-Premises System verbunden und getrennt administriert, gibt es bei hybrider IaC und klassischer Infrastruktur meist Abstimmungsprobleme.

Das kann beispielsweise ein virtueller Server aus der Cloud sein, der über eine VPN-Verbindung auf eine Datenbank der On-Premises-Umgebung zugreift.

Änderungen können unerwartete Auswirkungen haben. Hier ist es wichtig, klare Absprachen zu treffen, wer für welche Elemente zuständig und sauber zu kommunizieren.