Docker Version veraltet nur 20.10.3 statt 23.0.3 Virtual linux server? Oder von Hand Docker aktualisieren

[freddey]

Hallo liebe Synology Begeisterte,

ich nutze schon seit längerem Docker. Leider kommt es immer wieder zu Unstimmigkeiten. So kann ein Container manchmal auf Ordner zugreifen obwohl GID und PIG stimmen und mit Portainer läuft es auch nicht wirklich rund. Manchmal geht es Variablen festzulegen manchmal nicht. Bei meiner Suche im Netz stellte ich fest, dass die Docker Version die das Synology System benutzt hoffnunglos veraltet ist. Da ich sowieso einen Yunohost (Debian 11 64bit) als virtuelle Machine laufen habe, habe ich nun dort mal Docker installiert und siehe da. Es installierte sich die aktuelle Version und auch Portainer läuft.
1. Warum mach Synology kein Update für die Docker App? Was hängt da dran?
2. Ist es eine gute Idee Docker auf einem virtuellen Linux laufen zu haben?
3. Kann man Docker auch durch hinzufügen der repos auf Synology auf eine andere Version bringen?
4. Gibt es Vorteile der alten Version weswegen Synology die nutzt?

Würde mich freuen, wenn wir hier was zusammentragen dazu.
Gruß Fred
DS 918+

 

[plang.pl]

Dass Synology veraltete Pakete nutzt, ist leider bekannt. Da wirst du nix machen können. Ich bin mittlerweile auch davon weg, alles auf der DS zu betreiben, sondern verwende stattdessen Linux-VMs auf 2 Proxmox Hosts.
Klar kannst du Docker auch in einer schlanken Linux VM auf der DS laufen lassen. Dann hast du den Vorteil, die verbastelte Docker-Version von Synology loszuwerden.

 

[Monacum]

Das wird sich Stand heute auch leider mit dem nächsten Update auf DSM 7.2 nicht ändern…

 

[haydibe]

1. Warum mach Synology kein Update für die Docker App? Was hängt da dran?

Weil Synology laut eigener Aussage nicht der Entwickler ist, sondern Docker... Das stimmt sogar bis zu dem Zeitpunkt, an dem Synology die Docker Sourcen geforked und verändert hat. Docker selbst hat nichts von dem in seinem Code: Syno-UI, DDSM Support, Verbiegungen an Docker die notwendig sind, um mit anderen von Syno verbogenen Libraries zusammenzuarbeiten. Der Swarm mode ist seit Tag1 bei Synology kaputt.

Deswegen kann man nicht einfach den Docker Binary-Release nehmen und die bestehenden damit problemlos austauschen. Es gibt Leute, die das durchaus tun, aber dann mit dem experimentellen und schnarch langsamen vfs StorageDriver leben.

2. Ist es eine gute Idee Docker auf einem virtuellen Linux laufen zu haben?

Absolut!

3. Kann man Docker auch durch hinzufügen der repos auf Synology auf eine andere Version bringen?

Leider nicht.

4. Gibt es Vorteile der alten Version weswegen Synology die nutzt?

Aus Sicht der Entwicklung: ja, in der Version sind alle Syno-Modifikationen eingebaut. Es spart erheblichen Entwicklungs- und Testaufwand hier nicht jeder Docker-CE Version hinterherzulaufen.

Aus funktionaler Sicht gibt es für den Endanwender, der nur fertige Images konsumiert, keinen Mehrwert neuere Versionen zu verwenden - das ist aber auch schon länger so.

Solange Synology alle Security-Fixes die Docker seitdem erfahren hat backported in ihre Version, sollte es keinen Unterschied machen. Allerdings bezweifle ich das Synology die Security-Fixes wirklich backported.....

 

[Ulfhednir]

Der Swarm mode ist seit Tag1 bei Synology kaputt

Hast du das zufälligerweise in letzter Zeit evaluiert? Bei mir sieht es gerade wie folgt aus:

 

[tAntChen]

2. Ist es eine gute Idee Docker auf einem virtuellen Linux laufen zu haben?

Absolut!

@haydibe nur so Interesse halber, wie ist das gemeint mit einem virtuellen Linux ? Ein Linux Container im Synology-Docker in dem dann eine aktuelle Version von Docker läuft? Oder ist da was anderes gemeint?

 

[Ulfhednir]

Da gibt es zwei Möglichkeiten: Docker-in-Docker oder eine schlanke Linux VM (Ubuntu Core) aufsetzen und Docker per Hand installieren. Letzteres habe ich auch schon auf der DS praktiziert. Bin mal gespannt, was haydibe hierfür präferiert.

 

