dockhand als mögliche portainer Ablösung

[the other]

Moinsen,
ich beschäftige mich gerade das erste mal ein wenig mit einem Ersatz für Portainer. Da ich gerne mit der GUI (wenn sie denn vernünftig gestaltet ist) arbeite, verwalte ich meine Stacks, Images und container von Anfang an mit Portainer CE (community edition). Das ist auch ganz nett bisher.
Eher nebenbei bin ich gestern Abend über eine Alternative gestolpert, die seit einer Stunde hier auf dem "Versuchsrechner" läuft: dockhand. Kurz gestern noch im Netz gesucht, scheint so, als wäre ich einer der letzten, die damit in Kontakt kommen.
Nutzt ihr für eure container direkt das Terminal? Oder auch eine grafische Oberfläche wie eben zB Portainer? Oder sogar schon längst dockhand? Oder was ganz anderes?

Ich bin bisher recht begeistert, die Oberfläche sieht ok aus, die Optionen zur Container, Stack, usw Verwaltung sind deutlich mehr (und sinniger) als bei Portainer.
So kann zB direkt für alle nach einem Update gesucht werden per einfachem Klick (nur gesucht, nicht direkt installiert zum Glück!), da ich kein watchtower nutze also ganz nette Zeitersparnis. Außerdem kann das Programm (selber als container) auch mit User PUID laufen. Und beim download neuer Images werden diese auf Wunsch auch durch 2 weitere Erweiterungen (grype und trivy) auf bekannte Verwundbarkeiten gescannt. Auch nett.

Es können auch remote hosts mit laufender docker Umgebung einbezogen werden, soweit bin ich aber noch nicht. Falls ihr das Programm bereits kennen solltet, schreibt doch mal eure Erfahrungen damit kurz auf. Falls nicht und ihr seid auch weniger CLI als GUI, dann schaut mal rein...ist recht schnell aufgesetzt. Hier die Doku dazu.

 

[Fusion]

Willkommen im Club. Hab Dockhand seit ein paar Wochen laufen. Parallel Dockman, das ist im Vergleich etwas einfacher gestrickt.

DockGE und Dockmate habe ich schon entsorgt.
Ich mach auch viel direkt in CLI, da ist mir der Unterschied / Mehrwert zu gering.

Lazydocker habe ich nie probiert und Arcane klingt schon wieder zu 'professionell'.

Die ersten beiden haben für mich genug 'Mehrwert' (z.B. Multihost) , da ich eben nicht alles per Script, ansible playbooks oder ähnliches Infrastruktur tools automatisiert habe.

 

[the other]

Moinsen,
hast du eigentlichzusätzlich einen docker socket proxy laufen oder geht das bei dir auch eher mit den ENV_VARIABLES über "normale" Userrechte? Ich hab hier zwar eh alles nur streng lokal (oder eben VPN), aber wenn irgend möglich hat alles andere (2 andere container) maximal read only oder eben (zusätzlich wenn möglich) laufen nicht als root bzw non-privileged.

 

[Fusion]

Ja, den habe ich mal über socket-proxy.
Dockman läuft noch direkt über socket und eingeschränkte Rechte für Container, aber den wollte ich auch noch umstellen , wenn ich Zeit habe. Außerhalb des Rechners sind nur die via reverse Proxy konfigurierten Dienste erreichbar, weder der proxy noch die Containerverwaltung (nur via VPN oder lokale source IP).

 

[the other]

Moinsen,
hatte kurz drüber nachgedacht und bin dann doch beim alten geblieben...ist aber ja aktuell auch nur als Test am Laufen. Sollte ein Umzug aufs eigentliche Dockersystem anstehen, dann kann ich den Kram auch gleich mit socket proxy aufsetzen. Dann laufen beszel-agent, uptimekuma und homepage auch zukünfig so (siind eh alle nur read only).
Danke für deine Info .

 

[Confluencer]

Einer der Docker Mitarbeiter hat einen recht ausgebufften docker-socket-proxy herausgebracht: https://github.com/mikesir87/docker-socket-proxy

Etwas komplexer in der Konfiguration, dafür erlaubt er Filter einzusetzen und im Gegensatz zu den anderen Lösungen nicht nur die generelle Ressource erlaubt/verbietet, sondern auch explizit Ressourcen mit Namen zu erlauben/verbieten kann.

 

[Fusion]

Man lernt nie aus.

Da ich es beruflich nicht brauche dauert das ausprobieren bei mir tendenziell immer etwas länger. Und zu optimieren gibt es auch immer was.
Portainer hatte ich noch nie laufen.

