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 ueber 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 fuer 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 koennen.

Ausgangslage

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

• libvirt/KVM-VMs ueber Terraform und Cloud-Init
• FreeIPA fuer IdM, DNS und Zertifikatsintegration
• Samba AD-DC fuer 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-Netzwerkgeraete ueber 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 Abhaengigkeiten: DNS muss funktionieren, bevor Hosts joinen koennen. DHCP und DNS duerfen nicht gegeneinander arbeiten. Firewall- und Routing-Regeln muessen zu NetBox passen. Updates duerfen Nextcloud, Mail oder Datenbanken nicht in inkonsistente Zwischenzustaende bringen. Und GitLab selbst ist zugleich Werkzeug und Workload.

Das eigentliche Muster: Ticket zu Zielzustand

Ein typisches Ticket enthaelt:

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

Der Merge Request ist dabei der sichtbare Arbeitsnachweis. Er enthaelt 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 fuer Aenderungen:

• Issues beschreiben Arbeit.
• Branches isolieren Arbeit, typischerweise mit codex/-Prefix.
• Merge Requests machen Aenderungen, Nachweise und Diskussion sichtbar.
• Pipelines pruefen, planen, deployen und aktualisieren.
• Die Registry haelt 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 zirkulaer, ist aber bewusst so gebaut. GitLab ist Workload, Werkzeug und Nachweisraum. Dadurch entsteht ein durchgaengiger Audit-Trail: Warum wurde etwas geaendert? Wer oder was hat es geaendert? 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 fehlschlaegt, ist das nicht nur ein Incident. Es ist Input fuer das System. Der Agent analysiert den Fehler, verbindet sich auf den betroffenen Host, prueft 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 fuer Infrastrukturidentitaeten: 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 ueber Pipelines.

Die Pipeline erzwingt diese Reihenfolge. Zuerst laeuft 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 persoenlichen Notizen, Host-Konfigurationen, Terraform-Variablen und DNS-Zonen herum. Stattdessen wird jede Schicht aus der darueberliegenden Wahrheit abgeleitet. Wenn NetBox inkonsistent ist, stoppt die Pipeline frueh. Wenn Terraform eine destruktive Aenderung 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 fuer Merge Requests nach main. Sie validiert die geplante Aenderung, ohne sofort produktiv zu deployen. Dazu gehoeren 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-Aenderungen
• YAML- und Ansible-Syntaxpruefungen
• Ansible-Dry-Run mit --check --diff
• dedizierte OPNsense- und Netzwerk-Validierungen
• ein Approval-Gate fuer 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 ausfuehren. Netzwerkgeraete 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 laeuft geplant auf main und aktualisiert Systeme ueber Ansible. Debian, RedHat/AlmaLinux und Arch Linux werden jeweils OS-spezifisch behandelt. Arch/AUR-Fehler werden klassifiziert, transiente AUR-Probleme koennen 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, pruefbar 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 fuer 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 fuer 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 fuer 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 ueberfuehrt.

Agentenarbeit im Betrieb: mehr als Codegenerierung

Der fuer 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 faellt 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 prueft systemctl, journalctl, Service-Konfiguration, Netzwerk, DNS, Paketstatus oder Kubernetes-Zustand. 6. Er testet den kleinstmoeglichen Fix direkt auf dem Zielsystem. 7. Erst danach uebertraegt er die validierte Loesung in Ansible, Terraform, CI oder Dokumentation. 8. Er laesst begrenzte Tests laufen und dokumentiert die Verifikation im Merge Request.

Das Repo enthaelt diese Arbeitsweise sogar als verbindliche Prozessregel: erst Situation verstehen, bei Bedarf auf Server verbinden, Kommandos manuell testen, dann in Rollen integrieren, betroffene Tasks erneut ausfuehren, 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 erklaeren, testen, nachweisen und den Zielzustand versionieren.

Was dadurch entstanden ist

Das Ergebnis ist ein Infrastruktur-Repo, das die reale Umgebung zunehmend vollstaendig beschreibt:

• Terraform modelliert VMs, Cloud-Init, Storage-Profile, Netzwerkprofile, Autostart, Konsolen, Graphics und Sondergeraete.
• Ansible konfiguriert Rollen fuer Identity, DNS/DHCP, Datenbanken, Docker, Mail, Nextcloud-nahe Dienste, Pi-hole, Traefik, Backups, Updates und Systembaselines.
• NetBox liefert die Infrastrukturidentitaeten und verhindert Drift zwischen Dokumentation und Ausfuehrung.
• 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-Namensaufloesung scheiterte.
• Identity-VMs fuer FreeIPA und Samba AD bekamen explizites libvirt-Autostart, nachdem der operative Bedarf als DNS/Kerberos-Abhaengigkeit 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 ueber 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 fuer Infrastruktur.

Warum das fuer Field Engineering relevant ist

FDE-Arbeit lebt selten davon, dass jemand in Ruhe eine perfekte Loesung auf der gruenen Wiese baut. Relevanter ist die Faehigkeit, unvollstaendige reale Systeme zu verstehen, Anforderungen in technische Zielzustaende zu uebersetzen, Risiken sichtbar zu machen, Kunden- oder Betreiberkontext ernst zu nehmen und eine Loesung so zu bauen, dass sie im Betrieb traegt.

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 begruenden
• 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 fuer Field Engineering sehr nah an der Praxis ist: Problem verstehen, Kontext sammeln, Loesungsweg bauen, beim Kunden- oder Zielsystem validieren, in ein dauerhaft wartbares Modell ueberfuehren.

Fazit

Mein Infrastruktur-Repo ist fuer mich ein Experiment mit sehr praktischem Ergebnis: Wie weit laesst sich eine reale Umgebung als GitLab-gesteuerter, agentenunterstuetzter Betriebsprozess fuehren?

Die Antwort ist: erstaunlich weit, wenn man Agenten nicht als Codegeneratoren behandelt, sondern als ausfuehrende Ingenieurspartner in einem strengen Prozess. Die Tickets geben Richtung und Grenzen. Die Agenten analysieren, testen und implementieren. Die Pipelines pruefen 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 Systemverstaendnis, Automatisierung, Betriebsnaehe und AI-gestuetzter Umsetzung ist der Kern dessen, was ich als Field Engineer in groessere, kundenseitige Kontexte einbringen moechte.