Support for switch configs/secrets on-the-fly

[gviczai]

Currently "docker service update" commands related to configs/secrets automatically restart service instances in a swarm. (Checked with 19.05.3 build 633a0ea838)
There are plenty of tools on the market which are able to detect an underneath configuration file change and re-configure themselves with the new data without the need of restart. Running these services as a swarm service looses this benefit. (Assuming one uses config/secret feature of swarm services instead of regular container mounts.)
Since there exisis a --force option which could be used to indicate the need of a restart, I think
--config-add
--config-rm
--secret-add
--secret-rm
options should not re-schedule tasks by default.

[gviczai]

Not strictly, but also related: "Updating --restart-condition restarts service" docker-archive/classicswarm#2848 (I don't know whether the issue mentioned there fixed already or not, I just found it while googling, haven't checked the story behind it...)

[thaJeztah]

I'm not sure this would work; updating "on the fly" would mean unmounting the config/secret in the running containers, and mounting the new secret/config in the same (or possibly different) place.

Processes inside the container could have these files open (potentially causing the unmount to fail) or processes may only read configs/secrets when starting the container (thus updating the config/secret having no effect).

For reasons above, updating these options will replace existing containers with a new one

[gviczai]

This sounds reasonable, thank you!
I have tested "--bind" mounts/re-mounts and what I found is that the application does not react to the (re)mount but it detects the originally mounted file change even when the other one is mounted. It was funny, because when I changed the un-mounted file, the application immediately reloaded - the mounted one. :) Seems like that the Linux file-change detection hook is connected to the i-node of the mounted file, not the mount point.
So, I see now that my original idea was wrong, re-mounts without process restart would be meaningless and even dangerous...

However, I think my original concept is still valid: there should be some support to change configs/secrets contents in a running container to let applications re-load changed config files on-the-fly if they are designed to do so in the first place...
Maybe the configs/secrets shouldn't be immutable?
For example a "docker config update ..." or "docker config replace ..." command could be introduced, which would replace and re-distribute the contents of one registered config/secret...