[TUT] Dockhand - Docker Management Alternative zu Portainer

eineb Ich erspare mir einen weiteren Kommentar. Nur so viel: Der Inhalt bzw. die Qualität mancher Posts ist manchmal grenzwertig, da gebe ich dir recht. Unterschiedlicher Meinung sind wir allerdings, falls es in einem Forum ausschließlich darum geht, dass jede/r irgendetwas ungefiltert rausposaunen können sollte, v.a. wenn es nicht stimmt. Gegen eine lebhafte oder kontroverse Diskussion bei einem strittigen Punkt habe ich überhaupt nichts einzuwenden. Bevor man jedoch andere bzgl. Forenklima tadelt, sollte man seine eigene Beiträge in manchen Threads auf Inhalt und Sachlichkeit überprüfen.

Quote from eineb

Wenn nur Helden ihre Ansicht äußern dürften, dann wäre das Forum ganz schön leer, und es besteht auch kein Anspruch auf 100% tige Aussagen, sondern wenn man anderer Meinung ist kann man den anderen darauf hinweisen oder die eigene Ansicht äußern.

Die "Schärfe" bringst du selbst hier rein, wenn du solche Aussagen postest (scheinbar fühlst du dich persönlcih angegriffen). Es war nicht die Absicht meines Beitrags, mich als "Held" aufzuspielen, aber ich gebe zu, dass manche Diskussion oder Lösungsversuche sehr ausufern. Wenn dadurch die Lösung schneller ersichtlich wird und dadurch die Beitragsliste etwas kürzer wäre, hätte ich persönlich nichts dagegen.

Aber ich verstehe auch, das manche in Foren eine neue Spielwiese sehen und sehr viel Zeit verbringen. Das kannst du jetzt interpretieren wie du willst.

Übrigens: Grenzwertig finde ich, wenn man eine andere Meinung so konnotiert (siehe folgendes Zitat) und dann auch das Forenklima bemüht, um seine herablassende Aussage zu rechtfertigen.

Quote from eineb

Kein Grund oberscchlaue Kommentare abzusetzen. wir sind hier um zu diskutieren

Solche Kommentare entsprechen keinem Austausch sondern snd im Sinne eines guten Forenklimas sehr grenzwertig!

Wenn keine Kritik mehr erlaubt ist oder man einen falschen Beitrag als solchen nicht mehr identifizieren darf, dann nehme ich gerne meinen Hut und kündige meine Mitgliedschaft in diesem Forum, bedanke mich für die nette Zeit und den -meistens- guten und interessanten Ausstausch. Denn eines habe ich gelernt: Viel Meinung äußern, heißt nicht immer das Richtige kundzutun.

Aber zurück zum eigentlichen Thema: steffenglock hat recht und ich schließe mich seiner Aussage an.

Quote from steffenglock

Sorry, aber anscheindend hast Du das System Docker noch nicht ganz verstanden. Jeder Docker Container stellt sozusagen eine eigene virtuelle Maschine dar die sich auch unabhängig von anderen administrieren, verwalten und verändern lässt.

Es geht ja hier nicht darum wer hat recht. Man legt mir hier etwas in den Mund, ich habe das schon verstanden, ich sags jetzt in wenigen Worten, wenn Dockhand aus irgendeinem Grund nicht mehr läuft, laufen zwar die Container weiter, können auch genutzt werden aber können nicht mit Portainer nicht ohne weiters verwaltet werden, sprich ohne die Stacks in Portainer neu aufzusetzen / zu übernehmen oder wie auch immer.

Quote from steffenglock

Beides bleibt lauffähig selbst wenn das andere deinstalliert wird! Das einzige Problem ist, dass die yml Dateien in unterschiedlichen Pfaden liegen. Wenn man das weiß wo die liegen, ist das kein Problem auch im Fall eines Backups.
selbst wenn einer von beiden abstürzt funktioniert der andere noch einwandfrei. Selbst wenn beide Container abstürzen kann man über :
docker stop <Container-Name-oder-ID> docker start <Container-Name-oder-ID>
Container starten und beenden und zum Beispiel mit filebrowser kann man die jeweilige compose.yml ohne Probleme bearbeiten! So geht da auch mit allen anderen compose-Befehlen.

Das sind aber keine Standarts mehr mit denen die meisten User nicht klar kommen (ohne diesen jetzt Nahe treten zu wollen) Fakt ist daß die eine Verwaltungsoberfläche von der anderen nicht einfach übernommen werden können und darum ging es mir . Das beste Beispiel ist die UGREEN Docker App.

Und daß es mehrere Wege gibt, das alles wieder zum laufen zu bringen hat nichts mehr mit der einer Problemlosen übernahme durch andere Verwaltungsoberflächen zu tun.

