Docker Update auf neuer als 17.05?

[nachon]

Bei mir läuft es leider nicht ganz so rund. Ich hatte gerade aktualisiert und wollte einige Container neu aufsetzen.
Pustekuchen. Ich bekomme meine Container zwar gestartet und die übernommenen laufen auch, aber neu einrichten geht leider nicht. Verzweifel schon seit Stunden hier.
Nun muss ich wohl downgraden. So ganz funktioniert Docker bei mir noch nicht wie gewünscht.

Leider.

 

[haydibe]

Also ein simpler Test mit 'docker run -ti --rm -p 8080:8080 ehazlett/docker-demo' läuft bei mir wie erwartet: der Container ist über http://dsm-ip:8080 zu erreichen.

Update: über die UI klappt es genauso....

 

[nachon]

Vielleicht liegt es auch nicht an der Version. Aktuell versuche ich Nextcloud wieder zum laufen zu kriegen aber irgendwie hat sich das komplett zerschossen. Auch ein komplett neues Aufsetzen von Docker, DB und Nextcloud hat gerade nichts gebracht.
Ich habe gerade keine Ahnung mehr, ruder aber zurück und vermute gerade, dass es zumindest nicht an der Version liegt.

Hmm.

 

[haydibe]

Ich würde die Ausgaben von 'docker info' vergleichen.
wenn Docker auf einem anderem Volume installiert wird, oder der "Storage Driver" anders ist, sind die Daten in "Root Dir" nicht mehr weiterbenutzbar.

 

[nachon]

Danke. Aktuell nutze ich Docker in einer DS mit nur einem Volumen. Bisher lief alles perfekt, ich wollte lediglich Nextcloud aktualisieren. Damit nahm das Übel seinen Anfang und nun bekomme ich es gar nicht mehr eingerichtet und ans laufen. Auch die DB nicht mehr. Aber dazu sollte ich wohl einen eigenen Thread aufmachen. Grr. Danke.

 

[haydibe]

yep!

Update:
Nach einem 'docker swarm init --advertise-addr {dsm-ip}' kann man sogar swarm nutzen.
Das "ingress mesh routing" funktioniert nicht, was aber weiter schlimm ist und kann beim publishen der ports durch "mode=host" durch ein direktes Host-Binding umgangen werden, erlaubt dann leider aber auch keine Replikation.

docker service create --replicas 1 --name overlay-test --publish published=8080,target=8080,mode=host --detach=true ehazlett/docker-demo

Was ich jetzt nicht getestet habe ist, ob man einen reverse proxy (traefik/nginx) vor einen Service mit mehreren Replikaten hängen kann.
Update2: zumindest ist die Kommunikation innerhalb eines Overlay-Netzes mit n replicas möglich, aber nicht wir erwartet...
Es müsste mit "{{servicename}}.{{netzwerkname}}" funktionieren, hier ist der Host dann aber nicht erreichbar. Mit "tasks.{{servicename}}" geht es wie erwartet auch.

Hier stimmt etwas mit dem Overlay-Netzwerk nicht. Das mit dem Ingress-Netzwerk hatte ich ja schon geschreiben.
Es fehlen die notwendigen Kernel-Module: ip_vs_rr, xt_ipvs und ip_vs. Die kommen dann hoffentlich mit DSM7 mit.

 

[helmut72]

Auch danke für den Hinweis! Vielleicht behalt ich ja doch die 716er anstatt 116er. Showstopper bleibt weiterhin die X-Forwarded-For Sache.

 

[haydibe]

Schonmal mit traefik als reverse proxy versucht?
Die Inital-Konfiguration ohne Letsencrypt-integration is trivial. Mit automatischem Letsencrypt-Handling braucht es in jedem Fall eine .toml-Konfigurationsdatei, die aber auch nicht wirklich schwer zu erstellen ist.
Danach kann man die Routing-Regeln als Label am Container anbringen - allerdings dann nur über die cli, bzw. docker-compose.

 

[helmut72]

Nein. Und wenn, dann würde es Caddy 2.0 werden. Bis dahin bleibt es der Apache. Und überhaupt wird es mit Traefik ebenfalls nicht funktionieren, weil der Fehler bei einigen Docker-Installationen bekannt ist, aber schon Jahre offen. Darauf setze ich nicht. Den Hund, den Synology reingehauen hat, gibt es auch mit Docker unter Mac und Windows.

Außerdem suche ich mir nicht das Produkt nach einem Fehler im System aus

Für Lets Encrypt habe ich mir mühevoll ein eigenes Docker-Image gebaut, dass ein Wildcard-Zertifikat erstellt. Ich brauche die Zertifikate für Reverse Proxy und Mailserver. Das Volume mit dem Wildcard-Zertifikat binde ich dann bei beiden Container mit ein und mein Letsencrypt-Container startet beide neu, falls es ein neues Zertifikat gibt.

 

[haydibe]

Den Hund, den Synology reingehauen hat, gibt es auch mit Docker unter Mac und Windows.

Die Mac- und Windows-Varianten sind ja auch echt mal für'n ****!! Docker in einer VM kann sich nunmal nicht identisch verhalten wie ein Docker direkt auf nem Linux-Host. Ich meide beide Varianten. Gefühlt haben die Leute auch nur Probleme mit diesen beiden Varianten.


Du meinst das da ein Fehler direkt in der Docker-Engine verankert ist? Wo/Wie? Hast Du einen Link auf ein Github Issue dazu? Das würde mich näher interessierne.

