Open Bman7714 opened 1 month ago
This demonstrates lack of native support for secrets in docker engine (when swarm mode is disabled) which require users to be creative :)
Reminds me an earlier discussion we had regarding secrets extensibility (cc @hyu). The topic was basically "how to let compose retrieve secrets from an external service like Vault". What you implemented here is basically a hand-made secret provider. Would be nice you can fully delegate secret management to some custom component so you get my_secret
eventually bound to a path on docker host.
Regarding this proposal, using such a from_docker_host
would require we disable relative path resolution on file
(which takes place client side and would not make sense). Such cross-attribute logic would be a pain to implement. IMHO if we want to explicitly cover this usage, we would better add support for a dedicated host_path
(actual name to be debated) attribute, that would be exclusive vs file
and environment
, and would be documented to disable support for uid
, gid and
mode`. Such an attribute would not be considered relative to project directory, and passed as-is to docker engine.
This is a good feature that lends itself to a GitOps approach to remote Docker Compose deployments. However I think this should be a toggle, especially with secrets.
For example, in my workflow I have various
docker-compose.yml
s each in different directories, with each directory corresponding to a remote server. As a very basic example:This is all Git tracked as a single source of truth to track server state and changes to deployments over time. By being able to use configs from my localhost, we can also track Docker config changes in Git. However, it doesn't make sense to track secrets in the Git repository, as they are meant to be secret - it would be more ideal for my workflow to bind/copy secrets from DOCKER_HOST.
I think an attribute such as
from_docker_host
would be useful, so you can explicitly choose where the config/secret files will be found when using Docker contexts, and it is flexible around different workflows people may use:Originally posted by @LawrenceWarren in https://github.com/docker/compose/issues/11867#issuecomment-2147007301