Wer meinenletzten Beitrag zum Homelab Setup 2025 gelesen hat, weiß dass ich dortKomodo (externer Link) als GitOps-Werkzeug für meine Docker Compose Stacks einsetze. Das Prinzip dahinter ist gut: Git als Single Source of Truth, Renovate für automatische Version-Updates, und bei einem neuen Commit deployed Komodo die Änderungen auf das Zielsystem. Funktioniert im Grunde auch – aber Komodo hat mich mit einer Sache regelmäßig zur Weißglut gebracht: File Permissions. Das funktioniert einfach nicht konsistent. Entweder stimmen die Berechtigungen auf dem Host nicht, oder Komodo meckert beim Deployment, oder irgendwas dazwischen. Nach dem x-ten Mal hatte ich genug und wollte eine schlankere Lösung.

Die Anforderung ist dabei überschaubar: Wenn Renovate einen neuen Commit in das Repo pusht (nach meinem Merge des Pull Requests), soll die compose-Datei auf dem Server aktualisiert und die betroffenen Container neu gestartet werden. Kein Kubernetes, kein weiteres Framework. Einfach git pull und docker compose up.

Das Grundprinzip

Das Setup basiert auf drei Komponenten die zusammenspielen:

1. Gitea (externer Link) – mein selbst gehosteter Git-Server, auf dem die Compose-Dateien liegen
2. Renovate (externer Link) – überprüft alle vier Stunden per Cronjob die verwendeten Image-Tags gegen die jeweiligen Container-Registries und öffnet bei neuen Versionen automatisch Pull Requests. Ich merge den PR, der Commit landet aufmain.
3. webhook (externer Link) – ein einzelnes Go-Binary, das auf dem Zielserver einen HTTP-Endpunkt bereitstellt. Gitea feuert bei jedem Push einen Webhook dorthin, woraufhin das Deploy-Script ausgeführt wird.

Der Datenfluss sieht so aus:

Renovate erkennt neues Image-Tag
→ PR in Gitea
→ Merge
→ Gitea feuert Webhook
→ webhook-Binary ruft deploy.sh auf
→ git pull + docker compose up -d

Kein Polling, kein Daemon der irgendwelche Container-Registries beobachtet, kein Framework das eigene Meinungen zu File Permissions hat.

Warum nicht einfach Watchtower oder ein Cron-Script?

Bevor ich zu webhook gegriffen habe, hatte ich kurz zwei andere Ansätze im Kopf.

Watchtower (externer Link) überwacht laufende Container und zieht neue Images automatisch. Das Problem: Watchtower reagiert auf neue Images in der Registry, nicht auf Git-Commits. Wenn Renovate einen PR öffnet und ich den merge, hat Watchtower davon keine Ahnung – der zieht einfach irgendwann wenn er selbst nachschaut. Das passt nicht zu einem Setup bei dem Git die einzige Quelle der Wahrheit sein soll. Außerdem will ich den Merge-Zeitpunkt kontrollieren, nicht Watchtower.

Cron-Script mitgit fetch wäre die andere Möglichkeit – alle paar Minuten nachschauen ob es Änderungen gibt und dann deployen. Funktioniert, hat aber einen konzeptionellen Nachteil: Es ist Polling. Ich baue mit Gitea bereits eine Infrastruktur auf die Push-Events liefern kann, die sollte ich auch nutzen. Ein Webhook reagiert innerhalb von Sekunden, ein Cron-Job mit 5-Minuten-Intervall verzögert unnötig.

webhook ist der sauberste Weg: Event-getrieben, kein Extra-Daemon, ein einzelnes Binary ohne Abhängigkeiten.

Repo-Struktur

Ich habe pro Server ein eigenes Repository:

• apps-stack für dendocker01 – dort laufen Tools wiePaperless-ngx (externer Link) ,Immich (externer Link) ,Vaultwarden (externer Link) und ähnliches
• media-stack für denmedia01 – dort leben alle*arr-Container und was sonst noch zum Medien-Stack gehört

Jedes Repo enthält einfach diecompose.yaml sowie ggf. weitere Konfigurationsdateien die einzelne Anwendungen benötigen. Nichts Besonderes.

