Docker/DSM 7 und Environment Variables

[necarter]

Hallo Forum,
ich bin nach dem Upgrade auf DSM 7 auf ein etwas seltsames Problem gestoßen. Zunächst aber etwas Hintergrund:
Auf meiner DS218+ läuft Docker mit etlichen Containern im Swarm-Modus. Gestern habe ich das Upgrade auf DSM 7 gewagt (was unspektakulär ablief ...), damit geht auch ein Upgrade von Docker auf die Version 20.10.3 einher. Vorher alle Stacks gestoppt und nach dem upgrade alles nach und nach wieder gestartet. Leider liefen nach dem Upgrade eine Handvoll Container nicht mehr, zum Teil mit seltsamen Fehlermeldungen im Log. Andere Container funktionierten klaglos ...

Nach einigem Nachforschungen folgendes Ergebnis: überraschenderweise funktionieren nur genau die Container nicht mehr, die über Environment-Variablen konfiguriert werden! Die Variablen werden einfach ignoriert.

Normalerweise administriere ich die Container über Portainer, die Variablen wandern ins compose-file. Aber egal ob man etwas in den Abschnitt 'environment' schreibt oder ein File über 'env_file' einbindet - sie werden ignoriert. Auch wenn man Portainer beiseite läßt und das über Kommandozeile per docker stack deploy macht - immer das gleiche Ergebnis. Enviroment-Variablen lassen sich definieren und werden von den Containern dann ignoriert.

Hat jemand etwas ähnliches beobachtet und weiß vielleicht Abhilfe?

P.S.: den einzigen Workaround, den ich kurzfristig gefunden habe: ein eigenes Image bauen in die die Variablen schon 'eingebrannt' werden. Damit kriege ich die betroffenen Services zumindest wieder zum Laufen, aber schöne Lösung ist das aber natürlich nicht.

 

[haydibe]

Nach einigem Nachforschungen folgendes Ergebnis: überraschenderweise funktionieren nur genau die Container nicht mehr, die über Environment-Variablen konfiguriert werden! Die Variablen werden einfach ignoriert.

Ist schon seit DSM6 und der Version mit Docker-CE 17.05 unter der Haube so gewesen und war noch nie anders bei mir - ich hab es nach jedem Update des Docker Packages getestet und die Environment-Variablen haben bei Container, die aus Swarm Services erzeugten werden, immer gefehlt.

Dein Workaround ist der einzige Weg wie man Swarm Services "sinnvoll" (?!) betreiben kann. Ich bin überzeugt davon, dass Synology das bewusst kaputt gemacht hat, da sie seit etlichen Versionen keine Bemühungen zeigen den Fehler zu korrigieren.

Die einzig saubere Lösung wäre in VMM eine Debian oder Ubuntu VM aufzusetzen und dort eine unverändertes Release-Paket von Docker Inc. zu verwenden. Das Docker Paket von Synology bringt eine von Synology modifizierte Re-Distribution von Docker-CE mit.

 

[necarter]

Danke für Deine Antwort. Ich kann mir leider keinen Grund vorstellen, warum die das künstlich einschränken sollten, da es den Einsatz vieler Images unmöglich macht. Aber das bekommen wir nicht heraus.

Ich habe übrigens noch eine DS415+ im Einsatz, da laufen aber nur drei Container drauf. Da scheint es aber zu funktionieren? Ich fürchte, ich fürchte ich muß noch Zeit investieren, um herauszufinden, was der genaue Unterschied zwischen beiden Geräten ist. DSM und Docker-Versionen sind in jeden Fall gleich (7/20.10.3).

 

[THDev]

Naja weil docker swarm nicht unbedingt offiziell von synology unterstützt wird...

 

[haydibe]

..., da es den Einsatz vieler Images unmöglich macht.

