Mein Homelab wartet sich nicht

 (cleberg.net)
1 Punkte von GN⁺ 6 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Um den Betriebsaufwand für das private Homelab zu reduzieren, liegt der Fokus auf einer Ein-Server-Konfiguration und automatischen Updates; die meisten regelmäßigen Handgriffe entfallen dadurch
  • Durch die Konsolidierung mehrerer Server auf einen wurde die Komplexität der Umgebung verringert, und der Wartungsaufwand gemessen an der Serverzahl sank um 75 %
  • Der Raspberry Pi 4 läuft mit Home Assistant OS, das Netzwerk überlässt automatische und geplante Updates UniFi, wodurch es weniger manuelle Verwaltungspunkte gibt
  • Docker-Services werden über eine crontab aktualisiert, die einmal pro Woche docker compose pull und docker compose up -d ausführt; die root-crontab wird hauptsächlich für Backups genutzt
  • Wenn es keinen Notfall gibt, beträgt die monatliche Wartung etwa 15 Minuten; selbst wenn apt update und Neustarts aufgeschoben werden, hat das unmittelbar kaum Auswirkungen auf die Services

Vereinfachte Infrastrukturkonfiguration

  • Die Homelab-Services wurden von mehreren Geräten auf einen einzigen Server konsolidiert
    • Früher wurden vier Server genutzt, heute sind die Services auf einem physischen Server gebündelt
    • Statt Cluster, Hypervisor oder Hybrid Cloud läuft alles auf einem physischen Gerät im Keller
    • Durch diese Vereinfachung sank der Wartungsaufwand bezogen auf die Server um 75 %
  • Es gibt zwar zusätzlich einen Raspberry Pi 4, doch Home Assistant OS übernimmt seine Updates selbst, sodass der Verwaltungsaufwand gering ist
    • Technisch gesehen ist er eher ein Server, in der Praxis fühlt er sich aber mehr wie ein selbstwartendes IoT-Gerät an
  • Die Netzwerkgeräte laufen als UniFi-Setup in einem Mini-Rack
    • Enthalten sind eine UniFi Dream Machine Pro, ein Switch und mehrere APs
    • Da automatische und geplante Updates unterstützt werden, müssen auch die Netzwerkgeräte nur selten manuell angefasst werden

