Cloud-Infrastrukturen mit HashiCorp Terraform verwalten
Von Wolken und Strukturen
In komplexen Cloud-Umgebungen ist es nicht trivial, IT-Infrastrukturen bereitzustellen. DevOps, Infrastructure as Code und Provisioning-Tools sind zentrale Hebel für ein effektives Vorgehen. Mit Terraform lassen sich sogar Multi-Cloud-Architekturen verwalten.
Seit Jahren wachsen in vielen IT-Abteilungen die beiden klassischen Rollen IT-Operations (Betrieb) und Software Development (Softwareentwicklung) immer stärker zusammen. Die Gründe hierfür ergeben sich in erster Linie aus dem Wunsch, die eigene Software schneller, stabiler und zuverlässiger auszuliefern und den Kundenanforderungen besser zu entsprechen. Verkürzte Releasezyklen schaffen zudem einen Wettbewerbsvorteil. Die daraus hervorgegangene DevOps-Kultur hat das Ziel, Software von der Erstellung bis zur Auslieferung in einem kontinuierlichen Lifecycle abzubilden (Continuous Integration und Continuous Delivery, CI/CD). Dazu stehen dem DevOps-Team verschiedene Werkzeuge bereit. Die Provisionierung und Konfiguration der Server, virtuellen Maschinen oder Container erfolgt beispielsweise mithilfe einer Konfigurationsmanagementsoftware. Dabei installiert und konfiguriert das DevOps-Team Betriebssystem und Software nicht mehr händisch. Es definiert stattdessen den gewünschten Zielzustand im Quellcode. Dieses Vorgehen ist auch als Configuration as Code bekannt.
Der Rollout in die gewünschte Umgebung läuft automatisiert ab – die Anbindung an eine CI-/CD-Pipeline vorausgesetzt. Das verbessert die Nachvollziehbarkeit und reduziert das Risiko für sogenannte Configuration Drifts. Das bedeutet: Konfigurations- und Patchstände einzelner Server weichen untereinander nicht ab. Bekannte Konfigurationsmanagementlösungen sind neben Chef und Ansible insbesondere SaltStack und Puppet. Allerdings müssen DevOps-Teams die zugrunde liegenden IT-Infrastrukturkomponenten wie Server, Router, Switches oder Firewall weiterhin manuell bereitstellen. Es gibt Ansätze, dies mit Software-defined Networking, Software-defined Data Center oder hyperkonvergenten Infrastrukturen zu automatisieren. In der breiten Masse sind diese Systeme jedoch noch nicht angekommen. Der Research-Spezialist IDC schätzt, dass im globalen Maßstab lediglich 20 Prozent der Unternehmen über ein Software-defined Data Center verfügen (siehe ix.de/ix1902128).
Automatisierte Bereitstellung mit IaC
Nutzen Unternehmen Public-Cloud-Ressourcen, müssen sie in der Lage sein, die Infrastruktur auch ohne physischen Zugriff zu provisionieren. Dafür kommen idealerweise Provisioning- beziehungsweise Infrastructure-as-Code-Tools (IaC) zum Einsatz. Ein bekannter Vertreter dieser Softwaregattung ist HashiCorp Terraform. Im Gegensatz zu Konfigurationsmanagementsystemen ermöglichen IaC-Tools die Bereitstellung ganzer (Cloud-)Infrastrukturen.
Dafür beschreibt das DevOps-Team den gewünschten Zielzustand der Umgebung in sogenannten IaC-Templates, die alle für den Betrieb notwendigen Komponenten beinhalten. Für die Cloud wären das typischerweise Instanzen, Netzwerkkomponenten, Datenträger oder die Benutzerverwaltung. Ergänzend sind spezielle, durch den Cloud-Provider verwaltete Dienste wie Datenbankserver direkt mit provisionierbar.
Die strukturierte Beschreibung der IT-Landschaft über IaC-Tools dient gleichzeitig der Dokumentation und Nachvollziehbarkeit. Zudem hilft sie, sogenannte Environment Drifts zu vermeiden, da die IaC-Templates reproduzierbar gleiche Umgebungen aufbauen. Um die IaC-Templates einfach zu verwalten, bietet sich ein Softwareversionsverwaltungssystem wie Git an.
IaC-Tools im Vergleich
Mittlerweile stellen die meisten Cloud-Anbieter ihren Kunden eigene, plattformspezifische IaC-Lösungen bereit. Terraform agiert dagegen als unabhängiges Tool, das über die reine Provisionierung der Cloud-Ressourcen hinausgeht. Plattformspezifische IaC-Tools wie Amazons AWS CloudFormation oder Microsofts Azure-Resource-Manager-Vorlagen stoßen teilweise an ihre Grenzen: So unterstützen sie beispielsweise keine Multi-Cloud-Architekturen. Die Adaption einer bestehenden Architektur an einen anderen Cloud-Provider erhöht damit den Einarbeitungs-, Verwaltungs- und Entwicklungsaufwand deutlich. Das wiederum bremst die Bemühungen eines Unternehmens aus, Vendor-Lock-ins durch geeignete Multi-Cloud-Strategien zu umgehen.