Questionable design

Docker Engine Swarm
, ,
1

Why are configs and secrets static? Is it hard to do with current architecture? Is it a design choice? I see no good reason for not having dynamic secrets and configs. Am I just missing something?

2

The resource itself will always be static.

Though, the creation can be dynamic:
Since docker 18.06 (and 19.03 for compose) secrets and configs support --template-driver to render the the configuration.

I found a post of mine where I did some research about it:

Update: after re-reading the moby issue description, it seems secrets can dynamically reference other resources as well - I am not sure anymore, if the rendered output is stored in the resource, or the placeholders are stored in the resource.

3

I just tested it: secrets and configs using the template_driver can be dynamic.

Here is a test stack that uses the golang template driver to render configs and secrets dynamically:

services:
  container:
    image: alpine
    command: sh -c "cat /tmp/file* && sleep infinit"
    secrets:
      - source: file_secret
        target: /tmp/file_secret
        uid: "1000"
        gid: "1000"
        mode: 0440
    configs:
      - source: file_config
        target: /tmp/file_config
        uid: "1000"
        gid: "1000"
secrets:
  file_secret:
    file: ./file_secret.txt
    template_driver: golang
configs:
  file_config:
    file: ./file_config.txt
    template_driver: golang

Create a config and secret using template placeholders:

echo "this is a config: {{.Service.Name}}" > file_config.txt
echo "this is a secret: {{.Service.Name}}" > file_secret.txt

Then deploy the stack, inspect the config and cat both files:

[root@swarm template-driver]# docker stack deploy -c compose.yml test
Since --detach=false was not specified, tasks will be created in the background.
In a future release, --detach=false will become the default.
Creating network test_default
Creating secret test_file_secret
Creating config test_file_config
Creating service test_container
[root@swarm template-driver]# docker service logs test_container
test_container.1.rg5jn0j69ikk@swarm| this is a config: test_container
test_container.1.rg5jn0j69ikk@swarm| this is a secret: test_container
[root@swarm template-driver]# docker config inspect test_file_config
[
    {
        "ID": "wohb85yxsyehb03uv636b5ns3",
        "Version": {
            "Index": 3066
        },
        "CreatedAt": "2025-12-16T22:43:29.411799107Z",
        "UpdatedAt": "2025-12-16T22:43:29.411799107Z",
        "Spec": {
            "Name": "test_file_config",
            "Labels": {
                "com.docker.stack.namespace": "test"
            },
            "Data": "dGhpcyBpcyBhIGNvbmZpZzoge3suU2VydmljZS5OYW1lfX0K",
            "Templating": {
                "Name": "golang"
            }
        }
    }
]
[root@swarm template-driver]# docker stack rm test
Removing service test_container
Removing secret test_file_secret
Removing config test_file_config
Removing network test_default

The content of the config’s inspect Spec.Data is base64 encoded. When decoded it shows the content of the file file_config.txt.

1 Like
4

Thanks. To clarify I meant option to edit configs & secrets. Important part is without restarting container. This would be nice with for example proxies. I wanted to ask where I could ask for config & secret update to be a thing in docker. Sorry for my English.

5

What you describe sounds like how Kubernetes handles secrets and configMaps. Note: it’s worth nothing if the applications only reads the configMap or secret during deployment, or during runtime in the entrypoint script, or during start of the main process, without re-reading it again after it’s modified.

Though, unfortunately it doesn’t work like that with Swarm secrets and configs. They are indeed immutable after the creation, and will not be “updated” unless the external resource name or the compose internal handle is changed. Updated is in quotes becomes it doesn’t really update, it creates a new immutable resource.

The closest you can get is described in this blog post: Docker stack deploy: update configs and secrets - Sune Keller’s blog. The idea is to use individual different external resource names, but keep static internal handles for the secrets and configs. This at least reduces the changes that need to be done in the compose file. I think it will still not hot-replace the files, but rather replaces the running task with a new task based on the changed configuration,

If you want to open a feature request, this is the repo to do so: GitHub · Where software is built

1 Like
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.