Adrian RomoAdrian Romo
Aktiv

Homelab Ops

14 Hosts, etwa 110 Container und die Disziplin, die Doku übersichtlich zu halten

Überblick

Kontext, Ansatz und Ergebnis.

Problem

Ein Homelab hört genau dann auf, ein Hobby zu sein, wenn dein Haushalt davon abhängt. Bei mir war dieser Punkt erreicht — DNS, Hausautomation, Medien, Dokumentenspeicher und SSO-nahe Passwortdienste laufen alle darauf. Ab diesem Moment ist der Ausfallmodus nicht mehr „ein Dienst ist down“. Es ist „ich weiß nicht mehr, warum das so konfiguriert ist, und die einzige Person, die es wusste, war ich selbst vor sechs Wochen“.

Meine Rolle

Alleiniger Architekt und Betreiber. Jeder Host, jede Compose-Datei, jede Entscheidungsdokumentation.

Rahmenbedingungen

  • Einzelner Betreiber, abends und am Wochenende. Alles, was regelmäßig meine Aufmerksamkeit braucht, wird sie irgendwann nicht mehr bekommen.
  • Echte Abhängigkeiten. DNS- und Hausautomationsausfälle sind im Haushalt innerhalb von Minuten sichtbar.
  • Kein Cloud-Notausgang für die Dinge, die zählen — der Punkt ist, dass es hier läuft.

Architektur

Ein Proxmox-Knoten hostet zweckgetrennte Docker-VMs: gemeinsame Infrastruktur (Reverse Proxy, SSO, Metriken, Logs, Uptime, Push-Benachrichtigungen), ein operatives Backend (selbstgehostetes Git, CI-Runner, ein Append-only Event-Ledger), benutzerorientierte Wissens- und Dokumenten-Apps sowie eine Sandbox für Experimente und öffentliche Demos. Ein NAS hält Persistenz und Backups und dient gleichzeitig als zweiter DNS-Knoten. Eine separate GPU-Workstation betreibt den lokalen Modell-Stack.

Der Ingress läuft über einen einzigen Reverse Proxy mit Forward-Auth vor allem Internen. DNS läuft hochverfügbar über zwei Knoten mit einseitigem Policy-Sync aus einer festgelegten Quelle der Wahrheit, sodass das Replikat niemals zur zweiten Meinung abdriften kann.

Alles ist Git-gestützt und Git-first: Inventar, Compose-Dateien, Runbooks und Entscheidungsdokumentationen leben in einem Repo, und die laufende Flotte wird von Read-only-Collector-Agents gegen dieses Repo verglichen, die selbst nichts ändern und ihre eigenen Fehler aufzeichnen, statt abzustürzen.

Ergebnis

14 Hosts und etwa 110 Container, dokumentiert in 368 Markdown-Seiten: 21 Architektur-Entscheidungsdokumente, 131 Runbooks — inklusive Wiederherstellungsprozeduren für jeden zustandsbehafteten Dienst — und Postmortems, ehrlich genug, um auch die Fixes zu enthalten, die nicht funktioniert haben.

Was ich anders machen würde

Die Entscheidungsdokumente von Anfang an schreiben, statt sie später rekonstruieren zu müssen. Das Teure war nie die Konfiguration; es war das Wiederherstellen der Gründe hinter einer Konfiguration, die ich längst vergessen hatte. Und die USV kaufen, bevor dich ein unsauberer Stromausfall dazu zwingt, es zu lernen.

Erkenntnisse

Was ich mitnehme.

Im Homelab teste ich Ops-Patterns, bevor ich sie im Job einsetze – günstiger Blast-Radius, hohe Lernrate. Das erfolgreichste Pattern war „Read-Only First“: Collector-Dienste, die erst beobachten und berichten, um Vertrauen zu gewinnen, lange bevor sie irgendetwas am Zustand ändern dürfen.

Stack

Tools und Plattformen.

ProxmoxDockerTraefikAuthentikPrometheusGrafanaLokiPi-holeGiteaDebian

Verwandte Texte

Notizen aus diesem Projekt.

Reden wir

Möchtest du über solche Arbeit sprechen?

Wenn du für ähnliche Backend-, AWS-, Voice- oder Integrations-Arbeit einstellst — oder einfach Architektur-Notizen vergleichen willst — melde dich direkt.