von
Die Qual der Wahl
Im letzten Blogbeitrag wurde das Konzept “Infrastructure as Code” vorgestellt. So interessant das Konzept ist, so vielfältig sind sowohl die Ausprägungen und Anwendungsfälle des Konzepts in der Praxis als auch der zugehörige Werkzeugkasten: Terraform, Ansible, OpenTofu, Pulumi, Vagrant, Packer, Crossplane, Cloud Formation, ARM Templates, GCP Deployment Manager, AWS CLI, Azure CLI, Heat, um nur einige zu nennen. Nicht nur die bloße Anzahl an verschiedenen Werkzeugen stiftet Verwirrung. Auch die Tatsache, dass einige Werkzeuge sich nicht nur auf einen Aspekt beschränken, sondern auch andere Bereiche wie Orchestrierung und Konfigurationsmanagement abdecken. GitOps-Werkzeuge wie ArgoCD und Flux2 sind hingegen auf Kubernetes beschränkt und decken daher nur einen Teil der Infrastruktur ab.
Dieser Artikel versucht, eine erste Einordnung der Werkzeuge zu geben.
Begrifflichkeiten
Das Konzept “Infrastructure as Code” (IaC) wird je nach Sichtweise enger oder weiter ausgelegt. Allen Auslegungen gemein ist jedoch, dass es eine Beschreibung von Infrastruktur-Ressourcen in maschinen- und menschenlesbarer Form umfasst. Diese Beschreibung kann jedoch nicht nur der Dokumentation der Infrastruktur, sondern auch zur aktiven Pflege, Wartung und Weiterentwicklung der Infrastruktur dienen. Die Beschreibung der vorhandenen physischen Hardware im Rechenzentrum (Racks, Server, Switches, etc.) ist zwar ein Schritt in die richtige Richtung. Gemeint ist im IaC-Umfeld jedoch eher virtuelle Infrastruktur wie Netzwerke oder virtuelle Maschinen im Cloud-Umfeld. Diese Art von Ressourcen kann im Gegensatz zu Hardware einfach und schnell aufgebaut oder geändert werden, erfordert jedoch ebenfalls Pflege und Wartung. Und hier schlägt das Konzept zwei Fliegen mit einer Klappe.
In Abgrenzung dazu wird der Begriff Konfigurationsmanagement traditionell eher auf die Konfiguration innerhalb solcher Infrastruktur-Ressourcen angewendet. Das kann sowohl die Konfiguration des Webservers in einer virtuellen Maschine als auch die Konfiguration eines Switches oder einer Firewall-Appliance sein. An dieser Stelle verschwimmen die Grenzen jedoch, weil die Konfiguration des Routers vielleicht auch die Definition virtueller Netze o.ä. enthält und damit in Richtung Infrastruktur geht.
Im allgemeinen Sprachgebrauch werden beide Begrifflichkeiten gerne vermischt, da die Definition der Konfiguration in einer Ressource zwar streng genommen keine Infrastruktur ist, aber gut in das Konzept der Definition “as Code” passt.
Terraform
Der Platzhirsch unter den Werkzeugen im “Infrastructure as Code”-Umfeld ist Terraform. 2014 von der Firma Hashicorp ins Leben gerufen, steht es vielmals stellvertretend für die ganze Gattung von IaC-Werkzeugen. Einsatzzweck ist das Erstellen von “Ressourcen” bei einer Vielzahl von Anbietern. Diese bewusst schwammige Formulierung ist der hohen Flexibilität von Terraform geschuldet.
Terraform baut auf einer deklarativen Beschreibungssprache (HCL) auf und bietet selbst nur grundlegende Funktionen. So gut wie alle Ressourcen, die mit Terraform verwaltet werden können, werden nicht von Terraform, sondern von einem sog. “Provider” bereitgestellt. Provider existieren für die gängigen Public-Cloud-Anbieter (AWS, Azure, GCP, Digital Ocean, Hetzner etc.) und Private-Cloud-Anbieter (OpenStack, VMware) genau wie für Datenbanken, Kubernetes-Cluster und hunderte andere Anbieter. Die Provider werden unabhängig von Terraform weiterentwickelt und beschreiben die verfügbaren Ressourcen und deren Konfiguration. Viele Provider werden von den Infrastruktur- bzw. Cloud-Anbietern selbst betreut und mit ihrem Produktportfolie zusammen weiterentwickelt, so dass neue Dienste meist zeitnah zur Verfügung stehen.
Auf Grund der hohen Beliebtheit und der einfachen Erweiterbarkeit kann Terraform mittlerweile auf fast 4.000 Provider zugreifen, die in mehrere Güteklassen (offiziell, Partner, Community) eingestuft werden.
Terraform ist das bekannte und beliebteste Werkzeug, nichtsdestotrotz gibt es einige Einschränkungen zu beachten. Zum einen benötigt jeder Provider eine unterschiedliche Ressourcen-Definition, auch wenn Infrastruktur bei verschiedenen (Cloud-)Anbietern mit Terraform verwaltet werden kann. Die Anwenderin kann zwar das gleiche Programm verwenden, muss sich jedoch an unterschiedliche Ressource-Definitionen und –konzepte gewöhnen.
Zum anderen glänzt Terraform besonders auf Infrastrukturebene, kommt jedoch bei zustandsbehafteten Ressourcen wie virtuellen Maschinen an seine Grenzen. Die Anwenderin kann mit Terraform zwar dafür sorgen, dass z.B. die Anzahl an Webservern zu Stoßzeiten erhöht und danach wieder verringert wird. Jedoch reicht Terraforms Kernkompetenz nur bis zum erfolgreichen Starten der virtuellen Maschine. Die Konfiguration des Webservers in der Maschine lässt sich mit Terraform nur schwer umsetzen.
Terraform kann zwar sog. “Provisioner” wie Ansible oder Puppet anbinden, Hashicorp empfiehlt dies jedoch ausdrücklich nicht. Stattdessen raten die Terraform-Entwickler zur Nutzung vorgefertigter Betriebssystemabbilder (“golden images”), so dass die eingeschränkte Konfiguration über Cloud-Schnittstellen wie cloud-init oder Ignition ausreicht. Hintergrund ist, dass Terraform über die API des Cloud-Anbieters keinen Zugriff auf den Zustand im Inneren z.B. einer virtuellen Maschine hat. Da die Nutzung unterschiedlicher Betriebssystemabbilder Nachteile in Bezug auf Kosten und Speicherverbrauch aufweist und nicht alle Anwendungsfälle abdeckt, wird Terraform meist in Kombination mit einem der genannten Konfigurationsmanagementsysteme eingesetzt.
Auch wenn der eigentliche Einsatzzweck von Terraform die Erstellung, Verwaltung und Pflege (engl. “lifecycle management”) ist, kann es durchaus auch für andere Zwecke verwendet werden. Denkbar ist dies für begrenzt benötigte Ressourcen z.B. für Schulungen, für die jeder Teilnehmer einen eigenen Satz an z.B. virtuellen Maschinen benötigt. Auch kurzlebige Aufbauten zum Vorführen von Anwendungen (engl. “proof of concept”) und sogar Testserver lassen sich mit Terraform sehr elegant aufbauen, weil Terraform auch das Entfernen aller Ressourcen mit einem Befehl erlaubt. Hier macht sich Hashicorp selbst Konkurrenz zu Vagrant, das in einem späteren Abschnitt beschrieben wird.
Im Jahr 2023 hat Hashicorp die bisherige Open Source-Lizenz bei all seinen Produkten durch eine eingeschränkte unfreie Lizenz ersetzt, um die unberechtigte Nutzung der Produkte durch Konkurrenten zu erschweren. Dieser Schritt wurde kontrovers diskutiert und hat zu großer Enttäuschung und letztlich zur Gründung des OpenTofu-Projekts geführt.
Empfehlung:
Terraform (bzw. OpenTofu, s.u.) sollten immer evaluiert werden, vor allem weil es die Nutzung des gleichen Werkzeugs für eine Vielzahl von Anbietern und Zwecken erlaubt. Die Auswahl an Providern ist bei Terraform sehr groß, was auch der großen Verbreitung geschuldet ist. Meist wird Terraform in Kombination mit einem Konfigurationsmanagementsystem wie Ansible eingesetzt, was das Beste aus beiden Welten verbindet.
OpenTofu
Als Reaktion auf den Lizenzwechsel von Terraform wurde unter Federführung der Linux Foundation das OpenTofu-Projekt ins Leben gerufen. Die erste stabile Version basiert auf dem letzten Stand des Terraform-Quelltextes, der unter einer freien Lizenz steht. Aktuell können sowohl der Infrastrukturcode als auch bestehende Terraform-Provider ohne Anpassung mit OpenTofu verwendet werden.
Derzeit ist nicht abzusehen, ob auf Dauer beide Werkzeuge aktiv weiterentwickelt werden. Da Terraform ein ausgereiftes und vielfach praxiserprobtes Programm ist und die Weiterentwicklung der Provider und deren Funktionen unabhängig von Terraform selbst passiert, ist der Bedarf an Weiterentwicklung überschaubar. Es ist dennoch nicht auszuschließen, dass eines der beiden Werkzeuge Funktionalitäten einbaut, die das andere nicht besitzt, so dass die Anwenderin vor die Entscheidung für ein Werkzeug gestellt wird.
Empfehlung:
OpenTofu besitzt die gleiche Ausrichtung und die gleichen Einschränkungen wie Terraform. Daher ist auch die Empfehlung die gleiche wie für Terraform. Zu klären ist lediglich, ob mit der vorgesehenen Nutzung von Terraform gegen dessen Lizenzbedingungen verstoßen wird bzw. Kosten für die Nutzung entstehen. In diesem Fall kann OpenTofu als Alternative ins Auge gefasst werden.
Pulumi
Pulumi gleicht den beiden Werkzeugen Terraform und OpenTofu in vielerlei Hinsicht, setzt den Fokus aber anders. Anstelle der werkzeugeigenen Beschreibungssprache HCL (engl. “Hashicorp configuration language”) kann Pulumi-Infrastrukturcode in einer von vielen Sprachen geschrieben werden, mit denen Entwickler:innen sowieso vertraut sind. TypeScript, JavaScript, Python, Go, Java, C#, F# und Pulumi YAML stehen zur Wahl. Zusätzlich bietet Pulumi Schnittstellen für die genannten Sprachen (engl. “software development kit”, SDK) an.
Ähnlich zu Terraform und OpenTofu baut auch Pulumi auf dem Provider-Konzept auf. Pulumi selbst enthält die Kernfunktionalität, während das Erstellen von Ressourcen über einen Provider bereitgestellt wird. Unterstützt werden neben den großen Cloud-Anbietern auch weitere Dienste wie Datenbanken, IAM-Lösungen wie Okta oder Code-Hosting-Anbieter wie GitHub und GitLab.
Empfehlung:
Für Unternehmen, deren Entwicklung in einer der unterstützten Sprachen stattfindet, ist Pulumi einen Blick wert. Gerade die Vertrautheit mit der Sprache kann den Einstieg erleichtern. Die Liste der Provider ist umfangreich, reicht aber nicht an die Vielfalt im Terraform-Umfeld heran.
Packer
Wie im Terraform-Abschnitt beschrieben, empfehlen die Terraform-Autoren die Nutzung sog. “golden images” kombiniert mit einer Basiskonfiguration über Cloud-Funktionen wie cloud-init oder ignition. Der klassische Ansatz ist es, ein generisches Betriebssystemabbild zu verwenden und je nach Rolle (Webserver, Datenbank, etc.) die passenden Pakete nachzuinstallieren und die Dienste zu konfigurieren. Der von Terraform präferierte Ansatz ist es, passende Abbilder pro Rolle bereitzustellen, in denen die Pakete bereits enthalten und die grundlegende Konfiguration bereits vorhanden ist. Beim Start einer virtuellen Maschine mit einem derartigen Abbild ist nur noch ein sehr geringer Individualisierungsaufwand nötig, der über cloud-init oder ignition abgedeckt werden kann.
Um solche “golden images” bereitstellen zu können, bietet die Firma Hashicorp das Werkzeug Packer an. Basierend auf einer Beschreibung des Abbilds, können Abbilder für unterschiedliche (Private-) Cloud-Umgebungen erzeugt und in der Cloud bereitgestellt werden.
Ein Nachteil dieses Konzepts ist der benötigte Speicherplatz für die Abbilder, die sich in den meisten Fällen auch nur geringfügig unterscheiden.
Empfehlung:
Das Arbeiten mit “golden images” ist nicht in allen Anwendungsfällen möglich und sinnvoll. Falls es zum Einsatz kommt, so kann Packer das Arbeiten mit Abbildern und mehreren Cloud-Anbietern jedoch deutlich vereinfachen. Auch hier ist jedoch zu prüfen, ob die vorgesehene Nutzung gegen die Lizenz verstößt bzw. Kosten verursacht.
Vagrant
Auch das Programm Vagrant stammt von der Firma Hashicorp. Ausgerichtet ist es auf die einfache und schnelle Bereitstellung von Umgebungen, vorwiegend für Entwickler. Mit einem Befehl ist es der Entwicklerin möglich, den aktuellen Zustand z.B. einer Webanwendung in einer (oder mehreren) virtuellen Maschine(n) bereitzustellen und auszuprobieren. Änderungen können zwischen Entwickler-Laptop und der virtuellen Maschine synchronisiert werden. Durch das einfache Auf- und Abbauen der virtuellen Maschinen, kann eine Verschleppung von Fehlern vermieden werden.
Aufgrund der einfachen Definition in einem sog. “Vagrantfile” kann die Definition der Testumgebung im gleichen Code-Repository wie der Anwendungsquelltext gepflegt werden und steht somit allen Entwicklern zur Verfügung.
Ursprünglich war es auf lokal installierte Virtualisierungslösungen wie Virtualbox ausgerichtet. Im Laufe der Zeit wurden jedoch weitere Anbindungen u.a. auch an Cloud-Anbieter bereitgestellt, so dass VMs nicht nur lokal, sondern auch “in der Cloud” erstellt werden können. Hier verschwimmen die Grenzen zu Terraform und OpenTofu ein wenig. Als Faustregel kann gelten, dass Vagrant für kurzlebige, einfache Ressourcen angedacht ist. Der Haupteinsatzzweck von Terraform/OpenTofu ist hingegen das langfristige Pflegen, Erstellen und Betreuen der Infrastruktur, was weit über einfache virtuelle Maschinen hinausgeht.
Für Vagrant existiert auch ein Provider, der die Anbindung an Docker bereitstellt. Hier werden Container statt virtueller Maschinen aufgebaut, was je nach Anwendungsfall die benötigte Zeit zum Aufbau der Umgebung verkürzen kann.
Empfehlung:
Zur lokalen Bereitstellung von virtuellen Maschinen oder Containern ist Vagrant weiterhin ein interessantes Werkzeug. In den meisten Fällen stellt auch die unfreie Lizenz kein Problem bei der Nutzung dar, dies sollte jedoch geprüft werden.
Für Cloud-Ressourcen oder Container bietet Terraform deutlich mehr Flexibilität, falls die Anwenderin mit Vagrant an ihre Grenzen stößt.
Ansible, Puppet, Chef, Saltstack
Zum Reigen der Konfigurationsmanagementsystem zählen Ansible, Puppet, Chef und SaltStack. Chef und Puppet stellen dabei die alte Garde dar, während speziell Ansible mittlerweile über das Thema Konfigurationsmanagement hinausgewachsen ist und auch Orchestrierung und Infrastrukturautomatisierung bietet. So lassen sich viele Netzwerk-Appliances (Router, Switches, Firewalls, etc.) nicht nur per Terraform, sondern auch per Ansible konfigurieren.
Ansible sticht zudem heraus, da es als einziges Werkzeug von Grund auf ohne einen zentralen Server und ohne lokale Agenten auf den betreuten Ressourcen ausgelegt wurde. Zur Verwaltung von virtuellen Maschinen und Servern reicht ein SSH-Zugang, für Appliances reicht vielleicht der HTTPS-Zugang zur REST-API der Geräte.
Ähnlich wie bei Terraform werden die Kernfunktionalität von Ansible und die Module getrennt weiterentwickelt. Bei Ansible gibt es eine Vielzahl sog. “Collections”, welche den Funktionsumfang von Ansible stark in Richtung “Infrastructure as Code” erweitern. Dies umfasst sowohl Zugriff auf Public Clouds und deren Dienste als auch Kubernetes-Cluster oder Container.
Empfehlung:
Die niedrige Einstiegshürde sowie der Wegfall des zentralen Servers machen Ansible zu einem vielseitigen und flexiblen Werkzeug. Die einfache Konfiguration in YAML erleichtert den Einstieg genau wie der Wegfall des zentralen Servers.
Ob Ansible alleine oder in Kombination mit z.B. Terraform oder Vagrant eingesetzt wird, kommt auf den Anwendungsfall und die Planung für den Infrastrukturausbau an. Einen genauen Blick ist Ansible auf jeden Fall wert.
Crossplane
Crossplane baut auf Kubernetes und dessen API auf, um Cloud-Ressourcen zu verwalten, wie im letzten Blogbeitrag gezeigt. Die Herangehensweise unterscheidet sich von Terraform/OpenTofu, Vagrant und Ansible insofern, als die Auswertung des Infrastrukturcodes als Dienst in Kubernetes läuft und nicht lokal, wie beim manuellen Aufruf der genannten Werkzeuge. Ähnlich wie bei Terraform wird die Anbindung verschiedener Cloud-Anbieter ebenfalls über Provider bereitgestellt, von denen es bereits eine ansehnliche Anzahl zu geben scheint.
Empfehlung:
Crossplane ist im Vergleich zu anderen Werkzeugen noch vergleichsweise jung, hat es aber bereits geschafft, ein CNCF-Projekt zu werden, was ein gerüttelt Maß an Struktur und aktiven Unterstützern voraussetzt. Wenn das Projekt in gleichem Maße weiterwächst und sich weiterentwickelt, stellt es tatsächlich eine spannende und vielversprechende Alternative dar, sofern Kubernetes bereits im Einsatz ist.
Automationswerkzeuge der Cloud-Anbieter
Auch wenn viele Cloud-Anbieter selbst die Provider für Terraform oder Collections für Ansible betreuen, bieten fast alle auch eine eigene Automationslösung an. Diese Werkzeuge funktionieren entsprechend nur mit der jeweiligen Cloud und unterstützen deren Funktionen. Hierzu gehören z.B. die Kommandozeilenwerkzeuge (CLI , engl. “command line interface”) für AWS, Azure, Google.
Neben dem Ausführen von interaktiven bzw. imperativen Kommandos können diese Werkzeuge z.T. auch dateibasiert arbeiten, erreichen jedoch nicht den Komfort von Terraform/OpenTofu. Die AWS CLI kann z.B. "AWS Cloud Formation"-Dateien provisionieren, die Azure CLI bietet diese Funktion für “ARM Templates” (Azure Resource Manager).
Die Nutzung dieser Programme kann im Vergleich zum händischen Erstellen von Ressourcen über die Weboberfläche der jeweiligen Cloud viele Arbeitsschritte vereinfachen. Allerdings bindet man sich fest an einen Cloud-Anbieter, d.h. der Wechsel zu oder der Ausbau der Infrastruktur bei einem weiteren Cloud-Anbieter erfordert die Einarbeitung in ein weiteres Werkzeug. Hier bieten Terraform bzw. OpenTofu Vorteile, auch wenn sich der eigentliche Infrastrukturcode zwischen den Cloud-Providern unterscheidet.
Fazit
Der Bereich “Infrastructure as Code” entwickelt sich ständig weiter, gerade durch den Vormarsch von Kubernetes und Containertechnologie. Daher ist dieser Artikel auch nur eine Momentaufnahme, kann aber hoffentlich zumindest für eine kurze Zeit Klarheit in die Werkzeugauswahl bringen.