[haydibe]

Hast du das zufälligerweise in letzter Zeit evaluiert? Bei mir sieht es gerade wie folgt aus:

- Swarm Mode Imitieren geht.
- Deployment von Swarm Services geht auch.
- Bei den Swarm Tasks (aka das was am Ende den Conatiner startet) fehlen die Environment-Variablen, obwohl sie an der Service Definition vorhanden sind
- Afair hatt der Zugriff auf gepublishte Port auch nicht funktioniert.

Wobei ich es noch nicht mit der 20.10.23 probiert habe. Hier im Forum habe ich irgendwo die Befehle mit denen ich das immer teste

 

[haydibe]

@haydibe nur so Interesse halber, wie ist das gemeint mit einem virtuellen Linux ? Ein Linux Container im Synology-Docker in dem dann eine aktuelle Version von Docker läuft? Oder ist da was anderes gemeint?

Nach meinem Verständnis eine VM.

 

[haydibe]

Da gibt es zwei Möglichkeiten: Docker-in-Docker oder eine schlanke Linux VM (Ubuntu Core) aufsetzen und Docker per Hand installieren. Letzteres habe ich auch schon auf der DS praktiziert. Bin mal gespannt, was haydibe hierfür präferiert.

Die VM Docker-in-Docker kann nerven, wenn im inneren Docker kein performanter Storage-Driver herangezogen wird, Wenn DinD, dann tatsächlich lieber mit macvlan, da man sonst beim Port publishen zweistufig publishen müsste: einmal am DinD und dann am Ziel-Container.

Ich würde keine DinD einsetzen, auf der Syno läuft das Docker, was Synology mitbringen, alle anderen Container laufen bei mir in Ubuntu VMs auf Proxmox.

 

[tAntChen]

Danke für die Aufklärung @haydibe
bislang bin ich für meine privaten Zwecke noch mit dem Syno-Docker hingekommen, aber soviel Kram hab ich auch nicht. Es scheinen aber wohl auch viele Leute Syno-DS als produktives Firmen-System ein zu setzten. Da würde ich mich wahrscheinlich eher für nen Root-Server oder eine AWS-EC2 Büchse entscheiden. Da hat man zwar den ganzen Syno-Klicki-Bunti Zucker nicht mit dabei jedoch viel mehr Kontrolle über das System.
Ich hab eh immer so den Eindruck dass Synology den SSH Zugang nur zähneknirschend eingebaut hat. Und nach all den Jahren haben die es noch nichtmal geschafft einen Paketmanager bereit zu stellen, soll ja auch Software geben, die gar keine UI braucht - hab ich gehört.

 

[haydibe]

Hast du das zufälligerweise in letzter Zeit evaluiert? Bei mir sieht es gerade wie folgt aus:

Nu aber: die Variablen werden nach wie vor nicht bis zum Container durchgereicht -> immer noch kaputt!

# docker swarm init --advertise-addr 192.168.x.y
Swarm initialized: current node (r4einj2b89zsq7o6za92p0le2) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-TOKEN 192.168.x.y:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

# docker service create \
  --name overlay-test \
  --replicas 3 \
  --publish published=8080,target=8080 \
  --env "TITLE=SYNOTEST" \
  dockersuccess/docker-demo

image dockersuccess/docker-demo:latest could not be accessed on a registry to record
its digest. Each node will access dockersuccess/docker-demo:latest independently,
possibly leading to different nodes running different
versions of the image.

fkv6rte0zz1tm2us7rmwfekoo
overall progress: 3 out of 3 tasks
1/3: running   [==================================================>]
2/3: running   [==================================================>]
3/3: running   [==================================================>]
verify: Service converged

## Environment Variable vom Service: OK
# docker service inspect overlay-test --format '{{.Spec.TaskTemplate.ContainerSpec.Env}}'

[TITLE=SYNOTEST]

## Default Environment-Variable vom Image: OK
# docker image inspect dockersuccess/docker-demo:latest --format '{{.ContainerConfig.Env}}'

[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]

## Environment Variable im Container: Nicht okay, es sind nur die vom Image geerbten zu sehen, die vom Service definierten fehlen
# docker container inspect $(docker ps --filter name=overlay-test.1 -q) --format '{{.Config.Env}}'

[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]

Der gepublishte Port ist übrigens erreichbar - die Replicas funktionieren auch. Nur taugt es ohne Variablen herzlich wenig.

Hier nochmal die Environments, wie sie eigentlich am Container aussehen müssten:

