IaC – Infrastructure as Code mit Terraform
Was IaC ist, welche Werkzeuge es gibt und wie Terraform funktioniert. Mit Beispielen auf Azure.
$ terraform apply -var-file=dev.tfvars + azurerm_resource_group.rg + azurerm_service_plan.plan + azurerm_linux_web_app.app Plan: 4 to add, 0 to change, 0 to destroy. Apply complete! Resources: 4 added.
Wie entsteht heute eine neue App-Umgebung?
- Tag 1
Ticket
«Wir brauchen eine Web App.»
- Tag 1
Klicken
Portal, Wizard, Werte aus dem Kopf.
- Tag 3
Nachbessern
TLS vergessen, falscher Tarif.
- Woche 2
Nochmals
Dasselbe für test und prod.
Die Konfiguration ist nirgends zentral festgehalten.
Das Problem: Umgebungen laufen auseinander
| Einstellung | dev | test | prod |
|---|---|---|---|
| Region | Switzerland North | Switzerland North | West Europe |
| Laufzeit | Node 22 LTS | Node 18 LTS | Node 22 LTS |
| Nur HTTPS | Ein | Ein | Aus |
| Mindest-TLS | 1.2 | 1.0 | 1.2 |
Von Hand gebaute Umgebungen laufen auseinander. Mit IaC kommen alle aus derselben Vorlage.
Was ist Infrastructure as Code?
Wir beschreiben die gewünschte Infrastruktur in Textdateien, legen sie ins Git und lassen ein Werkzeug die Realität daran angleichen.
So läuft eine Änderung mit IaC ab
- 1Code schreibenÄnderung in einer
.tf-Datei, z.B. eine neue Datenbank - 2ReviewPull Request im Git. Kollegen prüfen den Code und die Vorschau (
plan) - 3AusführenNach Freigabe setzt die Pipeline die Änderung um (
apply) - 4ErgebnisAzure entspricht dem Code. Der Git-Verlauf zeigt wer, was, wann
| Ohne IaC (Portal) | Mit IaC | |
|---|---|---|
| Wo steht die Konfiguration? | Im Portal und im Kopf einzelner Personen | In Textdateien im Git |
| Wie wird geändert? | Klicken, sofort live | Pull Request, Review, dann Pipeline |
| Wer hat was geändert? | Activity Log, ohne Begründung | Git-Verlauf mit Autor und Kommentar |
| Neue Umgebung aufbauen | Alle Schritte erneut von Hand | Gleicher Code, andere Werte |
Die Infrastruktur ist im Code beschrieben und damit wiederholbar, versioniert und automatisiert.
Deklarativ vs. imperativ
Beim ersten Aufbau sehen beide ähnlich aus. Der echte Unterschied zeigt sich bei Updates.
Deklarativ = definiere WAS du am Ende willst
Man beschreibt, was man will. Das System findet selbst heraus, wie.
Pulumi ist auch deklarativ, nur in Python geschrieben. Die Schleife beschreibt den Zielzustand, nicht die Schritte. Pulumi rechnet die Differenz genauso aus.
Beispiele: Terraform, OpenTofu, Pulumi, Bicep, ARM Templates
Imperativ = definiere die genauen Schritte, WIE
Man gibt Schritt für Schritt vor, wie man zum Ergebnis kommt.
Beispiele: Bash- oder PowerShell-Skripte mit Azure CLI, Python mit Azure SDK
Deklarativ: Zielzustand anpassen, Terraform rechnet die Differenz aus. Imperativ: Man muss jede Änderung selbst als Schritt formulieren.
Vorteile: reproduzierbar und wiederverwendbar
Ein Bauplan mit Platzhaltern, beliebig viele Umgebungen. Die Werte kommen aus einer kleinen Datei pro Umgebung.
Pro Umgebung nur eine kleine .tfvars-Datei mit den Werten. Klicken Sie auf eine Umgebung.
Wie die .tfvars in den Code kommen
.tfvars-Datei
fest steht im Code: für alle Umgebungen gleich
- Reproduzierbardev = test = prod
- WiederverwendbarModule für alle Teams
- PrüfbarReview per Pull Request
- WiederherstellbarNach Ausfall neu aufbauen
Welche IaC-Werkzeuge gibt es?
| Werkzeug | Sprache | Clouds | Lizenz | Kosten |
|---|---|---|---|---|
| Terraform | HCL | alle | BSL 1.1 | CLI gratis · Plattform kostenpflichtig (siehe unten) |
| OpenTofu | HCL | alle | Open Source | gratis |
| Pulumi | Python, TypeScript, Go, C# | alle | Open Source | CLI gratis · Pulumi Cloud für Teams |
| Bicep | Bicep | nur Azure | MIT | gratis |
| ARM Templates | JSON | nur Azure | Teil von Azure | gratis · Vorgänger von Bicep |
Das Kommandozeilen-Tool. Interne Nutzung ohne Lizenz erlaubt.
Web-Oberfläche, Remote State, Rechte, SSO, Policies. Preis je nach Stufe (Essentials, Standard, Premium).
Wie HCP Terraform, aber im eigenen Netz. Mit Hersteller-Support. Preis auf Anfrage.
Die CLI ist gratis, die Plattform kostet. Für die BKB ist Terraform Enterprise vorgesehen: selbst betrieben, mit Rechten, Audit und Hersteller-Support.
Was ist Terraform?
Terraform ist für das Erstellen und Pflegen von Infrastruktur da.Creating and maintaining infrastructure
Typischerweise läuft ein Projekt in zwei Schritten:
1Infrastruktur bereitstellen
VNet, VMs, App Service Plan, AKS, Key Vault, Zugriffsrechte
Dafür wird Terraform verwendet2Anwendungen deployen
App-Code auf App Service oder AKS bringen
meist per Azure-DevOps-PipelineTerraform wird für Schritt 1 verwendet: Es stellt die Infrastruktur bereit, auf der die Anwendungen danach laufen.
Terraform und Ansible: Was ist der Unterschied?
Ansible ist für das Einrichten und Konfigurieren von Servern da.Configuring and managing servers
Hauptsächlich Konfiguration
- Bestehende Infrastruktur konfigurieren
- Apps deployen
- Software installieren und aktualisieren
Hauptsächlich Provisionierung
- Infrastruktur bereitstellen, z.B. VNet, VM, App Service
- Kann auch Apps deployen
- Stärker in der Orchestrierung: kennt Abhängigkeiten und baut in der richtigen Reihenfolge
- Erkennt Abweichungen über den State
Oft kombiniert: Terraform erstellt die Azure VM, Ansible richtet sie ein. Für PaaS wie den App Service reicht Terraform allein.
So sieht ein Terraform-Repo aus
Ein normaler Ordner im Git. Terraform liest alle .tf-Dateien darin zusammen, die Dateinamen sind nur Konvention. Klicken Sie auf eine Datei. Gelb = von Git ignoriert.
.tf beschreibt die Infrastruktur, .tfvars liefert die Werte pro Umgebung. Der State liegt nicht im Repo.
Wie funktioniert Terraform?
Zwei Hauptkomponenten: der Core und die Plugins (vor allem Provider). Dazu kommt das Gedächtnis: die State-Datei.
- 1Konfiguration schreiben
*.tf= gewünschter Zustand - 2Befehl starten
planoderapply
3Core
vergleicht Konfiguration mit State und berechnet den Plan
4Provider
setzen den Plan per API in Azure um
Provisioner
Skripte ausführen. Nur als Notlösung.
5State-Datei
terraform.tfstate · wird nach apply aktualisiert
Azure
die echte Infrastruktur
Der Core vergleicht Konfiguration mit State, die Provider setzen die Differenz in Azure um. Der State ist das Gedächtnis dazwischen.
Die State-Datei: der aktuelle Stand
{ "version": 4, "terraform_version": "1.15.8", "serial": 7, "resources": [ { "mode": "managed", "type": "azurerm_linux_web_app", "name": "app", "instances": [ { "attributes": { "name": "app-iac-demo-dev-k3x9p", "location": "switzerlandnorth", "https_only": true, "service_plan_id": "/subscriptions/…/asp-iac-demo-dev" } } ] }, { "type": "azurerm_service_plan", … }, { "type": "azurerm_resource_group", … } ]}
Eine Liste aller Ressourcen, die Terraform verwaltet, mit ihren aktuellen Eigenschaften und IDs.
Bei jedem terraform apply. Ohne Einstellung landet sie lokal auf dem eigenen Rechner.
Es ist nur JSON, man könnte es theoretisch direkt ändern. Nicht tun. Nur über Terraform-Befehle: terraform apply, für Spezialfälle terraform state.
Alle brauchen denselben, aktuellen State. Er gehört in einen geteilten Speicher mit Sperre (Locking).
*.tf, *.tfvars, .terraform.lock.hclterraform.tfstate: kann Passwörter enthalten, keine Sperre, Konflikte bei parallelen ÄnderungenCode im Git, State im Remote Backend. Und den State nur von Terraform anfassen lassen.
Module: wiederverwendbare Bausteine
Ein Modul ist ein Ordner mit .tf-Dateien. Es bündelt mehrere Ressourcen zu einem Baustein, ähnlich wie eine Funktion im Code.
Das Modul · einmal gebaut
Darin stecken, für alle gleich:
Die Nutzung · wenige Zeilen
Angegeben wird nur, was sich unterscheidet. Alles andere kommt aus dem Modul.
Wann lohnt sich ein Modul? Beispiel: drei Web Apps
Ein Plattform-Team pflegt die Module, die anderen Teams nutzen sie. Abgelegt werden sie in der privaten Registry von Terraform Enterprise.
Die Befehle: init, refresh, plan, apply, destroy
Beispiel: Der Code verlangt 3 VMs und eine Firewall-Regel. Jemand hat vm-2 im Portal gelöscht. Was macht Terraform bei jedem Befehl?
Code · gewünscht
Tipp: Auf ein Element klicken zeigt den Terraform-Code dazu.
Terraform
State · bekannt
Azure · Realität
refresh holt den Ist-Zustand, plan zeigt die Differenz ohne etwas zu ändern, erst apply setzt um.
App Service im Portal und in Terraform
Jede Einstellung aus dem Portal steht als Zeile im Code.
Der Terraform-Workflow
Infrastruktur ist nie fertig. Im Laufe des Projekts braucht es oft weitere Instanzen, eine Datenbank oder mehr Security. Dann müssen bestehende Umgebungen verwaltet werden. Mit Terraform heisst das: Code anpassen, plan, apply.
plan jede Änderung an, bevor etwas passiert.
plan zeigt alle Änderungen vor der Ausführung, auch manuelle Änderungen im Portal.
Cloud-Anbieter und weitere Provider
Grosse Cloud-Anbieter mit Region Schweiz
- Microsoft Azure Zürich, Genf · bei uns im Einsatz
- Amazon Web Services Zürich
- Google Cloud Zürich
Schweizer Anbieter
- Exoscale Zürich, Genf
- cloudscale.ch Zürich
- Infomaniak über OpenStack
Beispiel-Konfiguration
Aufbau: zuerst denprovider konfigurieren, dann die resource beschreiben.Provider gibt es für Cloud-Plattformen und für andere Dienste mit einer API. Aufbau und Befehle sind dabei gleich.
Mögliche nächste Schritte
Pilot
Eine dev-Umgebung komplett in Terraform.
Terraform Enterprise
Lizenz klären. State, Rechte und Policies zentral verwalten.
Pipeline
planim Pull Request,applynach Freigabe in Terraform Enterprise.Standard
Eigene Module, bestehende Ressourcen importieren.
Mit einer Umgebung starten und Erfahrungen sammeln.