Thanks for sharing, Telos!
Seems like Synology sneaked the update in on 12th March 2020 without someone realy noticed it...
I took 15 minutes to make my personal regression tests.
Finaly, the client and server version are in sync (we already hat the 18.09.8 client, but a 18.09.6 server):
root@dsm:~# docker version
Client:
Version: 18.09.8
API version: 1.39
Go version: go1.11
Git commit: bfed4f5
Built: Fri Mar 13 06:46:11 2020
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 18.09.8
API version: 1.39 (minimum version 1.12)
Go version: go1.11
Git commit: 3a371f3
Built: Fri Mar 13 06:44:35 2020
OS/Arch: linux/amd64
Experimental: false
I used this docker-compose.yml to test wether the bug, where the environment variables are removed during deployment, returned for docker-compose and still exists for docker swarm stack deployments:
Code:
root@dsm:~# cat env-test.yml
version: '3.7'
services:
ubuntu:
image: ubuntu:18.04
environment:
TEST: test
command: ["tail","-f","/dev/null"]
Docker Compose works as expected, no signs of regression (unchanged):
root@dsm:~# docker-compose --project-name demo -f env-test.yml up -d
root@dsm:~# docker exec demo_ubuntu_1 env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=fd57870a8364
TEST=test
HOME=/root
root@dsm:~# docker-compose --project-name demo -f env-test.yml down
Stopping demo_ubuntu_1 ... done
Removing demo_ubuntu_1 ... done
Removing network demo_default
Docker Swarm Stacks still suffer from removed environment variables (unchanged):
root@dsm:~# docker stack deploy -c env-test.yml demo
root@dsm:~# docker exec $(docker ps -q --filter name=demo_ubuntu) env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=5e92cc53e34c
HOME=/root
root@dsm1:~# docker stack remove demo
Removing service demo_ubuntu
Removing network demo_default
Same with docker services:
root@dsm:~# docker service create --name demo_ubuntu --env TEST=test ubuntu:18.04 tail -f /dev/null
image ubuntu:18.04 could not be accessed on a registry to record
its digest. Each node will access ubuntu:18.04 independently,
possibly leading to different nodes running different
versions of the image.
ljmv2cbpvdcq7tt23r7bz40r0
overall progress: 1 out of 1 tasks
1/1: running [==================================================>]
verify: Service converged
root@dsm:~# docker exec $(docker ps -q --filter name=demo_ubuntu) env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=0db8a2f5fcd8
HOME=/root
root@dsm:~# docker service rm demo_ubuntu
demo_ubuntu
sidenotes:
-
env
is used to print the environment variables from inside the container.
- with docker-compose the argument
--project-name
is used to get a stable container name, regardless where the compose.yml file is stored (as fallback the foldername is used instead)
- with docker services deployment (stack deployments deploys those as well) , the containername is unpredictable, thus the image name is searched with a subcommand.
Conclusion: Seems like Synology does not realy care about fixing deployments of swarm services/stacks.