Automatisierte Software-Updates und Backups

  • Updates für Docker-Services laufen wöchentlich über einen einzigen crontab-Eintrag auf dem Server
    • 0 0 * * 0 docker-update
    • docker-update führt in jedem Verzeichnis unter ~/docker/*/ sudo docker compose pull und sudo docker compose up -d aus
  • Die crontab des root-Benutzers dient größtenteils für Backups
    • Sie erstellt täglich Systemberichte
    • Sie erzeugt PostgreSQL-Dumps von Immich und Piped
    • Sie sichert Plex, den Webserver, die Nginx-Konfiguration, Docker-Verzeichnisse und SSH-Dateien per rsync in einen ZFS-Pool
    • Beim Backup der Docker-Verzeichnisse werden Datenbanken, Caches, temporäre Dateien und einige Log-Pfade ausgeschlossen
  • Die verbleibenden manuellen Aufgaben beschränken sich auf apt update, apt upgrade, apt autoremove und bei Bedarf einen Neustart
    • Diese Arbeit dauert etwa 60 Sekunden
  • Wenn es keinen Notfall gibt, liegt die Wartungszeit bei etwa 15 Minuten pro Monat
    • Selbst wenn man sich einen Monat lang nicht per SSH einloggt, um Updates einzuspielen, hat das keine praktischen Auswirkungen auf die Services
    • Es ist wahrscheinlich, dass auch nach mehr als sechs Monaten ohne Eingriff nichts kaputtgeht, aber ein absichtlicher Test ist nicht geplant
  • Die aktuelle Konfiguration bietet auch bei einem vollen Terminkalender ein Gleichgewicht zwischen Privatsphäre, Sicherheit und Komfort

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 시간 전
Meinungen auf Lobste.rs

  • Ich betreibe meinen Heimserver ganz ähnlich.
    Auf Debian sind unbeaufsichtigte Sicherheits-Upgrades aktiviert, alles läuft in rootless Containern mit fest gepinnten Versionen und wird über Podman Quadlet von systemd verwaltet.
    Podmans auto-update kümmert sich um Container-Updates, und systemd-Timer übernehmen wiederkehrende Aufgaben wie Backups und Image-Bereinigung.
    Ich logge mich nur zum Neustarten ein, wenn es ein Kernel-Upgrade gab oder ich eine Image-Version anhebe; das übernimmt Ansible.

    • Die Kombination aus „Versionen pinnen“ und „Podman auto-update“ verwirrt mich.
      Ich hätte „Versionen pinnen“ so verstanden, dass keine Updates automatisch gezogen werden, aber offenbar wird tatsächlich aktualisiert; mir ist daher nicht ganz klar, ob hier unterschiedliche Dinge aktualisiert werden.
    • Ich nutze seit über 10 Jahren nahezu dieselbe Konfiguration und upgrade alle zwei Jahre auf das aktuelle Stable.
      Das einzige separat verwaltete Gerät ist ein Router mit OpenBSD, den ich etwa alle 6 Monate upgrade, wenn eine neue Version erscheint.
      Beides ist geradezu langweilig stabil.

  • Ähnlich, aber ich aktualisiere nichts, bevor ich eine gewünschte Funktion brauche.
    Das Gute an selbst gehosteter Software ist, dass man nach dem eigenen Zeitplan aktualisieren kann.
    Wenn alles gut läuft, nur über Tailscale erreichbar ist und nicht direkt im Internet hängt, kann man es abgesehen von Hardwareausfällen einfach laufen lassen, und es bleibt stabil.

    • Ich frage mich, warum es einen Unterschied macht, ob eine Anwendung direkt im Internet oder über Tailscale exponiert ist.
      Die Daten, die die Anwendung erreichen, sind am Ende doch dieselben; könnten also nicht dieselben Schwachstellen ausgenutzt werden?

  • Wenn man diesen Zustand erreicht hat, ist das eine ziemlich gute Situation.
    Ich versuche auch, dorthin zu kommen, bin aber noch nicht ganz da.
    Debian-Major-Upgrades erfordern weiterhin alle 2 Jahre Handarbeit: "Issues to be aware of for trixie", "Obsolescence and deprecation", "Cleanup after the upgrade"
    Ein altes Ansible kann mit aktuellen Debian-Systemen nicht umgehen; wenn ich also Debian-Server upgrade, muss ich auch Ansible aktualisieren, und am Ende muss ich die Playbooks an das neue Ansible anpassen.
    Derzeit versuche ich, das durch using more Docker containers zu reduzieren, aber Ansible vollständig zu ersetzen, dürfte schwierig werden.
    Es gibt auch Online-Dienste, die ich nicht selbst hosten möchte, etwa freeDNS oder dynv6.net, und auch die bringen gelegentlich Breaking Changes.
    Insgesamt ist es aber ziemlich in Ordnung.
    Ehrlich gesagt bedeutet die Verwaltung eines „wartungsfreien“ Homelabs, dass wir sie letztlich den Open-Source-Entwicklern auf der ganzen Welt überlassen, die die von uns genutzte Software, Pakete und Docker-Images pflegen.

  • Ich zögere zwar, meine Konfiguration als „Homelab“ zu bezeichnen, aber es ist ein unRAID-NAS, auf dem mehrere Docker-Container laufen.
    Einer der Gründe, warum ich gerne für unRAID bezahle, ist, dass die Docker-Unterstützung ordentlich ist, Container per Plugin automatisch aktualisiert werden können und auch die sonstige Wartung ziemlich einfach bleibt.

  • Persönlich stört mich ein wenig, dass ein „Lab“ für mich eher ein Ort zum Experimentieren ist und man das Experiment selbst nicht unbedingt warten muss.
    Der Einsatz von Containern hat gemischte Vor- und Nachteile.
    Für manche Projekte sind Container der erstklassige Distributionsweg, sodass man darüber korrekt Updates erhält.
    Aber ich habe den Eindruck, dass viele Leute eher schlecht gepflegte Container betreiben, und genau dort werden vermutlich viele Probleme entstehen.
    Entscheidend ist zu verstehen, welcher der offizielle Weg ist, Updates für die Software zu bekommen, die man nutzt.
    Ich betreibe hauptsächlich RHEL-Klone mit automatischen Updates, und wenn ein Neustart nötig ist, meldet sich Nagios.
    Da die meisten Dienste in RHEL oder EPEL enthalten sind, ist der Wartungsaufwand ziemlich gering.

  • Für die Wartung meines Homelabs war pyinfra genau das richtige Maß an Faulheit.
    Man kann den Einrichtungsprozess als Code festhalten, besonders nützlich etwa für Konfigurationsdateien, und bei Bedarf einfach apt aufrufen, ohne sich zu fragen, wie man so etwas in nix lösen würde.
    Es ist kein besonders schlaues Tool, aber besser als ein einzelnes Shell-Skript, und ich möchte es künftig weiter ausbauen.
    Wenn man agentenbasiertes Coding nutzt, gibt es außerdem den Bonus, dass man Claude die pyinfra-Dateien zeigen und Hilfe beim Debuggen der Konfiguration bekommen kann.

  • Ich nutze NixOS auf dem Server und aktualisiere nur gelegentlich, wenn es mir einfällt.
    Meist läuft es auf nix flake update && nix run .#deploy hinaus, daher mache ich mir kaum Gedanken darüber.

  • Bei mir ist es sehr ähnlich, auch wenn ich es ungern zugebe: Ein großer Teil liegt am Ende einfach daran, dass die Konfiguration einfacher geworden ist.
    Früher mochte ich einen vollständigen Observability-Stack inklusive Log-Rotation, aber die nervigen Vorfälle der letzten über 2 Jahre kamen alle von kleinen Problemen aus genau dieser Komplexität.
    Dinge wie volle Festplatten wegen Logs und Metriken.
    Die Lösung ist sehr einfach, aber ich möchte mich inzwischen einfach nicht mehr damit beschäftigen.

  • Um docker-compose-Konfigurationen aktuell zu halten, gefällt mir Watchtower.
    https://hub.docker.com/r/nickfedor/watchtower
    Die Konfigurationsoptionen sind ziemlich gut, um Versionen laufend anzuheben und dabei größere Änderungen in gewissem Maß zu berücksichtigen.
    Das Basisbetriebssystem ist Debian LTS mit nur unbeaufsichtigten Updates aktiviert, und wenn ein neuer Kernel kommt, logge ich mich zum Neustarten ein.
    Es macht wirklich nicht viel Arbeit, und der Aussage von weniger als 15 Minuten pro Monat stimme ich zu.