Die 'produktiven' Container laufen aktuell via nginx proxy manager und mit Benutzereinschränkung, teilweise mit auf dem LXC, teilweise noch auf der Syno.
Da ich das aufräumen will jetzt zum testen eine Instanz in einem LXC mit Dockman und Dockhand/socket-proxy (und verschiedene kurzlebige Container die ich mir immer schon mal anschauen wollte) und NPM und eine zweite Docker Instanz in einer VM mit temporärem NPM und auch temporären Containern.
LXC vs VM habe ich schon hier und da was gelesen, aber selbst noch keine Probleme mit LXC bekommen. Vielleicht zu wenig oder die 'falschen' Container bis jetzt. Falls was nicht geht habe ich ja zwei Instanzen zur Verfügung und nehme dann halt die VM dafür.

Den NPM will ich wahrscheinlich auch gegen einen 'nackten' nginx proxy wechseln.
Grund ist die gewachsene Struktur wo meine verschiedenen Domains gehostet sind und welche Dienst davon acme DNS Challenges für Wildcards unterstützt.
Da nutze ich aktuell acme.sh mit dns/domain alias challenge um ohne Ports und für beliebige Domains über einen Anbieter mit DNS Api die Zertifikate holen kann. Bei den anderen reicht ein CNAME Eintrag für den Aufruf des TXT records für _acme-challenge
Muss also nicht API Daten von beliebigen Hostern auf beliebigen Systemen verteilen und bekomme auch gleich Hosted ohne API abgefrühstückt.
But for the life of me bekomme ich dem NPM die Wildcards nicht automatisch untergeschoben. Einzig die custom_X Zertifikate die einem Container Dienst zugeordnet sind kann ich mappen. Aber jedes mal wen man Dienste ändert etc verschiebt sich die ganze Nomenklatur, da hab ich keinen Bock hinterher zu scripten, oder immer dran zu denken, doll ja automatisch laufen.
Und die Funktionen in der GUI für dns LE kann ich nicht nutzen, weil ausgerechnet dieser Hoster kein DNS API hat.
Also entweder Domain umziehen, oder proxy tauschen den ich dann per acme.sh füttern kann.

Falls da irgendwo ne ganz dumme Idee dabei ist, lasst es mich wissen. Bei Bedarf und je nach Umfang kann man das dann woanders ausdiskutieren.

 

[Confluencer]

Also entweder Domain umziehen, oder proxy tauschen den ich dann per acme.sh füttern kann.

Ich hab die technische Administration meiner Domains genau deswegen vor Jahren von NetCup zu Cloudflare gezogen. Sprich: NetCup ist nur noch Registrar und Rechnungssteller bei mir. Ich hab bei Cloudflare noch nie einen Cent dafür bezahlt.

 

[the other]

Moinsen,
Bis vor wenigen Wochen habe ich ausschließlich auf selbst signierte Zertifikate gesetzt, die dann je auf dem host installiert wurden. Nervig, aber 10 Jahre gültig. Und alles rein für den internen Gebrauch.
Dann, weil es abzusehen ist, dass die Browser solche beizeiten nicht mehr akzeptieren, endlich mal in den gedacht sauren Apfel gebissen:
Zuerst eine Domain bei netcup registriert. Dann den NS Record direkt via cloudflare gesetzt. Entgegen der best practices auf eine private IP als A Record gesetzt und wildcards angelegt als CNAME.
Dann gemäß Anleitung für LE in nginx proxy manager eingebunden. Lief erst nicht, weil mein username@example.com keine echte Email war. Da dann eine existierende eingetragen und es lief und läuft seitdem.
Alle container, home assistant VM und das NAS mal damit versorgt. Sehr schön. Aktualisierung läuft auch. Und eben alles mit DNS-challenge. Hatte kurz mal überlegt, das per HAProxy auf der pfsense zu machen, aber ich lasse es erstmal bei der Trennung zwischen LE für virtuelles und self signed für "echte" hosts (Router, switch, usw). Mir geht es dabei ganz einfach um die Ersparnis der nervigen Portangaben und einer schöneren usability. Öffentlich hosten tue ich nix und werde das auch nicht. Daher bin ich mit dem Konstrukt erstmal ganz happy.

 

[Fusion]

Der Hoster in question ist Strato. Bei Netcup finde ich den langen Commit / DNS propagation extrem nervig (1800, 2400, 3600 Sekunden oder wie lange man auf den TXT record warten musste). Ja, ist automatisiert, aber trotzdem....
Deshalb habe ich meine Alias-Domain (bzw. DNS Verwaltung dafür) bei Hetzner, da reichen die 20s Standard Delay.

Cloudflare schön und gut, aber ich habe eine leichte Abneigung gegen dieses so gut wie Monopol. Zugegeben, schneidet man sich manchmal selbst ins Fleisch, und vielleicht nicht die rationalste Entscheidung.
Könnte natürlich auch die DNS Verwaltung von dort wegnehmen und Domain / Email trotzdem dort liegen lassen.