zwischen "Images" und "unmöglich" fehlt "unter Docker Swarm". Bei Swarm gewinnst Du zwar einen Multi-Node Orchestrator und kannst configs und secrets verwenden, verlierst aber die ganzen Low-Level features wie --privileged und --umask. Aber erklär mal den Anwendern, warum n tote Task-Container mit vorherigen Versionen des Deployments in der Oberfläche zu finden sind... ich sehe den Ottonormal Synology Benutzer gleich aufschreien, obwohl die Task-History eine Standard Funktion von Swarm-Services ist.

Da alle Images unter docker-compose funktionieren, wird man sich damit wohl begnügen bei Synology.

Ich verstehe eh nicht, warum Synology nicht anfängt eine vanilla Docker-CE Version in die Pakete zu packen. Die Mods, die für DDSM Notwendig waren, sind es doch nicht mehr. Entgegen meiner Wahrnehmung, dass bestehende Container nur bei Synology nachträglich verändert werden können, hab ich gerade gelernt, dass man das auch mit einer vanilla Docker-CE Version hinbekommt. Es gibt keinen Grund mehr für diese verbastelte Docker-CE Redistribution... trotzdem haben wir sie noch (sigh)

 

[THDev]

Dann hast du für deinen advanced stuff einfach das falsche Produkt. Synology ist NICHT für enthusiasts gedacht. hol dir nen pi oder ähnliches dafür. du bist dafür die falsche zielgruppe.

 

[haydibe]

... ehrlich gesagt würde ich Synology's Docker auch niemals in einen Swarm Cluster mit vanilla Docker-Nodes packen. Selbst wenn ein vanilla Docker in "derselben" Version auf den anderen Nodes läuft, so ist es trotzdem nicht wirklich dieselbe Version - es ist schwer hervorzusagen was alles durch die Verbiegungen von Synology betroffen ist und ein abweichendes Verhalten zeigt.

Ein Single-Node Swarm Cluster würde ich mir persönlich verkneifen, da er aus meiner Sicht eher Nachteile als Vorteile hat.

Wenn man ernsthaft Multi-Node Container-Orchestrierung machen will, führt im Endeffekt kein Weg an Kubernetes vorbei... Das Einzige wofür die Syno in dem Kontext sinnvoll eingesetzt werden könnte ist als Backend für PersistentVolumes.

 

[MasterAl]

Hi

Bei meinerDS918+ mit installierten Docker vom Paket Zentrum (20.10.3-0554) habe ich das exakt gleiche Problem mit den Variablen wenn ich über Portainer mit einem docker-compose File arbeite. (Workaround: Variablen in file direkt).

@haydibe @THDev : Ihr schreibt, dass das Problem nur bei Docker Swarm auftritt, allerdings ist das Problem bei mir auch ohne Docker Swarm. Übersehe ich hier etwas, würde man es ohne Docker Swarm auf der DS918+ mit Variablen zum laufen kriegen?

Grüße

 

[haydibe]

Mit docker-compose sollte es funktionieren, mit docker stack deploy -c (=swarm stack deployment) hat es auf der Syno noch nie funktioniert - das verhalten ist auf DSM6.2.x und DSM7 leider gleich.

Teil mal exemplarisch den Inhalt von einer eine Deiner compose files, dann kann man mal schauen.

 

[MasterAl]

Hi,

Ich nutze das docker compose File der Owncloud Installation via Portainer.

https://doc.owncloud.com/server/next/admin_manual/installation/docker/#docker-compose-yaml-file

Wie gesagt, meines Wissens ist das kein Stack deployment.

Einziger Workaround. Variablen hardcodieren.

Grüße

 

[haydibe]

Wie gesagt, meines Wissens ist das kein Stack deployment.

Das ist wahr, wenn auf der Docker Engine der Swarm Mode nicht aktiviert wurde...

Normaler Modus: Stack = "docker-compose" deployment
Swarm Modus: Stack = "docker stack deploy" deployment

Was sagt den docker info | grep Swarm?

 

[MasterAl]

ash-4.3# docker info | grep Swarm
Swarm: inactive

...wie vermutet

 

[haydibe]

Dann ist es eindeutig ein docker-compose deployment... tja, damit ist die einzige sinnvolle Erklärung vom Tisch.