In meinem letzten Artikel habe ich den aktuellen Stand meines privaten RKE2-Clusters beschrieben: drei RKE2-Server-Nodes, GitLab als zentraler Plattform-Workload, Longhorn, MetalLB, cert-manager, MinIO, Prometheus, OpenProject und weitere Dienste. Dieser Artikel betrachtet die Ebene darunter und darum herum: Wie die gesamte Infrastruktur verwaltet wird.

Hinweis: Dieser Beitrag ist die deutschsprachige, praxisnähere Fassung. Eine kürzere englische Version mit stärkerem Fokus auf Forward-Deployed Engineering und AI-assisted infrastructure workflows steht hier: GitLab as an Operating System for AI-Assisted Infrastructure.

Der interessanteste Punkt daran ist nicht, dass ich Terraform, Ansible, NetBox oder GitLab CI/CD einsetze. Das wäre für sich genommen nicht ungewöhnlich. Der entscheidende Punkt ist das Arbeitsmodell:

Ich habe im Infrastruktur-Repository keine einzige Zeile Code oder Script von Hand geschrieben. Alles entstand über GitLab-Tickets, Merge Requests und AI-Agenten. Selbst die Tickets habe ich nicht ausformuliert, sondern Codex nur die entscheidenden Stichpunkte gegeben: Ziel, Kontext, Randbedingungen und Akzeptanzkriterien. Daraus entstanden strukturierte GitLab-Issues, die wiederum als Arbeitsanweisung für Codex oder GitHub Copilot dienten. Die Agenten setzen diese Anforderungen um, arbeiten im Terminal, verbinden sich per SSH auf Zielsysteme, lesen Logs, testen Kommandos direkt auf den Servern, bauen die funktionierenden Schritte in Terraform, Ansible oder CI-Jobs ein und dokumentieren die Verifikation im Merge Request.

Meine Rolle hat sich dadurch nicht reduziert. Sie hat sich verschoben: weg vom Tippen einzelner YAML-, HCL-, Python- oder Shell-Zeilen, hin zu Zieldefinition, Architekturentscheidungen, Review, Risikosteuerung, Betriebsvalidierung und dem Aufbau eines Systems, in dem Agenten produktiv und nachvollziehbar arbeiten können.

Ausgangslage

Das Infrastruktur-Repo ist ein privates GitLab-Projekt für meine eigene Plattform. Es entstand am 1. Oktober 2025 und umfasst aktuell rund 600 versionierte Dateien, mehr als 760 Commits, über 250 Merge Requests und mehr als 130 Ansible-Rollen. Es verwaltet nicht nur den Kubernetes-Unterbau, sondern einen großen Teil der Heim- und Plattforminfrastruktur:

• libvirt/KVM-VMs über Terraform und Cloud-Init
• FreeIPA für IdM, DNS und Zertifikatsintegration
• Samba AD-DC für Windows-Domain-Funktionen
• Kea DHCP, Stork und NetBox als Source-of-Truth-nahe Infrastrukturverwaltung
• RKE2-Server als Kubernetes-Basis
• PostgreSQL, Redis, Nextcloud, Kimai, Mail, Pi-hole, Traefik, Grandstream-Provisioning und weitere Dienste
• OPNsense und Juniper-Netzwerkgeräte über eigene Validierungs- und Apply-Pfade
• Backup-Orchestrierung inklusive Pre-/Post-Kommandos, Healthchecks und GitLab-basierter Auslieferung

Das Repo ist damit kein Demo-Projekt. Es ist der laufende Betriebszustand einer realen Umgebung mit echten Abhängigkeiten: DNS muss funktionieren, bevor Hosts joinen können. DHCP und DNS dürfen nicht gegeneinander arbeiten. Firewall- und Routing-Regeln müssen zu NetBox passen. Updates dürfen Nextcloud, Mail oder Datenbanken nicht in inkonsistente Zwischenzustände bringen. Und GitLab selbst ist zugleich Werkzeug und Workload.

Das eigentliche Muster: Ticket zu Zielzustand

Ein typisches Ticket enthält:

Das ist wichtig, weil es Agenten führt. Der Agent bekommt nicht nur eine technische Aufgabe, sondern einen Entscheidungsrahmen. Er kann damit Informationen sammeln, Risiken erkennen, konkrete Kommandos testen und seine Änderungen gegen klare Kriterien validieren.

