So fein das Selbst-Hosting mit Docker und/oder Proxmox auch ist, ein gravierender Nachteil ist allgegenwärtig: Mit der Zeit wächst die Infrastruktur um immer weitere Dienste an, insbesondere bei 24/7-Servern. Warum dem nicht noch eine Aufgabe mehr verpassen? Der Server zieht den Strom ja sowieso.
Somit wachsen auch die verwendeten IP-Adressen und Ports irgendwann so weit an, dass es unübersichtlich wird. So stellt sich dann die Frage: Wer soll sich das alles merken? Ohne seinen Browser mit Bookmarks vollzustopfen – was bei 20 bis 30 Adressen ebenfalls unübersichtlich wird.
Eine IP-Adresse lässt sich zwar im Browser mit einer Portnummer aufrufen. Für einen Healthcheck mittels ping funktioniert dies aber nicht, da ping keine Ports kennt. Und genau das möchtest du auf den ersten Blick wissen: Ist der Container noch da oder gerade abgestürzt?
Eine Möglichkeit ist dann, einen eigenen DNS-Server im Netz zu betreiben, um echte Namen wie nextcloud.lan in IP-Adressen aufzulösen. Da eine Namensauflösung aber ebenfalls keine Ports kennt, müssten alle Dienste hinter einer Portnummer vom DNS-Server an einen Reverse-Proxy im LAN weitergeleitet werden. Dieser übernimmt dann die eigentliche Zuleitung auf die entsprechenden Ports. Traefik ist hierbei ein üblicher Kandidat; allerdings wird das Setup dann echt kompliziert und wartungsaufwendiger. Sollen diese Dienste von außen erreichbar sein, kommst du um einen Reverse-Proxy nicht mehr herum, möglicherweise auch um eine eigene DMZ nicht.
Für diesen Beitrag will ich mich aber nur mit dem Betrieb im LAN befassen.
Es werde Überblick:
Und so kommen die Application-Dashboards ins Spiel: Webinterfaces, welche die verwendeten Dienste und Apps per einfachem Klick im Browser verfügbar machen. Dazu lassen sie sich gruppieren, unterschiedlich anordnen, teils mit Icons bestücken oder manchmal auch mit einer CSS-Datei im Gepäck noch stylisch aufarbeiten.
Auch hier gilt: Man wächst mit seinen Aufgaben, und plötzlich sind andere Werkzeuge mit vermeintlich komplexeren Konfigurationsmechanismen kein Hindernis mehr. Wenn du also mit einfachen Werkzeugen anfangen möchtest, ist das eine gute Entscheidung. Upgraden kannst du immer noch bei Bedarf.
Die Vorreiter: Heimdall, Homarr und Dashy
Als sehr einsteigerfreundlich wird Heimdall beschrieben, allerdings auch als veraltet. Dennoch ist in vielen Foren zu bemerken, dass Heimdall nach wie vor eine breite Anhängerschaft hat. Allerdings sind die Updates und neuen Features so gut wie zum Erliegen gekommen, und Heimdall ist eher eine Linksammler-App. Echte Metriken wie Docker-Status, Pi-hole-Queries oder CPU-Auslastung wirst du hier nicht finden.
Ebenfalls als einsteigerfreundlich gilt Homarr. Die Unterstützung von Pi-hole und Docker ist vorhanden. Die Konfiguration erfolgt primär über die GUI selbst, die die dazugehörigen JSON- bzw. YAML-Dateien im Hintergrund verwaltet. Etwas eingeschränkt in der Flexibilität zwar, aber erfüllt seinen Zweck voll und ganz.
Auch lässt sich Dashy zum Beispiel direkt im Webinterface/GUI konfigurieren. Dies ist im Grunde genommen aber nur ein Front-End für die Eintragungen in der eigentlichen config.yaml, welche auch „zu Fuß“ bearbeitet werden könnte. Dashy ist mächtig, die Lernkurve wird oft als hoch empfunden – bei einer reinen Linksammlung ist diese aber ebenfalls eher flach. Schwieriger wird es tatsächlich, wenn z. B. eine Pi-hole-Integration eingebaut werden soll. Hier dran bin ich, warum auch immer, gescheitert und habe dann irgendwann gewechselt.
Hier ein Screenshot meines nicht mehr genutzten Dashy-Dashboards. Bitte verzeiht mir das Zensieren der ganzen Einträge, aber welche Dienste ich hier exakt nutze, ist für den Beitrag nicht wichtig – und ich möchte dies auch nicht öffentlich servieren. Klar wird an diesem Board die saubere Übersicht durch Gruppierung – und die „Status-LED“, welche man pro Eintrag hinzufügen kann oder eben weglässt.
Ich habe mir hier angewöhnt, meine Container und Hosts sowie alle Bare-Metal-Geräte überwachen zu lassen, wie Router, 3D-Drucker und Raspis. Der Webshop natürlich ebenfalls. Allerdings bringt mir die Überwachung von DHL, dem Marktplatz-Anbieter oder auch des Kundenportals meines Hosters (für den Webshop) so erst mal nichts, da ich im Falle eines Ausfalls nichts daran ändern kann. Auf den Netzwerktraffic kann ich persönlich dann auch verzichten.
Der Fokus: Homepage
In diesem Artikel steht nun Homepage im Fokus. Das Einbinden von Pi-hole und auch Proxmox gelang mir auf Anhieb, was der Grund für den Wechsel war. Allerdings wird Homepage ausschließlich über YAML-Dateien konfiguriert, und davon auch gleich ein paar mehr.
Es unterstützt in beiden Fällen die API-Anbindung, aber auch die Docker-Engine-API und zum Beispiel Glances direkt. Dadurch sieht man zum Beispiel sofort, wenn eine VM herunterfährt oder ein Container nicht mehr zur Verfügung steht – bei entsprechender Konfiguration vorab natürlich. Diese ist zwar etwas technischer, insbesondere die Syntax mit ihren Einrückungen (wie für YAML typisch), aber einmal im Thema ist dies schnell umsetzbar. Homepage ist dazu meiner Meinung nach sehr gut dokumentiert.
Die Einrichtung von Homepage
Lasst euch da nicht verwirren von Foren, in denen über Doppelpunkte, Bindestriche und Gleichheitszeichen gestritten wird. So funktioniert es:
# docker-compose.yml
services:
homepage:
image: ghcr.io/gethomepage/homepage:latest
container_name: homepage
ports:
- 4001:3000 # Lege "deinen" Port fest.
volumes:
- ~/homepage/config:/app/config # Verzeichnis vorher anlegen bitte: 1) ~/homepage und 2) ~/homepage/config für persistente Daten
- /var/run/docker.sock:/var/run/docker.sock # (optional) Für Docker-Integrations, siehe alternative Methoden
environment:
HOMEPAGE_ALLOWED_HOSTS: 192.168.2.29:4001,homepage.local # Docker-Container, nicht die der Rechner im LAN, der darauf zugreift!
PUID: $PUID # in .env Datei definieren
PGID: $PGID # in .env Datei definieren. ID's findest du heraus in der Console mit dem Befehl 'id' - oftmals 1000.
Dashboard-Icons zur lokalen Hostung findest du hier: dashboardicons.com. (Wenn Anonymität dabei gefordert ist, mittels TOR-Browser einmalig downloaden) – ansonsten wird für den Download die IP-Adresse nun vermutlich übertragen, aber auch nur an diesem einen Tag; die Einbindung erfolgt dann dauerhaft lokal.
Ob SVG, JPG oder PNG ist beinahe egal und hängt von deiner Vorliebe ab. Homepage nimmt theoretisch alle drei Formate. Natürlich kannst du auch deine eigenen Kreationen hier verwenden. Achte aber bitte auf eine quadratische Form mit 256x256px oder 512x512px. Manch im Netz gefundenes Icon ließ sich bei mir übrigens nicht einbinden.
Einfach dieses Volume in der docker-compose.yml mit einbauen:
volumes:
- ~/homepage/icons:/app/public/icons # Stelle sicher, dass da Icons drin liegen!
Und zwar wirklich genau so. Wichtig ist der Pfad der Docker-Mount, da Homepage in genau diesem Ordner suchen wird. Ist dieser nicht korrekt, wird Homepage versuchen, das Icon über das CDN von Homarr zu finden – und dieses dann einbinden. Das läuft natürlich gegen den Ansatz, alles bei sich selbst zu hosten.
Ist dieser Pfad so angelegt und gemounted, die Icons vorhanden und mit den Rechten versehen, die der ausführende Nutzer hat, dann musst du Homepage noch mitteilen, dass es nun auch diese Icons nutzen soll – und nicht etwa die aus dem CDN von Homarr. Das geschieht in der services.yaml:
# services.yaml
icon: xxx.png # Sucht im CDN
icon: /icons/xxx.png # Sucht in der Docker-Mount /app/public/icons, also lokal
Im Browser klickst du einmal mit der rechten Maustaste über einem Icon und wählst „Untersuchen“. Wenn dort dann ein Link zu einem CDN erscheint, dann ist die Mount nicht korrekt gesetzt oder das Icon nicht vorhanden.
Schaue bei Problemen in deinen Container einmal hinein:
docker exec -it homepage /bin/sh
cd /app/public/icons # Wenn das schon auf einen Fehler läuft, dann ist die Mount nicht korrekt gesetzt
ls -l # Zeigt dir alle vorhandenen Dateien inkl. Rechte und Besitzer an.
Wenn die Mount nicht korrekt gesetzt ist, korrigiere deine docker-compose.yml wie oben beschrieben und starte den Container neu. Nicht mit docker compose restart bitte, sondern einmal sauber mit docker compose down gefolgt von docker compose up -d.
Die einzelnen YAML-Dateien
- bookmarks: Stehen dann ganz unten auf deinem Dashboard und können auch zweckentfremdet werden.
- docker: Hier kannst du verschiedene Docker-Hosts hinterlegen, direkt per IP/Port oder auch per Docker-Socket. Informationen zur Syntax etc. gibt es hier: gethomepage.dev/configs/docker
- kubernetes: Nutze ich nicht, also kann ich hier keine vernünftige Aussage zu machen. Siehe bitte: gethomepage.dev/configs/kubernetes
- proxmox: Bettest du lediglich Proxmox als Ganzes ein, werden dir auch nur die Informationen über den Node als solches angezeigt. Sollen einzelne VMs/LXC hier betrachtet werden, so sind in dieser YAML die Einstellungen dazu vorzunehmen. Die Syntax findest du hier: gethomepage.dev/configs/proxmox
- services: Trägst du deine IP-Adressen mit Ports ein, gruppiert. Für die fortwährende Überwachung der Erreichbarkeit noch ein Hinweis: Ports lassen sich nicht mit einem Ping ansprechen. Stattdessen kannst du
siteMonitorbei Ports verwenden, wie folgt:
# services.yaml
- Sell & Accounting: # Gruppe
- Webshop: # Menüpunkt
href: https://xxx.de # Link
description: Webshop # Deine Beschreibung
ping: https://xxx.de # So würdest du den Up/Down-Status einer Webseite oder einer IP-Adresse ohne Port abfragen
- Produktion:
- CRM:
icon: /icons/xxx.svg
href: http://192.168.0.1:8000/
description: Kundenkontakte
siteMonitor: http://192.168.0.1:8000 # siteMonitor ist für das kleine Monitoring von Ports dann die richtige Wahl
- settings: Formatierungen wie
rowsundcolumns: xwerden nicht auf Anhieb übernommen (auch mitdocker compose restartnicht). Das Einzige, was hier half, war die Umbenennung derservices.yamlin z. B..old, womit diese beim Browser-Refresh neu erstellt wurde (= leer bzw. Default); diese dann gelöscht und die zuvor umbenannte.oldwieder zurück umbenennen inservices.yaml. Dann wird die Datei offenbar neu eingelesen und mit den Eintragungen in dersettings.yamlerst richtig dargestellt. Den Grund für dieses etwas merkwürdige Verhalten habe ich nicht gefunden. - widgets: gethomepage.dev/widgets/info zeigt alle verfügbaren Widgets und die dazugehörige Syntax an. Die Liste ist umfangreich. Ob zu jedem Container nun wirklich detaillierte Informationen gewünscht sind, weißt du selbst am besten.
Hast du nun über die Services-Sektionen deine Gruppen erstellt und in den Settings die Zeilen/Spalten konfiguriert, könnte so etwas dabei herausgekommen sein:
Auch diesen Screenshot habe ich so weit neutralisiert, da ich die von mir genutzten Dienste nicht so gerne öffentlich ins Netz stellen möchte.
Konkrete Beispiele: Pi-hole und Proxmox
Für das Selbst-Hosting mit Proxmox und evtl. auch einer Pi-hol16e auf einem dedizierten Raspberry hier einmal die beiden Standard-Einstellungen:
Pi-hole:
- PiHole:
icon: pi-hole-unbound.png # Wenn im Icon-Ordner vorhanden
href: http://192.168.1.1 # (Optional) Link zur Pi-hole-Web-Oberfläche
ping: http://192.168.1.1
widget:
type: pihole
url: http://192.168.1.1 # IP oder Hostname Ihres Pi-hole
key: xxxxxxxx # Nur nötig, wenn Authentifizierung aktiviert ist
version: 6 # Pflicht für Pi-hole v6, standardmäßig auf 5 gesetzt
Proxmox:
- Proxmox:
icon: /icons/proxmox-light.svg
href: http://192.168.1.12:8006
siteMonitor: http://192.168.2.12:8006
widget:
type: proxmox
url: https://192.168.2.12:8006
username: # Siehe Anleitung!
password: # Siehe Anleitung! (Empfohlen: token_id & token_secret, siehe https://gethomepage.dev/configs/proxmox/#create-token)
Korrekt mit deinen Daten befüllt, sollte so etwas wie auf diesem Screenshot nun angezeigt werden, wobei zumindest bei Proxmox selbst weitere Metriken ausgegeben werden könnten, wie der Plattenplatz auf dem Node zum Beispiel – bevor hier ein ZFS-Laufwerk zum Beispiel die fiesen 80–90 % Belegung erreicht und dann irre langsam wird.
3D-Drucker und Moonraker
Weiterführend ließen sich unterschiedliche 3D-Drucker mit einbauen. Sofern diese über Klipper als Firmware verfügen, müsste nocheine separate Moonraker-Instanz pro Drucker hinzugefügt und konfiguriert werden. Ist neben Klipper jedoch Moonraker als Schnittstelle bereits auf den Druckern vorhanden, so entfällt diese zusätzliche Instanz und die Geräte können direkt angesprochen werden:
- 3D-Drucker:
- Gerät:
href: http://192.168.1.20
ping: http://192.168.1.20
widget:
type: moonraker
url: http://192.168.1.20
Ebenfalls gibt es hier Unterstützung für OctoPrint, welche eine ähnliche Kurz-Auswertung im Widget zurückgibt (Status, Fortschritt, Temperatur).
Auf dem großen Screenshot von Homepage weiter oben kannst du sehen, wie die 3D-Drucker dann abgefragt werden und welche Informationen zurückgegeben werden. Für weiter entfernte Geräte ist dies natürlich sehr praktisch, da man zum richtigen Zeitpunkt die Entleerung und den Neustart dann veranlassen könnte.
Styling mit CSS
Eine völlig nackte CSS-Datei liegt auch anbei (0 Byte, befüllbar). Dafür dürfte es die passende Füllung in unterschiedlichen Foren geben, falls keine CSS-Kenntnisse vorhanden sind. Keine Angst vor einer CSS-Datei: Diese „Cascading Style Sheets“ beschreiben für einen Webserver lediglich das Layout einer Webseite (Farben, Struktur, Schriftarten etc.). Wenn du also eine Schablone dazu z. B. bei Reddit gefunden hast, wird damit kein Sicherheitsrisiko entstehen – im Zweifel schaue dir die einzelnen Zeilen in der gefundenen CSS-Datei in Ruhe an und nimm dabei eine Referenz zur Syntax an die Hand, um zu verstehen, was welche Zeile bzw. welcher Block bewirkt. cssreference.org oder auch w3.org sind hier die richtigen Adressen.
Auch hier ist die Frage, was benötigt wird. Für reine Funktionalität brauchst du keine Einträge.
Zuletzt noch ein kleiner Tip: Möchtest du stylische Optik hinzufügen, so wären evtl. halb-transparente Blöcke schon mal sehr interessant:
div {
background: rgba(4, 170, 109, 0.3); /* Green background with 30% opacity */
}
/* Netzfund von w3schools.com */
Ich nehme speziell diesen halb-transparenten Block hier auf, weil das immer wieder hinterfragt wird und scheinbar zu einem gängigen Wunsch-Styling geraten ist. So wären dann jedenfalls die korrekten Parameter, anpassbar an deine Bedürfnisse.
Fazit
Mit einem gut eingerichteten Dashboard erhältst du nicht nur ein Stück mehr Überblick über die wachsende Anzahl an Containern und Diensten, sondern etablierst eine echte Steuerzentrale für dein Homelab oder auch dein KMU. Ob du dabei die schlichte Funktionalität bevorzugst oder das Ganze mit individuellem Styling aufpeppst, ist reine Geschmackssache.
Ebenso hängt die Tiefe der Integration – also wie viele Metriken du live im Dashboard sehen willst – von deiner Umgebung und deinen Bedürfnissen ab. Bevor ich bei Proxmox diese Daten automatisch auslesen und visualisieren ließ, musste ich mich mindestens einmal pro Woche händisch einloggen, um zu prüfen, wo die Ressourcen an ihre Grenzen kommen. Heute sehe ich das Problem als kleines Widget, bevor es kritisch wird. Das spart Zeit und Nerven.
Die hohe Anpassbarkeit und die saubere Struktur der YAML-Konfigurationsdateien sorgen dafür, dass du einmalig Zeit investierst und dafür ein Dashboard erhältst, das du beliebig erweitern oder umbauen kannst.
Und das Ganze ist selbstverständlich komplett selbst gehostet, inklusive aller Icons. Damit unterbindest du nicht nur den Zugriff auf fremde Content-Delivery-Netzwerke mit unklaren Standorten, sondern behältst die volle Datenhoheit. Bei jeder Nutzung deines Dashboards fließen keine Daten mehr ins externe Netz.
Wundere dich beim Stöbern im Netz nicht über die riesigen Dashboards, die du dort findest. Manche Enthusiasten „da draußen“ wachsen mit ihren Aufgaben, bis das Dashboard fast so komplex ist wie der Server selbst – und sie scheinen nie genug zu bekommen.
Thinkin ‚bout