Renovate in den Repos

Renovate läuft selfhosted und überprüft per Cronjob alle vier Stunden die Image-Tags in den Compose-Dateien. Dafür reicht eine minimalerenovate.json im Repo-Root:

{"$schema":"https://docs.renovatebot.com/renovate-schema.json","extends": ["config:base"],"docker-compose": {"enabled":true }}

Renovate erkennt dann automatisch die Image-Tags in der Compose-Datei und öffnet PRs wenn eine neuere Version verfügbar ist. Bei Software die semantische Versionierung verwendet (alsomajor.minor.patch) lässt sich das besonders fein steuern – z. B. nur Patch-Updates automatisch mergen, bei Minor-Updates erst schauen was sich geändert hat.

Für Postgres-Container würde ich Renovate übrigens ausschließen. Major-Upgrades zwischen Postgres-Versionen erfordern einen manuellen Datenbankdump und -import, das soll mir kein Bot automatisch reinschießen.

webhook installieren und konfigurieren

webhook gibt es als einzelnes Binary, alternativ auch als Paket:

apt install webhook

Die Konfiguration liegt unter/etc/webhook/webhook.conf:

-id:deployexecute-command:/opt/scripts/deploy.shcommand-working-directory:/opt/media-stacktrigger-rule:match:type:payload-hmac-sha256secret:"{{getenv \"WEBHOOK_SECRET\"}}"parameter:source:headername:X-Gitea-Signature

Ein paar Anmerkungen dazu:

Header-Name: Gitea schickt die Signatur alsX-Gitea-Signature – ohne-256-Suffix und ohnesha256=-Präfix im Wert. Das klingt trivial, hat mich aber beim ersten Versuch einen Debugging-Durchgang gekostet.

Secret als Umgebungsvariable: Das HMAC-Secret gehört nicht im Klartext in die Konfigurationsdatei, erst recht nicht wenn die Datei im Repo versioniert ist. Deshalb wird es pergetenv aus der Umgebung gelesen.

Das Secret generieren:

openssl rand -hex32

Und in eine Secrets-Datei schreiben die nur root lesen kann:

# /etc/webhook/secrets.envWEBHOOK_SECRET=dein-generierter-string

chmod600 /etc/webhook/secrets.env

Systemd-Unit

# /etc/systemd/system/webhook.service[Unit]Description=Webhook ReceiverAfter=network.target[Service]User=teqqy # Hier den eigenen Usernamen eintragenEnvironmentFile=/etc/webhook/secrets.envExecStart=/usr/bin/webhook -hooks /etc/webhook/webhook.conf -port 9000Restart=on-failure[Install]WantedBy=multi-user.target

User=teqqy sorgt dafür dass der webhook-Daemon und damit auch das Deploy-Script nicht als root laufen. Das ist mir wichtig – Prozesse die nur git pull und docker compose up ausführen müssen haben nichts als root verloren. Den Usernamen natürlich durch den eigenen ersetzen; der User braucht Zugriff auf das Repo-Verzeichnis und muss Mitglied derdocker-Gruppe sein.

EnvironmentFile lädt diesecrets.env und stelltWEBHOOK_SECRET als Umgebungsvariable bereit, bevor der Prozess startet – so kommt das Secret sauber in dengetenv-Aufruf der Konfiguration.Restart=on-failure sorgt dafür dass der Daemon bei einem unerwarteten Absturz automatisch neu startet, ohne dass man manuell eingreifen muss.

systemctl enable --now webhook

Gitea Webhook einrichten

In Gitea unterRepository → Einstellungen → Webhooks → Webhook hinzufügen → Gitea:

• Ziel-URL:http://media01.example.com:9000/hooks/deploy
• Secret: denselben String den du oben generiert hast
• Trigger: NurPush-Events reichen aus

Gitea berechnet bei jedem Push automatisch eine HMAC-SHA256-Signatur über den Request-Body und schickt sie alsX-Gitea-Signature-Header mit. Das webhook-Binary verifiziert die Signatur bevor es das Script ausführt – ein simpler Authorization-Header wäre hier deutlich unsicherer, weil man den Payload damit nicht gegen Manipulation absichert.