Der Merge Request ist dabei der sichtbare Arbeitsnachweis. Er enthält nicht nur eine Zusammenfassung, sondern auch konkrete Verifikation: Syntax-Checks, Terraform-Validierung, Ansible-Limited-Runs, direkte Host-Kommandos, Pipeline-IDs, Logbefunde und Rollback-Hinweise. Genau dort wird aus „AI hat Code generiert“ ein kontrollierter Engineering-Prozess.

GitLab ist in diesem Setup nicht nur Git-Hosting. Es ist das Betriebssystem für Änderungen:

• Issues beschreiben Arbeit.
• Branches isolieren Arbeit, typischerweise mit codex/-Prefix.
• Merge Requests machen Änderungen, Nachweise und Diskussion sichtbar.
• Pipelines prüfen, planen, deployen und aktualisieren.
• Die Registry hält eigene CI-Images.
• GitLab dient als Terraform-State-Backend.
• GitLab ist zugleich die Plattform, auf der andere Infrastruktur-Repos und Backup-Ablagepfade liegen.

Das klingt zirkulär, ist aber bewusst so gebaut. GitLab ist Workload, Werkzeug und Nachweisraum. Dadurch entsteht ein durchgängiger Audit-Trail: Warum wurde etwas geändert? Wer oder was hat es geändert? Welche Tests liefen? Welche Pipeline hat ausgerollt? Welche Fehler traten auf? Was wurde danach im Repo korrigiert, damit derselbe Fehler nicht wiederkommt?

Genau dieser letzte Punkt ist entscheidend: Wenn eine Pipeline fehlschlägt, ist das nicht nur ein Incident. Es ist Input für das System. Der Agent analysiert den Fehler, verbindet sich auf den betroffenen Host, prüft Logs, reproduziert das Problem, testet den Fix und schreibt die dauerhafte Korrektur ins Repo.

Source of Truth: NetBox vor Terraform vor Ansible

Ein Kernprinzip des Repos ist die Trennung von Verantwortlichkeiten. NetBox ist der Source of Truth für Infrastrukturidentitäten: Hosts, VMs, Interfaces, IPs, MACs, Netze, Gateways und Rollen. Terraform erzeugt oder adoptiert die libvirt-VM-Schicht. Ansible konvergiert die Betriebssystem- und Service-Schicht. GitLab verbindet alles über Pipelines.

Die Pipeline erzwingt diese Reihenfolge. Zuerst läuft ein Source-of-Truth-Gate. Danach wird NetBox in Terraform-Variablen exportiert. Erst dann darf Terraform planen oder anwenden. Erst danach darf Ansible konfigurieren.

Das verhindert eine typische Schwachstelle kleiner Infrastrukturprojekte: Werte liegen nicht verteilt in persönlichen Notizen, Host-Konfigurationen, Terraform-Variablen und DNS-Zonen herum. Stattdessen wird jede Schicht aus der darüberliegenden Wahrheit abgeleitet. Wenn NetBox inkonsistent ist, stoppt die Pipeline früh. Wenn Terraform eine destruktive Änderung plant, greifen Guards. Wenn Ansible keinen Vaultwarden-Prefetch oder keinen NetBox-Export findet, bricht es ab, statt still mit impliziten Annahmen weiterzulaufen.

Die Pipeline als Betriebsmodell

Die .gitlab-ci.yml unterscheidet drei zentrale Pfade.

Der erste Pfad ist die Pre-Merge-Pipeline für Merge Requests nach main. Sie validiert die geplante Änderung, ohne sofort produktiv zu deployen. Dazu gehören unter anderem:

• Vaultwarden-Session und Secrets-Prefetch
• NetBox Source-of-Truth-Gate
• NetBox-Export nach Terraform
• terraform fmt, terraform validate und terraform plan
• Guards gegen riskante libvirt-Änderungen
• YAML- und Ansible-Syntaxprüfungen
• Ansible-Dry-Run mit --check --diff
• dedizierte OPNsense- und Netzwerk-Validierungen
• ein Approval-Gate für Merge Requests

Der zweite Pfad ist die Post-Merge-Pipeline auf main. Sie ist der Apply-Pfad. Nach dem Merge werden Terraform und Ansible angewendet, aber weiterhin in kontrollierten Stufen: NetBox exportieren, Terraform anwenden, Ansible konfigurieren, Netzwerk-Smoke-Tests ausführen. Netzwerkgeräte wie Juniper haben eigene manuelle Apply-Pfade, weil Switch-Konfigurationen andere Risiken haben als normale Host-Konfiguration.

