I've set up a small Docker Swarm environment where I use secrets to pass sensitive information to my containers. I'm struggling with the management of these secrets, especially when it comes to updating them while the services are still running. Currently, I can't modify a secret that's being used until the service is redeployed, which means creating a new secret with a different name, changing the YAML configuration, and then redeploying the service. This process is tedious, as I prefer to keep my configuration static in a Git repository.
Additionally, I have to define the secrets in two places in the YAML configuration: once at the container level and again under the secrets section. The names have to match, making it more complicated. While at the container level, I can use environment variables like ${VAR}, I can't do the same in the secrets section. To work around this, I'm currently using an environment variable at the container level while maintaining a second YAML file outside of my Git repo. My deployment script creates the secret, updates the YAML, sets the environment variable, and redeploys the stack. Does anyone have better strategies to simplify this process?
2 Answers
You can actually define both the secret and its config in the same YAML file, which might simplify things for you. For example:
```yaml
services:
some-service:
secrets:
- source: secret-name
target: should/go/here.txt
...
secrets:
secret-name:
file: some-file.txt
name: secret-name-${THIS_SECRET_HASH}
```
Using that, you can refer to the secret by its `secret-name`. I also have a script that generates the `THIS_SECRET_HASH` based on the content of the secret, and then it’s used in the Docker stack command. This way, if the secret changes, it’s renamed and updated automatically. But yeah, it’s frustrating that Docker has made it this convoluted.
I use a similar tool for managing my Docker Swarm deployments that handles those hash values efficiently. It's a big time-saver! Check it out: https://github.com/UnclePhil/dkdtpl
Honestly, this feels more like an oversight on the client side. It would be ideal if the client could simply create or update the secret seamlessly. If the content changes, it could automatically initiate an update instead of redirecting you to create a new one. That way, it would function more like other configuration options.
Thanks for the tip! I wasn’t aware of the 'name:' tag under secrets. That could be the perfect solution for me!