Ich habe ja auch geschrieben, wenn ich alles mit einer Docker Compose aufsetze, dann brauche ich garkeine Verwaltungsoberfläche.

Natürlich kann man beides gleichzeitig nebeneinander laufen lassen.

Quote from steffenglock

Es spricht überhaupt nichts dagegen beides gegenseitig zu installieren. Weder Dockhand über Portainer noch Portainer über Dockhand oder Compose!

So habe ich das auch nicht gesagt.

Quote from steffenglock

Alles in allem spricht meiner Meinung nach aus technischer Sicht nichts dagegen beides mal zu installieren und auszuprobieren. Aus Usability-Gründen sollte man sich aber am Ende für ein Tool entscheiden und dieses dann richtig zu beherrschen. Nur wegen eines Features was die andere App hat beide zu installieren, finde ich nicht sinnvoll und sehe es auf Dauer sogar als Fehlerquelle.

In sofern, nutzt was ihr wollt, wenn ihr wißt was ihr tut.

Hier gebe ich Dir völlig Recht und so sehe ich das auch.

Quote from Tommes

... oder von mir aus auch umgekehrt installiert? Ich hätte es vermutlich noch nicht mal über die UGOS Pro Docker App installiert, sondern eher nativ, per Docker Run oder Docker-Compose.

Docker-Compose ist eigentlich in meinen Augen der Idealweg, so habe ich bisher Portainer Grundsätzlich installiert,

Daß ich diesesmal für Dockhand die UGREEN Docker App verwendet habe, weil ich nicht wußte ob ggf. noch etwas angepasst werden muß, was als Projekt in der Docker App möglich ist. -> Dockhand war ja für mich Neuland.

Quote from Kosmo

(scheinbar fühlst du dich persönlcih angegriffen)

Ja das tut man wenn solche Komentare kommen. Das was war etwas das nur durch die Hintertüre an mich gerichtet war.

Anstatt zu sagen ich sehe das anders und erläuterung oder oder....

Quote from Kosmo

Manchmal erschreckt mich das Halbwissen, welches hier geäußert wird.

Oh. Ha. Na da habe ich ja was losgetreten mit meiner Frage, ob es Sinn macht, Dockhand über Portainer zu installieren.

Ich habe das eher aus Sicht der unterschiedlichen Verwaltungsoberflächen (Docker App, Portainer, Dockhand) betrachtet und weniger aus Sicht der Container die über welche Verwaltungsoberfläche auch immer installiert werden. Natürlich handelt es sich bei allen drei Genannten und WebUI‘s, um der Usability entgegen zu kommen, damit man nicht alles per CLI machen muss.

Das die Container unabhängig von der WebUI sind, war mir zwar bewusst, aber zugegeben, man kann als unbedarfter Benutzer schon ins grübeln kommen, wenn man die Zusammenhänge noch nicht vollständig in sich aufgenommen hat. Von daher danke ich dir steffenglock für deinen erleuchtenden Beitrag #20

An dieser Stelle möchte ich auch gleich alle Beteiligen darum bitten, das das hier nicht weiter eskaliert. Wäre schade drum.

Ich denke, das Grundproblem ist doch, dass Docker keinen standardisierten Pfad zur Ablage der Stack-Dateien bietet und deshalb jede Verwaltungsoberfläche ihr eigenes Süppchen kocht, oder?

Ich habe Portainer in aktiver Nutzung.

Dockhand habe ich erst vor kurzem mit diesem TUT hier installiert. Nutze beide sozusagen parallel. Nach Aufruf der WEB-GUI hat Dockhand alles, was in Portainer drin ist (immerhin, bescheiden trotzdem, AdGuard, Beszel, Cronicle, Dockhand, Immich, NGINX, Paperless, Vaultwarden und Watchtower) angezeigt/aufgelistet.

In Portainer habe ich die nicht so relevanten „ausgewatchtowert“. Wenn da was Aktuelles vorliegt, sagt mir Dockhand täglich per Mail Bescheid und ich update in Dockhand.

Ziel soll es sein (selbst das ist nicht so 100%tig), das ich alles auf Dockhand herüberbringe, wobei, wann muss man in Portainer und/oder Dockhand rein? Ich zumindest garantiert nicht täglich, wenn dann mal so wie „beim Nachbarn klingeln“.

Ich mag an Dockhand, dass es sowas wie Watchtower bereits eingebaut hat. Auch sich selbst kann es unter Settings, About aktualisieren.
Aber es hat auch Schwächen, beispielsweiße habe ich einer NPM-Container, wenn ich den versuche, über Dockhand zu stoppen, sagt Dockhand "Failed to load Containers" und behauptet, dass er weiterhin läuft. Portainer aber sagt, dass er steht.

Quote from Benares

