Jeder Systemadministrator kennt den Moment: Man meldet sich auf einem Server an, führt ein paar Befehle aus, ändert eine Konfigurationsdatei, installiert ein Paket. Alles funktioniert. Ein paar Wochen später steht man vor demselben Problem — nur auf einem anderen Server. Und man kann sich nicht mehr erinnern, welche Befehle man ausgeführt hat. Der Server ist ein Schneemann: Er sieht aus wie die anderen, aber unter der Oberfläche ist alles anders.
Infrastructure as Code (IaC) ist die Antwort auf dieses Problem. Und wer als Softwareentwickler und Administrator — wie ich — beide Welten kennt, weiß, dass IaC nicht nur ein Trend ist, sondern eine Notwendigkeit.
Das Problem mit manuellen Servern
Manuelle Administration skaliert nicht. Das ist keine Meinungsfrage, sondern Mathematik. Wenn jeder Server ein Unikat ist, dann ist jeder Server ein Risiko. Wenn ein Server ausfällt und niemand weiß, wie er konfiguriert war, dann ist der Wiederherstellungsprozess ein Glücksspiel.
Die typischen Symptome sind vertraut:
- Konfigurationsdrift. Server, die identisch sein sollten, unterscheiden sich in subtilen — und manchmal kritischen — Details.
- Wissensmonopole. Nur eine Person weiß, wie ein bestimmter Server konfiguriert ist. Wenn diese Person krank wird oder geht, ist das Wissen weg.
- Nicht-reproduzierbare Zustände. Ein Server funktioniert, aber niemand kann erklären, warum. Oder schlimmer: Niemand kann ihn neu aufsetzen.
- Angst vor Änderungen. Weil niemand weiß, was passieren wird, wenn man etwas ändert, ändert man nichts. Bis man es muss. Und dann ist es zu spät.
Was Infrastructure as Code bedeutet
IaC ist nicht einfach „Skripte schreiben“. Es ist ein Paradigmenwechsel in der Art und Weise, wie wir über Infrastruktur denken.
Deklarativ statt imperativ. Statt zu beschreiben wie ein Server konfiguriert werden soll („installiere nginx, kopiere die Konfiguration, starte den Dienst“), beschreibt man was der Zustand sein soll („nginx muss installiert sein, die Konfiguration muss diesen Inhalt haben, der Dienst muss laufen“). Der IaC-Workflow kümmert sich um das Wie.
Versioniert. Jede Änderung an der Infrastruktur ist in Git committet. Man kann sehen, wer was wann geändert hat. Man kann zu einem früheren Zustand zurückkehren. Man kann Änderungen über Code-Reviews prüfen lassen.
Reproduzierbar. Wenn ein Server ausfällt, kann er aus der IaC-Definition komplett neu aufgesetzt werden. Wenn ein neuer Server benötigt wird, kann er in Minuten statt Stunden erstellt werden.
Testbar. Bevor eine Änderung auf Produktion geht, kann sie in einer Testumgebung validiert werden. Syntaxfehler, fehlende Abhängigkeiten, inkompatible Konfigurationen — alles wird erkannt, bevor es Schaden anrichtet.
Die Werkzeuge
Die Wahl des Werkzeugs hängt vom Kontext ab. Hier eine Übersicht der etablierten Optionen:
Ansible
Das probably bekannteste IaC-Werkzeug. Ansible ist agentenlos (arbeitet über SSH), verwendet YAML für die Konfiguration und hat eine flache Lernkurve. Für FreeBSD-Administratoren ist es attraktiv, weil es native Module für ZFS, Jails, pkg und andere FreeBSD-Spezifika hat.
- name: ZFS-Dataset für Backup erstellen
community.general.zfs:
name: tank/backup
state: present
extra_zfs_properties:
compression: zstd
atime: off
mountpoint: /backup
Der Nachteil: Ansible ist langsam bei großen Infrastrukturen und die YAML-Syntax wird bei komplexen Logiken unübersichtlich.
Terraform / OpenTofu
Für Cloud-Infrastrukturen ist Terraform (oder der Open-Source-Fork OpenTofu) der De-facto-Standard. Es verwaltet die Infrastruktur als Ressourcen — Instanzen, Netzwerke, Sicherheitsgruppen, Speicher — und hält den Zustand in einer State-Datei.
resource "aws_instance" "freebsd" {
ami = "ami-0xfreebsd15"
instance_type = "t3.medium"
tags = {
Name = "freebsd-prod"
}
}
Pulumi
Pulumi geht einen anderen Weg: Statt YAML oder HCL verwendet man echte Programmiersprachen — Python, TypeScript, Go. Das erlaubt echte Logik, Schleifen, Bedingungen und Typsicherheit.
import pulumi
import pulumi_command as command
server = command.remote.Command("freebsd-setup",
connection=command.remote.ConnectionArgs(
host="10.0.0.1",
user="root",
),
create="pkg install -y nginx",
)
Für FreeBSD: Besonderheiten
FreeBSD bringt eigene Werkzeuge mit, die in der IaC-Welt eine Sonderrolle einnehmen:
- Jails sind leichtgewichtige Container, die sich hervorragend mit Ansible oder Shell-Skripten verwalten lassen.
- ZFS bietet programmierbare Snapshots und Replikation, die sich in IaC-Workflows integrieren lassen.
- pkgbase (seit FreeBSD 15.0) macht das Basissystem selbst paketierbar und damit IaC-kompatibel.
Der Pfad zur Einführung
IaC lässt sich nicht über Nacht einführen. Aber man kann schrittweise vorgehen:
- Bestandsaufnahme. Welche Server gibt es? Welche Konfigurationen? Was ist dokumentiert, was nicht?
- Ersten Server codifizieren. Den einfachsten Server nehmen und seine Konfiguration in Ansible (oder ein anderes Werkzeug) übertragen. Das dient als Lernprojekt und als Template.
- Neue Server nur noch via IaC. Jeder neue Server wird ausschließlich über Code konfiguriert. Keine manuellen Änderungen mehr.
- Bestehende Server migrieren. Nach und nach die manuelle Konfiguration durch IaC-Definitionen ersetzen. Das ist der langwierigste Teil.
- CI/CD für Infrastruktur. Änderungen an der IaC-Definition werden automatisch in Testumgebungen deployed, bevor sie auf Produktion gehen.
Die Kultur ändert sich mit
IaC ist nicht nur ein technischer Wechsel, sondern ein kultureller. Plötzlich sind Konfigurationsänderungen sichtbar. Jeder kann sie sehen, kommentieren, zurückrollen. Das ist ungewohnt — besonders für Administratoren.
Aber es ist der richtige Weg. In einer Welt, in der Sicherheitseinheiten täglich nachweisen müssen, welche Konfiguration auf welchem Server zu welchem Zeitpunkt aktiv war, ist manuelle Administration ein Risiko, das man sich nicht mehr leisten kann.
Und für den einzelnen Administrator ist IaC eine Erleichterung: Man muss sich nicht mehr erinnern, was man auf welchem Server gemacht hat. Es steht alles im Git-Repository. Wenn man nicht weiß, wie ein Server konfiguriert ist — man schaut nach. Immer. Zuverlässig. Ohne Ausnahme.