Der dritte Pfad ist die Scheduled-Update-Pipeline. Sie läuft geplant auf main und aktualisiert Systeme über Ansible. Debian, RedHat/AlmaLinux und Arch Linux werden jeweils OS-spezifisch behandelt. Arch/AUR-Fehler werden klassifiziert, transiente AUR-Probleme können auf Paketquellen-Updates reduziert werden, Nextcloud bekommt bei Paketupdates einen OCC-Upgrade-Pfad, OPNsense hat eine eigene Update-Rolle, und am Ende entsteht ein Update-Report inklusive Mail-Zusammenfassung.

Diese Pipeline ist kein Beiwerk. Sie ist der Mechanismus, mit dem Agentenarbeit begrenzt, prüfbar und produktionsnah gemacht wird.

Backup als Repo-gesteuerter Betriebsprozess

Auch Backup ist nicht nur „ein Script irgendwo“. Das Infrastruktur-Repo verwaltet eine Backup-Orchestrator-Rolle. Sie checkt ein separates Backup-Repo aus GitLab aus, rendert Host-Konfigurationen aus dem Inventory, installiert systemd-Units und Timer und sorgt für SSH-Hostkeys, Zielhost-Definitionen, Pre-Kommandos, Stop-/Start-Sequenzen, Healthchecks und Post-Kommandos.

Die Backups sind pro Host unterschiedlich, weil die Datenklassen unterschiedlich sind:

• FreeIPA erzeugt ipa-backup und Datenbank-Dumps für NetBox, Kea und Stork.
• PostgreSQL-Hosts erzeugen konsistente Dumps.
• Samba AD nutzt samba-tool domain backup.
• Nextcloud geht vor dem Dump in Maintenance Mode und danach wieder heraus.
• Docker-basierte Dienste werden gezielt gestoppt oder mit applikationsspezifischen Dumps vorbereitet.
• RKE2-Server bekommen Ausschlusslisten für volatile Kubernetes-, Container- und Systempfade.

Der relevante Punkt ist nicht nur, dass Backups existieren. Der Punkt ist, dass Backup-Annahmen und Betriebssequenzen im gleichen GitLab/IaC-Prozess landen wie Infrastruktur, Services und Updates. Wenn ein Backup-Pfad nicht robust ist, wird die Korrektur nicht als lokaler Sonderfall belassen, sondern als Merge Request ins Repo überführt.

Agentenarbeit im Betrieb: mehr als Codegenerierung

Der für mich wichtigste Lerneffekt ist: AI-Agenten sind in diesem Setup keine Autocomplete-Funktion. Sie sind operative Pairing-Partner mit Terminalzugriff und klaren Leitplanken.

Ein typischer Fehlerlauf sieht so aus:

1. Eine Pipeline oder ein Dienst fällt auf. 2. Das Ticket oder der MR beschreibt den Kontext. 3. Der Agent liest Pipeline-Logs und Repo-Konfiguration. 4. Der Agent verbindet sich per SSH auf den betroffenen Host. 5. Er prüft systemctl, journalctl, Service-Konfiguration, Netzwerk, DNS, Paketstatus oder Kubernetes-Zustand. 6. Er testet den kleinstmöglichen Fix direkt auf dem Zielsystem. 7. Erst danach überträgt er die validierte Lösung in Ansible, Terraform, CI oder Dokumentation. 8. Er lässt begrenzte Tests laufen und dokumentiert die Verifikation im Merge Request.

Das Repo enthält diese Arbeitsweise sogar als verbindliche Prozessregel: erst Situation verstehen, bei Bedarf auf Server verbinden, Kommandos manuell testen, dann in Rollen integrieren, betroffene Tasks erneut ausführen, Branch mit codex/-Prefix, sinnvolle Commits, Merge Request mit Tests und Nachweisen.

Das ist aus meiner Sicht der relevante Unterschied zwischen „AI schreibt YAML“ und „AI wird Teil eines belastbaren Delivery-Prozesses“. Der Agent darf arbeiten, aber nicht ungebremst. Er muss erklären, testen, nachweisen und den Zielzustand versionieren.

Was dadurch entstanden ist

Das Ergebnis ist ein Infrastruktur-Repo, das die reale Umgebung zunehmend vollständig beschreibt:

