Am 17.09.2023 habe ich im zweiten Teil meiner Server-Reihe mit dem Titel Raspberry Pi als Heimserver – #2 – OMV & Docker ausführlich erläutert, wie sich auf einem frisch aufgesetzten Raspberry Pi OS neben OpenMediaVault auch eine performante Docker-Umgebung einrichten lässt. Über einen sehr langen Zeitraum hinweg gab es für mich im Docker-Ökosystem schlichtweg keine echte Alternative zu Portainer. Es galt aus meiner Sicht als das unangefochtene Standard-Werkzeug, wenn es darum ging, Docker-Container komfortabel über eine übersichtliche Weboberfläche zu verwalten. Aus diesem Grund betrieb ich über Jahre hinweg jeweils eine eigenständige Portainer-Instanz auf meinem externen vServer sowie auf dem lokalen Raspberry Pi im Smart-Home. Mit der Zeit keimte jedoch der verständliche Wunsch auf, die Verwaltung zu zentralisieren und den heimischen Raspberry Pi direkt über die Weboberfläche des vServers mitzubedienen. Sämtliche Versuche, eine solche plattformübergreifende Verbindung unter Portainer stabil einzurichten, schlugen in der Praxis leider fehl. Glücklicherweise entwickeln sich die Software-Optionen im Open-Source-Bereich stetig weiter, weshalb ich im April diesen Jahres auf das vielversprechende Projekt Dockhand aufmerksam wurde. Nach einer gründlichen Recherche stand für mich fest, dass ich dieser Lösung eine Chance geben wollte. In diesem Beitrag zeige ich dir, wie ich Dockhand sowie den dazugehörigen Agenten Hawser eingerichtet habe und warum Portainer bei mir inzwischen endgültig ausgemustert wurde.
Was ist Dockhand und wer steckt hinter dem Open-Source-Projekt?
Um die Motivation hinter dem Wechsel besser zu verstehen, lohnt sich ein genauerer Blick auf die Software selbst. Dockhand ist eine moderne, schlanke Verwaltungsoberfläche für Docker-Umgebungen, die als direkte, ressourcenschonende Alternative zu etablierten Schwergewichten wie Portainer konzipiert wurde. Entwickelt und vorangetrieben wird das Projekt von der Entwicklergruppe Finsys (fnsys) auf GitHub, die sich zum Ziel gesetzt hat, eine transparente, performante und visuell ansprechende Management-Plattform bereitzustellen.
Ein besonderer Schwerpunkt der Entwickler liegt auf einer klaren Architektur und der Vermeidung von unnötigem Overhead. Während andere Verwaltungswerkzeuge sämtliche Konfigurationen in geschlossenen internen Datenbanken kapseln, setzt Dockhand auf direkte Interaktion mit dem Dateisystem und dem Docker-Daemon. Dies vereinfacht nicht nur das Backup, sondern sorgt auch für eine außergewöhnlich hohe Geschwindigkeit bei der täglichen Nutzung. In Kombination mit dem separat bereitgestellten Agenten Hawser ermöglicht Dockhand zudem die nahtlose Anbindung entfernter Server-Knotenpunkte über eine verschlüsselte WebSocket-Verbindung.
Die entscheidenden Vorteile von Dockhand gegenüber Portainer
Nachdem ich die erste Dockhand-Instanz mittels Docker CLI auf meinem vServer aufgesetzt hatte, traten die Stärken des Systems im direkten Vergleich zu Portainer schnell zu Tage. Bereits nach wenigen Testläufen wurde mir klar, dass die Software das Potenzial besaß, meine bisherige Infrastruktur komplett abzulösen.
Die ausschlaggebenden Gründe für meinen endgültigen Umstieg lassen sich in folgenden Kernpunkten zusammenfassen:
- Transparentes Dateimanagement für Stacks: Die Erstellung und Pflege von Docker Compose Files ist in Dockhand spürbar eleganter gelöst. Während Portainer diese Dateien in einer internen Datenbank versteckt, legt Dockhand die Stacks direkt in einem zugänglichen Docker-Volume oder einem frei wählbaren Dateipfad auf dem Host-System ab. Dadurch bleiben alle Konfigurationen transparent, sicherer zu sichern und jederzeit manuell editierbar.
- Integrierte Update-Funktionalität für Container: Dockhand bietet eine native Möglichkeit, laufende Container mit nur einem Klick direkt aus der Benutzeroberfläche heraus zu aktualisieren. Bei Portainer musste man für automatisierte oder einfache Container-Updates zwingend auf externe Zusatzwerkzeuge wie Watchtower ausweichen, wozu ich im Beitrag Raspberry Pi als Heimserver – #4 – Watchtower bereits ausführlich berichtet habe.
- Sichere Verwahrung von Secrets: Ein extrem durchdachtes Feature ist die Möglichkeit, Umgebungsvariablen innerhalb von Container-Setups direkt als Secret zu deklarieren. Passwörter, API-Keys und sensible Zugangsdaten werden dadurch sauber gekapselt und tauchen nicht im Klartext in den regulären Konfigurationsdateien auf.
- Mühelose Multi-Server-Verwaltung: Über den schlanken Agenten Hawser lässt sich der heimische Raspberry Pi ohne komplexe Netzwerk-Klimmzüge direkt in die Dockhand-Instanz des vServers einbinden. Sämtliche Systeme lassen sich somit zentral über eine einzige Weboberfläche steuern.
Installation der zentralen Dockhand-Instanz auf dem vServer
Die Inbetriebnahme auf dem vServer erfordert keinerlei komplexe Konfigurationen und lässt sich innerhalb weniger Minuten über die Kommandozeile abwickeln. Nachdem ich mich per SSH und Putty auf meinem vServer eingeloggt hatte, reichte ein einziger Docker-Run-Befehl aus, um die voll funktionsfähige Instanz zu starten.
Der verwendete Befehl für das Deployment sieht folgendermaßen aus:
Bashdocker run -d \ --name dockhand \ --restart unless-stopped \ -p 3000:3000 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v dockhand_data:/app/data \ fnsys/dockhand:latest
Sobald der Container läuft, ist das Dashboard über den Port 3000 erreichbar. Von dort aus können sofort alle lokalen Container des vServers überwacht, Stacks angelegt und Systemeinstellungen vorgenommen werden.
Einbindung des Raspberry Pi mittels Hawser-Agent
Der eigentliche Durchbruch für mein Heimserver-Setup folgte an einem ruhigen Nachmittag, als ich mich an die Anbindung des Raspberry Pi gemacht habe. Um den Einplatinencomputer fernzusteuern, muss auf diesem nicht die gesamte Dockhand-Oberfläche installiert werden. Stattdessen kommt der extrem ressourcenschonende Agent namens Hawser zum Einsatz, der die Steuerbefehle der zentralen Instanz entgegennimmt.
Der Einrichtungsprozess startet direkt in der Weboberfläche von Dockhand auf dem vServer. Dort navigiert man zum Bereich der Umgebungen und fügt ein neues Environment hinzu. Als Umgebungstyp wählt man hierbei Hawser Edge aus. Nach dem Ausfüllen der erforderlichen Daten in der Eingabemaske erzeugt Dockhand einen eindeutigen Sicherheitstoken sowie die passende Verbindungs-URL.
Diesen generierten Token und die angepasste Server-URL habe ich anschließend in den Docker-CLI-Befehl übernommen und auf dem Raspberry Pi ausgeführt:
Bashdocker run -d \ --name hawser \ --restart unless-stopped \ -v /var/run/docker.sock:/var/run/docker.sock \ -v hawser-stacks:/data/stacks \ -e STACKS_DIR=/data/stacks \ -e TOKEN=<token> \ -e DOCKHAND_SERVER_URL=wss://<dockhand-url>/api/hawser/connect \ ghcr.io/finsys/hawser:latest
Nachdem der Hawser-Container auf dem Raspberry Pi deployed war, hat er sich augenblicklich und vollautomatisch mit der zentralen Dockhand-Instanz auf dem vServer verbunden. Seit diesem Zeitpunkt bin ich in der Lage, sämtliche Container und Stacks auf meinem Raspberry Pi direkt über das zentrale Dashboard meines vServers zu steuern.
Automatisierte Updates über ein maßgeschneidertes Wartungs-Skript
Ich nutze Dockhand nun bereits seit mehreren Monaten im produktiven Dauereinsatz und habe Portainer im Mai diesen Jahres auf all meinen Systemen vollständig gelöscht. Der Betrieb verläuft absolut stabil und ohne jegliche Ausfälle. Eine kleine Besonderheit zeigte sich jedoch im Wartungsalltag: Weder der Hawser-Agent noch die Dockhand-Hauptinstanz aktualisieren sich vollautomatisch selbst.
Um den Hawser-Container auf den neuesten Stand zu bringen, muss der bestehende Container gestoppt, gelöscht und mit dem aktuellsten Image neu aufgebaut werden. Um diesen manuellen Schritt nicht jedes Mal per Hand ausführen zu müssen und Fehler auszuschließen, habe ich die Update-Routinen direkt in mein bestehendes Server-Wartungsskript integriert.
Für die regelmäßige Aktualisierung des Hawser-Agenten auf dem Raspberry Pi kommt der folgende Skript-Abschnitt zum Einsatz:
Bashecho "Hawser Container wird aktualisiert..." local hawser_old_id hawser_old_id=$(docker images -q ghcr.io/finsys/hawser:latest 2>/dev/null) docker pull ghcr.io/finsys/hawser:latest > /dev/null 2>&1 || true local hawser_new_id hawser_new_id=$(docker images -q ghcr.io/finsys/hawser:latest 2>/dev/null) if [ -n "$hawser_new_id" ] && [ "$hawser_old_id" != "$hawser_new_id" ]; then docker stop hawser > /dev/null 2>&1 || true docker rm hawser > /dev/null 2>&1 || true docker run -d \ --name hawser \ --restart unless-stopped \ -v /var/run/docker.sock:/var/run/docker.sock \ -v hawser-stacks:/data/stacks \ -e STACKS_DIR=/data/stacks \ -e TOKEN=<token> \ -e DOCKHAND_SERVER_URL=wss://<dockhand-url>/api/hawser/connect \ ghcr.io/finsys/hawser:latest > /dev/null 2>&1 || true echo "Hawser erfolgreich aktualisiert" else echo "Hawser ist bereits auf dem neusten Stand" fi
Auf dieselbe elegante Weise wird auch die zentrale Dockhand-Instanz auf dem vServer über das Wartungsskript gepflegt und auf neu veröffentlichte Versionen geprüft:
Bashecho "Dockhand Container wird aktualisiert..." local dockhand_old_id dockhand_old_id=$(docker images -q fnsys/dockhand:latest 2>/dev/null) docker pull fnsys/dockhand:latest > /dev/null 2>&1 || true local dockhand_new_id dockhand_new_id=$(docker images -q fnsys/dockhand:latest 2>/dev/null) if [ -n "$dockhand_new_id" ] && [ "$dockhand_old_id" != "$dockhand_new_id" ]; then docker stop dockhand > /dev/null 2>&1 || true docker rm dockhand > /dev/null 2>&1 || true docker run -d \ --name dockhand \ --restart unless-stopped \ -p 3000:3000 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v dockhand_data:/app/data \ -e DATA_DIR=/app/data \ -e PGID=1001 \ -e PUID=1001 \ fnsys/dockhand:latest > /dev/null 2>&1 || true echo "Dockhand erfolgreich aktualisiert" else echo "Dockhand ist bereits auf dem neusten Stand" fi
Mithilfe eines wöchentlich ausgeführten Crontabs läuft dieser gesamte Prüf- und Aktualisierungsprozess nun vollautomatisch im Hintergrund ab. Dadurch ist sichergestellt, dass sämtliche Management-Komponenten ohne mein Zutun stets auf dem aktuellsten Stand gehalten werden.
Fazit und Bewertung der mobilen Nutzung
Ein Punkt, der bei Server-Verwaltungswerkzeugen oft vernachlässigt wird, ist die Nutzung auf mobilen Endgeräten wie Smartphones oder Tablets. Die mobile Ansicht von Dockhand schneidet im Vergleich zu Portainer spürbar besser ab und ermöglicht das schnelle Überprüfen von Container-Zuständen von unterwegs. Perfekt ist das mobile Responsive-Design zwar noch nicht, allerdings arbeiten die Entwickler sehr aktiv an der Weiterentwicklung. Für den alltäglichen Gebrauch kann ich mit dem aktuellen Stand hervorragend leben.
Zusammenfassend hat der Wechsel zu Dockhand meine Server-Infrastruktur erheblich vereinfacht. Die Kombination aus transparenter Dateispeicherung, integrierten Container-Updates, sicherer Secrets-Verwaltung und der einfachen Anbindung des Raspberry Pi über Hawser macht Dockhand zur idealen Wahl für jeden Heimserver-Betreiber.
Hast du noch Fragen?
Hast du noch Fragen zu diesem Beitrag? Dann ab damit in die Kommentare oder schreib mich über Mastodon an.
Dies könnte dich auch interessieren…
Du möchtest weitere Inhalte von mir lesen? Schau doch mal hier: Wieviel Datenvolumen braucht man wirklich?