Port 9000 sollte nicht direkt ins Internet exponiert sein. In meinem Setup sind Gitea und der webhook-Daemon im selben internen Netz, der Port ist von außen nicht erreichbar. Wer den Endpunkt für eine externe Gitea-Instanz oder GitHub erreichbar machen muss, sollte das zumindest hinter einem Reverse Proxy mit IP-Beschränkung tun.

Das Deploy-Script

#!/bin/bashset -euo pipefailREPO=/opt/media-stackLOG=/opt/deploy-logs/deploy-$(date +%Y%m%d-%H%M%S).logexec >>"$LOG" 2>&1echo"=== Deploy$(date) ==="cd"$REPO"git pull origin maindocker compose up -d --remove-orphansdocker compose psecho"=== Done ==="

set -euo pipefail sorgt dafür dass das Script bei jedem Fehler sofort abbricht und einen Exit-Code ≠ 0 zurückgibt. Den loggt webhook dann ebenfalls, sodassjournalctl -u webhook bei Problemen der erste Anlaufpunkt ist.

Das Log-Verzeichnis muss dem ausführenden User gehören:

mkdir -p /opt/deploy-logschown teqqy:teqqy /opt/deploy-logs

Stolpersteine die ich unterwegs getroffen habe

.git-Verzeichnis Ownership: Wenn das Repo irgendwann mal als anderer User geklont oder gepullt wurde, verweigert Git den Zugriff mit einer Warnung zu “dubiosen Besitzverhältnissen”. Fix:

chown -R teqqy:teqqy /opt/media-stack/.git

safe.directory: In manchen Setups hilft zusätzlich:

git config --global --add safe.directory /opt/media-stack

/var/log Permissions: Der ausführende User hat dort keine Schreibrechte. Deshalb das Log-Verzeichnis in einen Pfad legen der dem User gehört – ich nutze/opt/deploy-logs.

*arr-Container und UID/GID: Meine*arr-Container laufen mit99:100 (Unraid-kompatibel wegen NFS). Beim allerersten Deployment legt Docker die Bind-Mount-Verzeichnisse mit1000:1000 an wenn sie noch nicht existieren. Einmalig vor dem ersten Start:

chown -R 99:100 /mnt/data/arr/

Danach ist das kein Thema mehr da die Verzeichnisse bereits existieren.

Monitoring

Ich setzeUptime Kuma (externer Link) ein und beobachte dort ob die Container nach einem Deployment noch sauber laufen. Das reicht für meinen Use Case: Wenn ein Container nach einem fehlgeschlagenen Update nicht mehr antwortet, schlägt Uptime Kuma an. Das deploy.log undjournalctl -u webhook liefern dann die Details warum es schiefgelaufen ist.

Ein Dead-Man’s-Switch (z. B. über Healthchecks.io) wäre der nächste sinnvolle Schritt wenn man auch merken will wenn ein Deploy einfachausbleibt – aber für einen Media-Stack ist das für mich nicht kritisch genug um extra Aufwand zu treiben.

Fazit

Das Setup ist jetzt seit kurzem in Betrieb und macht genau was es soll – ohne dass ich irgendwas an Komodo debuggen muss. Das webhook-Binary ist stabil, der Deployment-Flow ist deterministisch, und der Gesamtoverhead beschränkt sich auf ein paar Konfigurationsdateien und ein Shell-Script.

Wer ähnliche Anforderungen hat und kein Kubernetes betreiben möchte: Das ist meiner Meinung nach der pragmatischste Weg. Keine Magie, keine Frameworks, kein Overengineering. Nur git pull und docker compose up.

Bei Fragen oder Anmerkungen erreichst du mich über die Links in der Menüleiste.