• Terraform modelliert VMs, Cloud-Init, Storage-Profile, Netzwerkprofile, Autostart, Konsolen, Graphics und Sondergeräte.
• Ansible konfiguriert Rollen für Identity, DNS/DHCP, Datenbanken, Docker, Mail, Nextcloud-nahe Dienste, Pi-hole, Traefik, Backups, Updates und Systembaselines.
• NetBox liefert die Infrastrukturidentitäten und verhindert Drift zwischen Dokumentation und Ausführung.
• GitLab CI/CD trennt Review, Apply, Updates, Netzwerk-Changes und Smoke-Tests.
• GitLab Issues und Merge Requests bilden den Entscheidungs- und Nachweisraum.

Ein paar konkrete Beispiele aus der Historie zeigen die Art der Arbeit:

• Pi-hole-DNS-Preflight auf einem Edge-DNS-Host bekam einen gezielten Retry inklusive FTL-Restart, weil eine Pipeline an der IPA-Namensauflösung scheiterte.
• Identity-VMs für FreeIPA und Samba AD bekamen explizites libvirt-Autostart, nachdem der operative Bedarf als DNS/Kerberos-Abhängigkeit sichtbar wurde.
• Nextcloud-Updates auf Arch wurden um OCC-Upgrade, Redis/PostgreSQL-Startlogik und PHP-Legacy-Konfiguration erweitert, nachdem reale Update-Fehler analysiert wurden.
• OPNsense-Konfiguration wurde aus NetBox abgeleitet und mit Dry-Run-/Validation-Jobs abgesichert.
• Juniper-Switch-Konfiguration wird über einen separaten Netzwerkpfad validiert und bewusst nicht automatisch wie normale Host-Konfiguration behandelt.
• Scheduled Updates erzeugen einen strukturierten Report mit aktualisierten Paketen, verbleibenden Updates, Reboot-Bedarf und Fehlern pro Host.

Das sind keine isolierten Automatisierungen. Es ist ein wachsendes Betriebssystem für Infrastruktur.

Warum das für Field Engineering relevant ist

FDE-Arbeit lebt selten davon, dass jemand in Ruhe eine perfekte Lösung auf der grünen Wiese baut. Relevanter ist die Fähigkeit, unvollständige reale Systeme zu verstehen, Anforderungen in technische Zielzustände zu übersetzen, Risiken sichtbar zu machen, Kunden- oder Betreiberkontext ernst zu nehmen und eine Lösung so zu bauen, dass sie im Betrieb trägt.

Genau das trainiert dieses Projekt:

• unklare Ausgangslagen aufnehmen
• bestehende Systeme ohne Drift adoptieren
• Zielmodelle in kleine, reviewbare Schritte zerlegen
• Agenten so instruieren, dass sie produktiv und kontrolliert arbeiten
• Fehler nicht nur beheben, sondern dauerhaft in Repo und Pipeline abbilden
• technische Entscheidungen dokumentieren und begründen
• Automatisierung an realen Betriebsgrenzen ausrichten

Die Besonderheit ist dabei nicht „ich nutze AI“. Die Besonderheit ist, dass AI nicht neben dem Prozess steht. Sie ist in GitLab, Tickets, MRs, Pipelines, SSH-Diagnose, Tests und Reviews eingebettet. Dadurch entsteht ein Arbeitsmodell, das für Field Engineering sehr nah an der Praxis ist: Problem verstehen, Kontext sammeln, Lösungsweg bauen, beim Kunden- oder Zielsystem validieren, in ein dauerhaft wartbares Modell überführen.

Fazit

Mein Infrastruktur-Repo ist für mich ein Experiment mit sehr praktischem Ergebnis: Wie weit lässt sich eine reale Umgebung als GitLab-gesteuerter, agentenunterstützter Betriebsprozess führen?

Die Antwort ist: erstaunlich weit, wenn man Agenten nicht als Codegeneratoren behandelt, sondern als ausführende Ingenieurspartner in einem strengen Prozess. Die Tickets geben Richtung und Grenzen. Die Agenten analysieren, testen und implementieren. Die Pipelines prüfen und deployen. Die Merge Requests dokumentieren Entscheidung, Verifikation und Rollback.

Am Ende steht nicht nur Infrastruktur-as-Code. Es steht Infrastrukturarbeit als nachvollziehbarer, wiederholbarer und zunehmend autonomer Engineering-Prozess. Genau diese Kombination aus Systemverständnis, Automatisierung, Betriebsnähe und AI-gestützter Umsetzung ist der Kern dessen, was ich als Field Engineer in größere, kundenseitige Kontexte einbringen möchte.