## Environment Variable im Container: OK, im Service deklarierte Variable und Default Variable vom Image sind vorhanden
me@swarm1:~$ docker container inspect $(docker ps --filter name=overlay-test.2 -q) --format '{{json .Config.Env}}' |jq
[
  "TITLE=SYNOTEST",
  "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
]

 

[Ulfhednir]

@haydibe scheint bei mir das gleiche Spielchen zu sein. Dann kann ich mir die Mühen auch erstmal sparen, schade eigentlich.

 

[haydibe]

Jepp, ist so. Das ist schon seit dem es den Swarm Mode in Docker gibt (seit 17.05) kaputt bei Syno.
Während es natürlich mit Vanila Docker von Anfang an funktioniert hat.

 

[Ulfhednir]

Im englischsprachigen Forum hat ein Jemand in der Vergangenheit die Docker-Engine manuell ausgetauscht und damit einige "Fehler" behoben.
https://community.synology.com/enu/forum/1/post/131600 und an anderer Stelle findet man ein Skript: https://github.com/markdumay/synology-docker

Insbesondere letzteres sieht spannend aus, insofern das mit dem "neuen" ContainerManager gangbar gemacht wird.
Bleibt für mich erstmal nur der Einwurf als Bug-Report bei Synology.

 

[haydibe]

Würde ich nicht empfehlen. Syno hat auch btrfs verbogen, sodass dann nur vfs benutzt werden kann.. Das will man nicht...

 

[Ulfhednir]

Ich habe es trotzdem gemacht und hier insbesondere auf dein Feedback verwiesen.
Vom Support/Entwicklung kam nicht wirklich sinniges zurück:

Vielen Dank für Ihre Antwort.

Nach Rücksprache mit den Entwicklern muss ich Ihnen leider mitteilen, dass DSM nur Docker-Pakete und Docker-Swarm-Funktionen unterstützt. Was die Konfiguration und Fehlerbehebung von Docker-Swarm angeht, lesen Sie bitte in der offiziellen Docker-Dokumentation nach oder suchen Sie online nach Lösungen, um die Probleme zu beheben. Dieser Aspekt fällt nicht in den Bereich unseres Supports. Wir danken Ihnen für Ihr Verständnis.

Wir hoffen, dass dies hilft, und lassen Sie uns bitte wissen, wenn Sie weitere Unterstützung benötigen.

Ich glaube, dass die das Kernproblem überhaupt nicht erfasst haben.

 

[haydibe]

Ich glaube, dass die das Kernproblem überhaupt nicht erfasst haben.

Kann ich nur zustimmen

Swarm nützt herzlich wenig, wenn der Service keine Environments an die von den Service Tasks erzeugten Container durchreichen.... Wer will schon für jede Konfigurationsänderung ein Image bauen müssen?!

 

[Ulfhednir]

Ich hatte die Tage jetzt nochmals mein Veto eingelegt und dabei einige Hinweise von anderen Foren beigefügt.

Dear Arno Nym,

Vielen Dank, dass Sie sich mit uns in Verbindung setzen und uns diese Informationen zur Verfügung stellen. Wir schätzen Ihren Beitrag und möchten Ihnen versichern, dass wir jedes Problem ernst nehmen.
Wir haben dies mit unserem Entwicklungsteam und unserem Manager besprochen, und sie haben das gleiche Problem mit dem Container Manager-Paket festgestellt. Wir arbeiten an einer Lösung für dieses Problem und bitten Sie um Geduld, da es einige Zeit dauern kann, bis es behoben ist.
In der Zwischenzeit empfehlen wir Ihnen, einen der folgenden Workarounds zu versuchen:
Packen Sie die env selbst in das Image
Verwenden Sie eine andere Lösung als die von Ihnen angegebenen Links.
Wir entschuldigen uns für etwaige Unannehmlichkeiten, die dadurch entstanden sind. Wenn Sie weitere Fragen oder Bedenken haben, zögern Sie bitte nicht, uns diese mitzuteilen.

 

[Ulfhednir]

https://github.com/markdumay/synology-docker

Insbesondere letzteres sieht spannend aus, insofern das mit dem "neuen" ContainerManager gangbar gemacht wird.
Bleibt für mich erstmal nur der Einwurf als Bug-Report bei Synology.

Ganz spannende Sache! Das Skript funktioniert auch mit DSM 7.2. In den Issues ist die Lösung beschrieben - es ist lediglich die Bezeichnung an zwei Stellen auf die neue Bezeichnung des ContainerManager umgestellt werden. Damit war es mir nun möglich auf die aktuelle Docker-Engine zu aktualisieren und auch die ENV durchzureichen.

Ich habe das Ganze jetzt "nur" versuchsweise in einer vDSM-Instanz durchprobiert.