Ich mag an Dockhand, dass es sowas wie Watchtower bereits eingebaut hat.

Besonders dabei gefällt mir auch, daß man manuell oder automatisch updaten lassen kann. So hat man bei manuell immer noch selbst den Finger drauf und kann erstmal abwarten ob in der Community über Probleme berichtet wird.

Bei Watchtower muß das ja unter Umständen für jeden Container Manuell angepasst werden.

Auf Dozzle und Beszel kan man im Prinzip auch verzichten, diese Infos kann man auch unter Dockhand finden..

Quote from Benares

beispielsweiße habe ich einer NPM-Container, wenn ich den versuche, über Dockhand zu stoppen, sagt Dockhand "Failed to load Containers" und behauptet, dass er weiterhin läuft.

Das ist zwischen der Dockerapp, bei manchem Container, und Portainer auch der Fall.

So hat halt jede Verwaltungsapp vor und Nachteile.

Quote from Benares

das Grundproblem ist doch, dass Docker keinen standardisierten Pfad zur Ablage der Stack-Dateien bietet

Das ist Freiheit und Problem zugleich. Persönlich denke ich, dass es irgendwann aber auf standardisierte Dinge raus laufen wird. In der Linux Welt ist es so, dass einer etwas entwickelt und dann rennen tausend Leute mit verschiedenen Ideen und Umsetzungen los. Am Ende setzt sich meist das Beste durch oder es entwickelt sich etwas ganz neues. Das hat den Vorteil, dass manchmal auch völlig unmögliche Dinge gedacht werden können.
Für jemand der aus einer "standardisierten Welt" kommt, wirkt dies oft wie Chaos und nicht wie Freiheit. Kommerzielle Unternehmen müssen in vielen Dingen Standars einführen weil das Team an Entwicklern sonst sehr ineffizient arbeitet. In der Opensourcegemeinde ist dies nicht der Fall.

Auch bei Docker gibt es "Richtlinien" an die sich alle halten. Eine der besten Standardtisierungen in Docker sind die YAML Dateien. Die erst ermöglichte es auch Nichtprogrammierern Einblicke zu erhalten. Auch die Netzwerkschnittstellen sind zentral geregelt und so könnte man weiter machen.

@all: Ich liebe Diskussionen und auch in diesem Forum! Diskussionen können durchaus auch hitzig geführt werden. Der Unterschied zwischen Kritik und Angriff liegt sehr oft in der persönlichen Wahrnehmung und ist von dem Gegenüber oft nicht so gemeint, gewesen. Deshalb: diskutiert weiter und seht Kritik immer als Erweiterung eures eigenen Horizontes an. (ich weiß ... fällt mir auch manchmal schwer, eine Tasse Kaffee und ne kurze Pause hilft dann meist)

Danke für die Diskussion und die tollen Informationen. Es war mir nicht bewusst, dass beide unterschiedliche Pfade benutzen um den Stack abzulegen.

Dann muss ich wohl für eine Lösung entscheiden.

Hab jetzt im Ugreen auf Dockhand umgestellt. Muss das jetzt noch in der VM umstellen.

Quote from peer

Dann muss ich wohl für eine Lösung entscheiden.

WEnn Du Dich entschieden hast, dann nimm einfach den stack aus dem einen UI , deaktivier den Container und erstelle den Container mit dem gleichen Stack im anderen Programm neu. Dann werden alle bereits vorhandenen Dateipfade (enviroments) übernommen und es läuft wie bisher mit genau den gleichen Einstellungen.
Wenn alles läuft, dann kannst Du den Stack im alten Programm einfach löschen.

Sollte etwas schief laufen, dann entferne den Container im zweiten Programm und reaktiviere den Container im ersten Programm.

Quote from steffenglock

WEnn Du Dich entschieden hast, dann nimm einfach den stack aus dem einen UI , deaktivier den Container und erstelle den Container mit dem gleichen Stack im anderen Programm neu

So wollte ich zu Anfangs auch vorgehen, aber Dockhand ließ den Stack nicht instalieren und gab eine Fehlermeldung aus, Sinngemäß wie daß er bereits in einem anderen Projekt am laufen ist. Wie die genau war weiß ich nicht mehr. Vorallem wenn bereits ein Volumen vorhanden war wurde das auch angemeckert.

Ich bin dann so vorgegangen, habe den Stack kopiert und in der Zwischenablage behalten.