Diejenigen die ein Homelab auch zum experimentieren und lernen nutzen, kennen das Problem: Nichts ist richtig und irgendwie machen alle anderen alles immer besser, schöner, toller. Naja, zumindest mir gehts häufig so wenn ich Blogbeiträge oder Posts inr/homelab (externer Link) lese. Eine längere Zeit nutzte ich Kubernetes für mein Homelab und habe damit einige Dinge gelernt. Die Umgebung hat auch Spaß gemacht, wurde mir aber irgendwann zu anstrengend zu administrieren. Ich setze Kubernetes nicht in meinem normalen Berufsleben ein, sodass mir häufig die Übung fehlt. Und daheim: Nunja, ist ja eher ein Homeprod als ein Homelab. Was ich in der ganzen Zeit aber super fand ist das GitOps Prinzip. Es machte die Pflege von Versionen einfach ohne mal wieder in einen riesen breaking change gelaufen zu sein der “alles kaputt macht”.

Mein Homelab sah also nach dem Weggang von Kubernetes so aus, dass ich diverse VMs für Docker Container hatte und divere LXC für einzelne Anwendungen. Ich hatte die meisten Container mittels:latest Tag versehen um mich so nicht mehr um die Updates großartig kümmern zu müssen. Watchtower hat sich dann um die Updates entsprechend gekümmert. Bei größeren Tools, oder denen häufiger ein breaking change enthalten ist, wie z. B. bei Immich, habe ich die Version gepinnt. Bekomme so aber nicht mehr mit wann ein neues Update erschienen ist. Zumindest nicht, wenn die Software nicht in ihrer Weboberfläche einen erinnert.

Als ich dann vor einiger Zeit auf Komodo aufmerksam gemacht wurde, haben sich meine Gedanken über mehrere Tage hinweg damit beschäftigt wie ich die Software gut in mein Homelab einbauen kann. Komodo ermöglicht nämlich das GitOps Prinzip bei Docker bzw. Docker Compose Umgebungen.

Das Grundprinzip meines Homelabs

Nachdem ich mir ein paar Blog Beiträge (z. B.den (externer Link) hier) und YouTube Videos (z. B.das (externer Link) hier) zu Komodo angeguckt habe, war mir klar, dass ich meine Docker Installationen damit verwalten werde. Gerade der Blog Post von Nick hat mich auch dazu gebracht wie das ganze im “Backend” ggf. aussehen könnte.

Der Stromverbrauch meines Homelabs hatte sich die ganzen Monate immer so zwischen 120 W und 150 W bewegt. Nichts tragisches für mich, aber ggf wäre auch eine Reduzierung möglich. Zudem hatte ich die ganze Zeit sämtliche Dinge immer auf meinen Unraid Server gesichert. Das wollte ich auch ändern. Ziel war es also alles auf einen Proxmox Host, anstatt vorher drei Kubernetes Nodes, zu bringen. Dazu sollte der Proxmox Backup Server als dedizierte Maschine mit eigenem Stroage bereit stehen. Die NFS implementierung von Unraid ist einfach extrem nervig.

Des weiteren wollte ich nicht mehr duzende virtuelle Maschinen oder LXC auf dem System am laufen haben, es soll alles etwas verschlankt werden. Allerdings bin und war ich nie ein Fan davon alles in eine VM zu quetschen. Aber das muss jeder für sich selbst entscheiden.

Wie sieht mein Homelab jetzt aus?

Mittlerweile habe ich nur zwei Thin Clients am laufen: Einen als Proxmox Host und einen als Proxmox Backup Server. Natürlich mein Unraid NAS noch zusätzlich. Aber auf dem Proxmox Server läuft jetzt alles. Der ist zwar sehr gut ausgelastet, wird aber in der nächsten Zeit noch durch einen Minisforum MS-01 ersetzt. Das hat den Vorteil, dass ich den PVE dann auch via 10 GBit anschließen kann. Perspektivisch würde ich nämlich gerne das Netzwerk etwas aufrüsten.

Die Fragmentierung meiner virtuellen Systeme hat auch stark nachgelassen. Auch wenn es noch etwas mehr sind als geplant. Manche Systeme lassen sich einfach schwer containerisieren bzw. möchte ich auf Grund von Hardwareressourcennutzung separieren. Im Grundlegenden habe ich vier wichtige virtuelle Maschinen:

