IaC steht für Infrastructure as Code und beschreibt den Prozess der Verwaltung und Bereitstellung von virtuellen Maschinen per maschinenlesbaren Definitionsdateien, statt diese per interaktiver Konfigurationstools oder klassischer Hardwarekonfiguration zu konfigurieren. In einfachen Wortes gesagt, kann im Grunde jeder Softwareentwickler in seine IDE, die für seine Anwendung benötigte Infrastruktur selbst per Code konfigurieren. Per Push oder Pull wird diese Konfiguration von einem Service interpretiert und ausgeführt. Dabei ist es egal, ob es in die Cloud geht oder in ein Rechenzentrum um die Ecke. Dadurch, dass die Infrastruktur als Code vorliegt, kann diese versioniert und wiederverwendet werden – in anderen Projekten oder auch um Staging Systeme auf und ab zu bauen. Jeder Schritt kann so jederzeit und von jedem nachvollzogen werden. Hier kommen alle Vorteile aus der klassischen Softwareentwicklung zusammen, wie Pull Requests, Wiederverwendbarkeit, modularer Aufbau, Versionierung, etc.
Terraform ist ein IaC System, das von der Firma HashiCorp als Open Source entwickelt wurde. Es ermöglicht Aufgaben und Abläufe in der Cloud durch Skripte zu automatisieren. Dadurch können Workflows vereinfacht werden, zugleich aber auch eine flexible Infrastruktur aufbauen, die auf mögliche wechselnde Anforderungen reagieren kann. Ein weiterer großer Vorteil von Terraform sind die diversen Provider von Cloud Anbietern, wie AWS, Azure, Google Cloud oder DigitalOcean, die es ermöglichen, schnell eine Infrastruktur aufzubauen, die dabei immer den selben Code-Aufbau hat. Dadurch kann recht flexible zwischen Anbietern gewechselt werden, ohne immer bei Null anzufangen. In Terraform wird der Code in einer recht leicht verständlichen Sprache, die sogenannte HCL (HashiCorp Configuration Language), geschrieben. Für die Ausführung des Codes wird keine Server Software benötigt - Dadurch kann die Infrastruktur vom Entwicklerrechner oder direkt aus der Pipeline aufgesetzt und angepasst werden.
In Terraform gibt es verschiedenen Typen, welche oft in separaten Dateien gespeichert werden, damit diese leichter zu warten und wiederzuverwenden sind.
Variables: Key-Value zur Konfiguration
Module: Wiederverwendbarkeit und Kapseln von Konfigurationen, in denen Provider, Variablen und Ressourcen liegen können.
State: Status-Speicherung, wichtig für den Abgleich und die Prüfung von Änderungen
Resources: Repräsentant eines Infrastrukturobjektes (Virtuelles Netzwerk, Serverinstanz, DNS, …)
Data Source: Informationen über externe Objekte
Output Values: Ausgabe aus dem Code (z.B. URL, Id, Name eines angelegten Objektes)
Der Ablauf ist immer folgendermaßen:
Init: Lädt alle benötigten Daten, wie Provider und externe Module ins Projekt
Plan: Prüft die Machbarkeit und zeigt an, was gemacht werden würde
Apply: Führt den Plan aus. Anlegen, Ändern, Löschen
Destroy: Dadurch wird alles, was per Terraform als Infrastruktur angelegt wurde, wieder gelöscht.
Durch die Befehle “apply” und “deploy” wird ein State angelegt, welcher in Terraform markiert, was schon existiert und was sich eventuell geändert hat. Darum empfiehlt es sich, diesen State zentral zu sichern. Dies ermöglicht auch von verschiedenen Clients Änderungen an der Infrastruktur durchzuführen. Die meisten Provider bieten Services wie S3 an, um den State remote zu speichern.
Durch das Anlegen von Modulen wird als erstes sichergestellt, dass jedes Environment das identische Setting hat, ohne dass der Code immer wieder dupliziert werden muss. Daher empfiehlt es sich, die Infrastruktur Bereiche von Beginn an modular aufzusetzen.
Da Terraform keine wirkliche Struktur vorgibt, kommt man im Laufe eines Projektes an seine Grenze der Übersichtlichkeit. Daher empfehle ich, so kleinteilig wie möglich zu schneiden. Unter dem Ordner “modules” werden die Ordner für die einzelnen Terraform Module gepackt, so können diese leicht für jedes Environment wiederverwendet werden. Unter “envs” liegen die einzelnen Environments, wie Dev Prod und Staging. In jedem Environment packen wir sortiert alles in einzelne Ordner, was wir nach und nach zum Aufbau unserer Infrastruktur benötigen. Unter dem Ordner “00_general” packen wir alles, was für die Nutzung der Infrastruktur notwendig ist, wie z.B: ein Billing Account, Nutzer Accounts, Nutzer Rollen, etc. In “01_vpc” liegen z.B. die Informationen zum Aufsetzen des VPC, die wiederum in allen anderen Steps benötigt wird. Über die Datei “outputs.tf” definieren wir alle wichtigen Output Values, z.B. die interne ID des VPC. Der Vorteil dabei ist, dass diese Informationen auch im State gespeichert werden. Darum können wir immer wieder auf diese Information zurückgreifen.
Ich hoffe, ich konnte hier zeigen, warum Terraform für jede Projektgröße eine gute Idee ist und warum es sich lohnt sich als Entwickler einmal damit zu beschäftigen.