Den alten Stack, Container, Image und ggf. Netzwerk Verbindung gelöscht (sonst gibt es am Ende 2 Verbindungen (wie auch bei mir passiert) und dann als einen neuen Stack in Dockhand reinkopiert und gestartet (Datenübernahme aus dem Dockerordner war dann kein Problem.

steffenglock

Genau so habe ich damals von Portainer auf Dockhand umgestellt . Hat alles reibungslos funktioniert.

Quote from eineb

Sinngemäß wie daß er bereits in einem anderen Projekt am laufen ist

das passiert meistens wenn der alte Container noch läuft. Den musst Du unbedingt stoppen und dann erst den neuen installieren. Sonst käme es zu Konflikten. Hier scheint dockhand schlauer zu sein. Portainer würde die gnadenlos installieren lassen und dir dann den Container als fehlerhaft (natürlich mit Fehlerbeschreibung in den logs) anzeigen.

Quote from steffenglock

das passiert meistens wenn der alte Container noch läuft. Den musst Du unbedingt stoppen

Hatte ich gemacht, das mache ich grundsätzlich sobald ich am Container oder darum herum mache. Nur beim manuellen Update eines Container unter Dockhand braucht man das nicht. So wie ich das sehe, übernimmt Dockhand das von selbst.

Quote from peer

Es war mir nicht bewusst, dass beide unterschiedliche Pfade benutzen um den Stack abzulegen.

Bei Dockhand liegt der StackOrdner direkt im entsprechenden Docker Verzeichnis, den hab ich bei mir normal mit in die wöchentliche Sicherung genommen, zur Sicherheit…..

Ich habe Portainer und Dockhand auch in einer VM betrieben. Grund Cloudflare-Tunnel für Nextcloud AIO, Vaultwarden und Kepassxc.

Der Umzug von Nextcloud war kein Problem. Vaultwarden zickte. Musste Daten erneut importieren und User anlegen. Es lag am hinterlegten Pfad des Data-Volumes. Ich habe mir nie Gedanken darüber gemacht. Es lief ja. Ich hatte vor Jahren die docker-compose.yaml ohne Änderung des Volume-Pfades übernommen (Nichtwissen eines Anfängers). Ich habe den Pfad jetzt angepasst.

Wenn man bei Portainer bei der Installation alles Standard lässt und auf volume1 installiert, dann packt es die ganzen compose Dateien in:

/volume1/@docker/volumes/portainer_data/_data/compose/

Dort erstellt es durchnummeriert für jeden stack einen eigenen Ordner. Bei mir sind darin 19 Ordner. In diesen Ordnern findet ihr jeweils eine docker-compose.yml Das ist die YML Datei mit den Daten welche ihr in Portainer beim erstellen des Stack angegeben habt.
In Filebrowser könnt ihr euch die Dateien sogar direkt anschauen, kopieren und sogar bearbeiten wenn ihr wollt.

Wenn ihr natürlich auf einem anderen volumen installiert habt, dann ändert sich entsprechend der Pfad.
ACHTUNG: Diesen Pfad könnt ihr in der Datei-App von ugreen nicht sehen! Hier müsst ihr auf andere Tools wie zum Beispiel filebrowser zurück greifen! (siehe meine Installationsanleitung) Ihr dürft dabei nicht die Standarddockerinstallation von ugreen nehmen! Sonst seht ihr die versteckten Pfade auch nicht weil sie ausgeblendet werden.

Was mir nicht so gut bei Dockhand gefällt, ist daß Dockand im Gegensatz zu Portainer keine eigene Backup Funktion hat. Bei Portainer konnte man halt mit 2-3 Klicks ein komplettes Backup erstellen und dieses zb, bei Serverumzug direkt bei der ersten Anmeldung in Portainer wieder herstellen.(im Portainer Backup befinden sich neben anderen Dateien auch alle vorhandenen .yaml Dateien). Vorausgesetzt, man hat ebenfals ein Backup des docker Ordner und desen beinhalteten Daten der Container ebenfalls als Backup mitgenommen ging das dann ratzfatz inkl. aller Daten der Container.

Diese Funktion hat mir sehr gut gefallen. vermisse ich ein wenig bei Dockhand. Natürlich kann man hier mittels einem Script das gleiche erreichen, oder die Stacks halt gleich beim aufsetzten des Containers händisch wegsichern.

Ich hab denn mal angefangen (hatte Zeit, Fußball nebenbei, Argentinien hat dank Wadentreter Messi gegen die Ösis gewonnen), Beszel (da ist ja auch meine DS224+ dabei) musste dran „glauben“, das läuft jetzt in Dockhand und in Portainer ist es deaktiviert. Die nächsten werden cronicle und Adguard. Vaultwarden, Paperless, NGINX, Immich kommen ganz zum Schluss.

Immer schön eines nach dem anderen. Eile mit Weile und nach mir nicht die Sintflut

Gute Nacht @Alle

eineb

Die Backup-Funktion soll kommen...seit Dez. 2025 "im Gespräch"...

Dockhand Roadmap

Dockhand Github Issus

Gruss

Camelot631