Ich mag den Ansatz, dass Traefik sich aus den Container create/remove events die Proxy-Regeln zieht und direkt anwendet. Bis auf die DNSChallange-Konfiguration für Letsencrypt musste ich nie etwas für die Letsencrypt-Wildcard-Zertifikate tun.

Hauptsache man findet eine Lösung die für einen Funktioniert.

 

[helmut72]

Bitteschön:
https://github.com/docker/for-mac/issues/180

Gleiches auf Synology. Auf meinem Ubuntu mit Docker funktioniert das einwandfrei. Ich kann von Fail2ban nicht die IP des Reverse Proxy blockieren lassen, weil ja dann logischerweise alles blockiert wird... absoluter Showstopper.

Mach Dir keinen Kopf, warum ich was verwende. Der neue Server hat 16GB RAM, bei der DS716 ist (inoffiziell) bei 8GB RAM Ende. Der doppelte RAM kommt mir entgegen, um noch für Guacamole ein paar virtuelle Maschinen zu starten, wenn ich einen Remote-Desktop benötige. Dann läuft ständig nur eine Hardware, weil ich EON nicht mit Absicht finanzieren möchte.

 

[haydibe]

Danke für den Link, bei Docker-Machine und Docker Desktop (Win/Mac) würde ich auch nichts anderes erwarten. Ich hatte auf einen Link auf einer der offiziell unterstützen Linux-Varianten gehofft.

Gratulation zur neuen Kiste. Ich hab auch noch kaum Docker Sachen auf der Syno. Wollte nur ausloten was die neue Version so kann und was mal wieder nicht geht.
Ich wünschte ich hätte die Disziplin meinen Stromanbieter nicht zu finanzieren. Mein Cluster verbrät bestimmt gut 2,5kw am Tag.

 

[helmut72]

Unter Linux funktioniert ja Docker einwandfrei, wenn man nicht gerade DSM von Synology verwendet...

So neu ist die Kiste nicht, die hat nahezu die gleiche CPU wie die DS716, aber war halt bisher die Spielwiese. Der Umzug zieht sich sicher noch bis Weihnachten, bis ich mir mit meinem Konzept und ausprobieren einig bin. Deshalb stolpere ich ja über die beschriebenen Sachen und im Sommer gibt es besseres als ständig vor dem Rechner zu hängen.

 

[stesoell]

Moin, bei mir hat's nach dem Update auf v18.09 OnlyOffice zerschossen. Dateien werden bei Öffnung heruntergeladen, nicht editiert. Keine Ahnung ob es an verwendeten Docker Storage Engine liegt, Synology hier und da sein eigenes Ding baute...

Erstmal downgraden

Edit: ok, hätte erstmal hier lesen sollen. Scheint ein Problem mit den ENV Variablen zu geben...
https://community.synology.com/enu/forum/15/post/128146

Oh man , Synology ....

 

[haydibe]

Tests bestätigen: es ist leider wirklich so!

Getestet mit folgender compose-compose.yml, die einen Ubuntu Container zum "rein-execen" erzeugt:

version: '3.7'

services:
  ubuntu:
    image: ubuntu:18.04
    environment:
    -  TEST=test
    command: ["tail","-f","/dev/null"]

Es ist dabei unerheblich, ob die ENVs als Liste oder KeyValue-Map angegeben werden: im Container fehlen sie.
Weder innerhalb des Containers mit `docker exec {containerid} env` noch mit `docker inspect {containerid}` sind die ENVs zu sehen.

Was dagegen funktionert: `docker run -d --rm -e Test=test ubuntu.18.04 tail -f /dev/null`
Ob es über die UI funktioniert habe ich jetzt nicht getestet.

 

[stesoell]

Von Synology

Hi all, we will fix this issue in next Docker package update. The workaround is to apply environment value in Docker UI.

Liest sich, als ob Synology sich Zeit nimmt.
Nun ja, nach einem fix zu erledigen Downgrade, funktioniert alles wie gehabt.

 

[hakiri]

Ich habe ein DDSM aktuell laufen. Wenn ich das Docker Paket aktualisiere, funktioniert das noch (bis Ende des Jahres)?
Auf meiner 2. Syno hatte ich DDSM nie genutzt. Nach dem Update war der gesamte Punkt DDSM verschwunden. Daher zögere ich etwas mit dem update.

 

[geimist]

Ich hatte bereits DDSM installiert und das bleibt auch mit der aktuellen Version erhalten. Lediglich die Reihenfolge im Seitenmenü ist umgestellt worden.

 

[haydibe]

Ich habe die Chance bekommen mit einer DS918+ rumzuspielen: dort funktioniert das ingress mesh routing ohne Probleme. Najo, auf einem einzelnen Knoten bringt es natürlich nicht wirklich viel, da es einen Port auf allen Nodes in einem Swarm bindet und eigenständig den Weg zum Ziel-Service findet.

docker service create --replicas 3 --name overlay-test --publish published=8080,target=8080 ehazlett/docker-demo

Danach kann man im Browser schön über https://{dsm-hostname}:8080 die Verteilung der Requests auf die 3 Replikas sehen.

 

[haydibe]

Es gibt jetzt einen Fix für das Problem mit Docker-Compose und den Environment-Variablen: https://usdl.synology.com/download/Package/spk/Docker/18.09.0-0506/
Swarm Deployments mit `docker stack deploy` haben nach wie vor das Problem, dass die Environment-Variablen "gefressen" werden. Ist wohl mal wieder mit der heissen Nadel gestrickt.