1. infra01 - Für Infrastruktur relevante Systeme
2. docker01 - Für meine ganzen “normalen” Anwendungen
3. media01 - Für alle Anwendungen rund um Bewegbild
4. ha01 - Home Assistant

Dazu gesellen sich noch zwei AdguardHome LXC, meine LXC für die Wetterstation und Wetter Webseite sowie Nextcloud (zieht aber auch bald um). Gehen wir mal auf die einzelnen Systeme ein.

infra01 - Das Backend meine Homelabs

Als so ziemlich wichtigste virtuelle Maschine der neuen Infastruktur ist diese VM quasi das Herzstück des ganzen. Hier werden alle relevanten Anwendungen gehostet. Diese Maschine ist aber leider auch gewisser single point of failure. Dadurch das ich kein Cluster mehr betreibe, würde sich der Punkt sonst einfach nur verschieben. Da wir später noch auf den genauen Workflow eingehen werden liste ich euch nur die dortigen Anwendunge einmal auf:

• Traefik: Mein GoTo Reverse Proxy den ich eigentlich überall einsetze (Webseite:https://traefik.io (externer Link) )
• Gitea: Interner GIT Server für sämtliche Konfigurationsdateien (Webseite:https://about.gitea.com/ (externer Link) )
• Komodo: Deployment der Container (Webseite:https://komo.do/ (externer Link) )
• Uptime-Kuma: Verfügbarkeitsmonitoring der Anwendungen (Webseite:https://uptimekuma.org/ (externer Link) )
• Authentik: Single Sign On für fast alle Anwendungen (Webseite:https://goauthentik.io/ (externer Link) )
• Beszel: Lastmonitoring der Systeme (Webseite:https://beszel.dev/ (externer Link) )

docker01 - Anwendungen des täglichen Bedarfs

Auf dieser VM lasse ich so ziemlich alle Anwendungen laufen die nicht auf die beiden anderen Systeme gehören. Gegebenenfalls wird hier zu einem späteren Zeitpunkt noch mal eine zweite VM hinzu kommen um die Apps ein wenig zu verteilen. Schlussendlich laufen hier die Apps die ich inmeiner Top 10 schon verbloggt habe . Zusätlich aber auch Dinge wie

• Treafik
• AdGuardHome Sync: Synct meine beiden AdGuardHome LXC (Webseite:https://github.com/bakito/adguardhome-sync (externer Link) )
• autokuma: Halbautomatisches hinzufügen der Anwendungen zu Uptime Kuma (Webseite:https://github.com/BigBoot/AutoKuma (externer Link) )
• beszel-agent: Monitoring Agent für Beszel

media01 - Für das Bewegbild

Alle Anwendungen rund um Filme und Serien, bis auf Jellyfin finden sich hier. Jellyfin hat seinen eigenen LXC bekommen um besser auf die iGPU des Hostsystems zugreifen zu können. Zwar sind 99 % aller Medienwiedergaben DirectPlay, aber man weiß ja nie.

Mein Workflow

Schlussendlich ist es bis hier hier nicht so wirklich spannend. Einfach nur wie ich die diversen Anwendungen auf diverse virtuelle System aufteile. Spannender wird es aber mit dem eigentlichen Workflow, denn der nutzt wieder das GitOps Prinzip. Da Komodo leider keine verschlüsselten Secrets kann, wollte ich meine compose Dateien nicht mehr auf GitHub hosten, sondern auf meinem eigenen GIT Server. Für diese Zwecke nutze ich schon immer gitea, auch wenn es da mittlerweile diverse Alternativen gibt.

Ich habe also zwei Repositories auf meinem Git Server erstellt, einen für den docker01 als “apps-stack” sowie für den media01 als “media-stack”. Das sind 08-15 compose Dateien ohne weiteren besonderen Konfigurationen. Sobald ich Änderungen pushe wird ein Webhook zu Komodo gesendet. Dieser triggert dort einen Workflow um das Repo zu aktuallisieren und die Änderungen entsprechend auf dem Zielsystem zu deployen. Ich kann über diesen Weg auch dedizierte Konfigurationsdateien mitgeben die einzelne Anwendungen benötigen. So habe ich alles immer zusammen in einem Repo. Dieses Vorgehen gilt, wie geschrieben, für die den docker01 sowie für den media01. Die Anwendungen auf dem infra01 werden so nicht deployed. Gitea installieren zu können ohne ihn zu haben funktioniert nunmal nicht. Sobald Komodo verschlüsselte Secrets beherrscht würde ich die Dateien sicherlich wieder auf GitHub auslagern um direkt mit dem Deployment starten zu können.

Update Management der Container

In meinen Compose Dateien versuche ich Container zu verwenden deren Entwickler semver verwendet. Damit habe ich es einfacher die Container leichter zu updaten. Okay, eigentlich habe ICH es nicht einfacher, sondern Renovate. Renovate habe ich auch bereits in meinem Kubernetes Cluster verwendet, damals als SaaS jetzt auch selfhosted. Renovate läuft alle vier Stunden per cronjob und überprüft ob es in den angebenen Container Registry eine neuere Version gibt. Sobald das der Fall ist, erstellt mir der Service einen Pull Request in dem jeweilgen Repository. Diesen kann ich dann entsprechend aktzeptieren und der o. a. Workflow wird getriggert.

Sollte eine Anwendung extrem häufig eine neue Version veröffentlichen, kann ich natürlich auch ein automatisches commit erstellen, dann muss ich nicht mehr händisch eingreifen. Auf der anderen Seite kann z. B. Postgres bei Upgrades auf neue Versionen unschön werden. Derzeit wird es noch nicht unterstützt, dass die Datenbank einfach auf die neue Version gehoben wird, wie das bei MySQL oder MariaDB der Fall ist. Entsprechend schließe ich die Postgres Container von Renovate aus und belasse sie derzeit auf Version 17.

Backup und Restore

Im vorherigen Proxmox Cluster habe ich Unraid als NFS Storage eingebunden und darauf meine Backups gespeichert. Auch mit dem Proxmox Backup Server als virtuelle Maschine hatte ich eine Zeit lang dieses Vorgehen. Wie du Unraid NFS Shares als Ziel im Proxmox Backup Server einbindest, kannst du indiesem Beitrag lesen.

Weiter oben habe ich bereits erwähnt, dass ich nun einen dedizierten PBS einsetze. Dieser ist mit einer 1 TB großen SSD ausgestattet auf dem ich meine Backups speichere. Zuküftig möchte ich noch ein Backupsatz außer Haus speichern, weil ich sonst das 3-2-1-Prinzip nicht einhalten kann und mir das schon wichtig ist.

Fazit

Das Setup läuft jetzt noch nicht so lange, fühlt sich für mich aber stabiler und kompletter an. Zudem habe ich die Updates der Anwendungen wieder besser im Griff. Allerdings muss ich mich noch um die Updates für die Betriebssysteme kümmern. Dazu werde ich mir sicherlich ein Ansible Playbook schreiben dass das für mich vereinfachen wird. Solltest du Fragen oder Anregungen zu irgendwelchen Punkten haben, kontaktiere mich einfach über die Wege oben in der Menüleiste.

Im Februar diesen Jahres habe ich einen ersten Beitrag zu meinem kleinen k3s Homelab geschrieben. Seit dem ist echt viel passiert und vieles hat sich verändert und ist hinzu gekommen. Direkt von Anfang an gilt ein großer dank der k8s-at-home Community!

k3s homelab Hardware

Fangen wir wieder mit der Hardware an. Damals primär nur Raspberry Pis ist es jetzt ein Architekturmix geworden. Als Master laufen dreiRaspberry Pi (externer Link) 4 mit 4 GB RAM. Daetcd (externer Link) die SD-Karten zum Frühstück fressen würde, bin ich hier auf128 GB SSDs (externer Link) gewechselt die mittels einesUSB zu SATA Adapters (externer Link) angeschlossen sind.

Als Worker habe ich mir in den letzten Monaten gebrauchte Lenovo Thin Clients gekauft. Zwei davon sind mit 4-Kern Intel i5-6500T, 8 GB RAM, einer 128er SSD für das OS und einer 512 GB NMVe für ceph ausgestattet. Die zwei anderen mit einem Intel i3-6100T, 8 GB RAM und einer 128 GB SSD für das OS. Diese Hardware reicht völlig für ein k3s Homelab aus.

Software

Diese hat sich kaum geändert. Damals Ubuntu 20.04 LTS, heute Ubuntu 21.04 (non-LTS). Die Raspberry Pis haben natürlich die jeweilige 64bit Variante für ARM installiert bekommen.

Cluster-Ressourcen

CSI – Cluster Storage Interface

Longhorn (externer Link) habe ich den Rücken gekehrt. Für kleine Cluster ziemlich brauchbar. Sobald der aber etwas größer wird, bzw. viele Dateien verändert werden kam die Replikation nicht mehr hinterher. Entsprechend vielen häufiger Volumes aus und mussten aus dem sehr gut funktionierenden Backup wiederhergestellt werden.

Als CSI nutze ich mittlerweilerook-ceph. (externer Link) Ceph als unterliegendes verteiltes Dateisystem und rook als Tool um darauf zugreifen zu können. Einige in der Community verwenden auch einen externen Ceph Cluster, z. B. via Proxmox. Rook-ceph ist schön leichtgewichtig, schnell und zuverlässig!

Derzeit ist der Cluster leider „degraded“, weil meine virtuelle Node auf meinem Proxmox Host fehlt.

CNI – Cluster Network Interface

Als CNI benutze ich das default Netzwerk von k3s: flannel. Allerdings lege ich ein LoadBalancer noch oben drüber.

Damals gar nichts dazu geschrieben. Ich gehe mal davon aus das ich auch zu diesem Zeitpunkt bereitsMetalLB (externer Link) verwendet habe. MetalLB stellt mir IP-Adressen zur Verfügung damit externe Geräte auf bestimmte Dienste direkt zugreifen können, ohne Reverse Proxy.

Ingress Controller

Auch hier gab es einen Wechsel. Damals noch ingress-nginx (externer Link) werden heute sämtliche HTTPS Seiten mittelsTraefik (externer Link) publiziert.Traefik liefert mit allerdings nicht die Zertifikate, dies wird weiterhin vom cert-manager übernommen. Natürlich via Let’s encrypt.

Monitoring

Im Bereich Monitoring hat sich am Cluster nichts geändert. Weiterhin wird er kube-prometheus-stack verwendet. Auch wenn der etwas Ressourcenfressend ist, gibt es kaum eine andere Lösung. Prometheus selbst hält die Daten allerdings nur noch sechs Stunden vor. Anschließend werden sie in Thanos bereit gestellt. Grafana greift entsprechend direkt auf Thanos als auf Prometheus zu.

Benachrichtigt werde ich via Alert Manager in einem separatenDiscord (externer Link) -Server. Dieser schickt mittels Webhook entsprechende Informationen über Fehler und deren Behebungsstatus.

Was läuft in meinem k3s Homelab?

Eigentlich alles was ich im Homelab immer so laufen hatte. NAS und Firewall sind weiterhin separiert. Alles andere läuft als Container im Cluster. Ein paar Beispiele

• Home-Assistant (externer Link) incl.Mosquitto (externer Link) MQTT undzwavejs2mqtt (externer Link)
• Teslamate (externer Link) um die Daten unseres Model 3 abzufragen
• Paperless-NG (externer Link) als DMS
• FreshRSS (externer Link) als RSS Reader
• Jellyfin (externer Link) als Mediaplayer
• blocky (externer Link) als Netzwerk Werbeblocker
• u. v. m.

Deployment

Im Februar wollte ich noch nichts zum Deployment der Anwendungen und Container schreiben. Mittlerweile finde ich das Thema sehr interessant und wollte es ganz kurz vorstellen.

Ich verfolge mit dem k3s-homelab einen GitOps Ansatz. Heißt meine komplette Konfiguration aller Container und Dienste befindet sich in einemGitHub Repository (externer Link) . Allerdings nicht als einzelne Kind-Defintionen sondern alsHelm (externer Link) Datei. Sobald ich ein neuen commit im Main-Branch mache wird dies durchFluxCD (externer Link) von meinem Cluster gepullt und die Änderungen übernommen.

Ein Webhook benachrichtigt mich dann viaDiscord (externer Link) über entsprechende Änderungen oder Fehler.

Bei Fragen und Anregungen versuche ich dir natürlich gern zu helfen.

Ich dachte mir, dass ich mal ein paar Worte zu meinem mittlerweile angewachsenen Kubernetes Homelab schreibe. Nicht, dass das irgendwas weltbewegendes wäre, aber sicherlich für den einen oder anderen ein kleiner Denkanstoß oder Inspiration für eigenes.

Hardware

Hardware wird keine dedizierte eingesetzt. Ich habe auf meinem Proxmox Server vier virtuelle Maschinen erstellt. Dazu gesellen sich allerdings derzeit noch zweiRaspberry Pi (externer Link) 4 mit 4 GB RAM.

Software

Als Betriebssystem setze ich durchgehend auf Ubuntu 20.04 LTS. Bei den virtuellen Maschinen natürlich die amd64 und bei denRPi (externer Link) arm64 Variante.

Der Cluster selbst läuft mit Ranchersk3s (externer Link) anstatt eines vollen k8s.

Kubernetes Cluster

Allgemein

Der Cluster selbst besteht aus einem Master und fünf Worker. Ein Multimaster-Setup habe ich mir überlegt, allerdings für den Anfang verworfen. Auch wenn es mit k3s eigentlich ziemlich einfach gehen würde. Zumindest mit externer Datenbank.

Storage

Als Storage setze ich aufLonghorn (externer Link) . Longhorn, auch von Rancher, ist ein distributed block storage welches iSCSI im Hintergrund nutzt. Je Storage Node wird eine dedizierte Festplatte (so zumindest der empfohlene Weg) an den Cluster gereicht und alle Dateien werden entsprechend verteilt. Zwei Hosts sind hier das Minimum. Bei mir werden alle 4 virtuellen Maschinen dafür verwendet.

Ingress

In meinem kleinen k3s Tutorial habe ichTraefik (externer Link) als Ingress eingerichtet. Für meinen produktiven Cluster im Homelab allerdings setze ich aufNGINX (externer Link) . Es liegt einfach an der leichteren Konfiguration für Einsteiger. Traefik ist wie unter Docker sehr mächtig, allerdings hat mich das etwas überfordert, sodass ich mit dem leichteren Beginnen wollte.

Monitoring

Auch hier nutze ich den klassichen Weg und verwende denkube-prometheus-stack (externer Link) . Bohrte den allerdings noch mit etwasLoki (externer Link) auf. Loki ist ein Software um Logdateien aufzubereiten. Ähnlich wie man es vlt. vom Elastik Stack (ELK) kennt.

Ein Alerting via Alertmanager ist noch nicht im Einsatz. Dafür informiert mich Botkube über diverse Cluster-Ereignisse auf einen dedizierten Server.

Besonderheiten

Ich wollte von Anfang an nicht stur yaml-Dateien schreiben und diese mit kubectl in den Cluster jagen. Ich bin früh auf diek8s@home (externer Link) Community gestoßen die sich Rund um das Thema GitOps und Kubernetes im Homelab beschäftigen. Entsprechend wird mein Cluster auch komplett aus einemGitHub Repository (externer Link) gespeist. FluxCD zieht sich diese Daten und deployt sie im Cluster. Alles via Helm.

Das Problem ist noch, dass ich mich noch nicht um das Thema Secrets bemüht habe. Das steht für die nächste Zeit auf der Roadmap. Dann ist es auch möglich Tokens, Zertifikate und ähnliches aufGitHub (externer Link) zu speichern. Im können fast alle Dienste nur aus dem internen Netzwerk heraus erreicht werden.

Was hoste ich?

Ich würde diese Liste einfach mal nach Namespaces aufteilen. Ich liste allerdings nur weitere Software auf die nicht oben beschrieben sind.

home

• Home Assistant mit code-server
• Mosquitto
• Heimdall

network

• MetalLB
• cloudflare-ddns
• ntp

media

• Gaps
• Ombi
• Tautulli
• Plex