I was wondering how others would handle configurations in Docker swarm.
I am more used to just baking the configurations (minus some environment variable to do switches) or having a volume mount for something that is frequently updated (primarily in development)
I know docker-compose has a config capability but the config cannot be updated without shutting down the services first.
Also in swarm mode, docker stack deploy does not try to update the configuration and instead causes an error when you’re redeploying a stack with a configs section that is used.
I’ve had good results using docker swarm configs. Swarm does not allow modification or deletion of a config that is currently in use, but you can get around that by rotating configs, which is creating a new config, making services use that, and then removing the old config. An example of rotation is shown here:
Caveat: I manage configurations manually (via scripts), not as part of the stack. Precisely because I do not want to re-deploy the stack for a configuration change. When there is a major configuration change, for example to accommodate new functionality, then I redeploy the stack with a new configuration.
I know of this approach, I kind of wish the CLI or something did that for us in a nice way. I guess when you redpeloy the stack you set up new configuration files as well so there’s no overlap when you deploy.
Treat all your deployments as immutable, so when a config change is required deploy a new stack following whatever pattern makes sense for your environment and your tolerance for loss of service, e.g. rolling, blue-green, et al. It’s usually possible to achieve no outage so long as you are prepared to accept that there will be a period where two versions of the same app are available, if not you can handle that further up the stack (although you may have to deal with ttl)