Repository navigation
Support for named single-file volumes #30310
Description
Single-file Docker volumes are great to replace / insert configuration files.
But the current implementation has some major limitations:
- you cannot replace the container without the file at place. (this makes the container dependant on the structure of the host fs).
- two containers cannot share the same file.
- a single-file volume is not listed as a volume.
Use cases for single-file volumes cannot be transformed into use cases with folder-based volumes without forcing the application to restructure their file system.
Reacted by Spence, hashlash, Rudá Almeida, Mohammed Noureldin, Double-A-92, Ntokozo and Michael Brown
Activity
justincormack commentedon Jan 20, 2017
Single file mounts are a feature that only exists on Linux, and are not available on other Unix platforms or on Windows, so I am not sure if adding this is a generic feature is a good idea.
Can you not use symlinks to have the same effect for configuration files? Build the container with a symlink pointing at
/config/.../config-fileand then mount a config volume in/config?JensPiegsa commentedon Jan 20, 2017
Ok, I was not aware of the plattform-specific limitations of this feature.
Working with symlinks like shown indeed solves the problem from the perspective of the image author.
From the user perspective this cannot be achieved for images that are not designed in this way. A lot of public Docker images therefore loose their flexibility in terms of advanced configuration. Apart from the comfort Docker provides, it just feels odd that switching one config file requires a whole new Docker image.
Illydth commentedon Aug 7, 2017
I'll leave a comment here:
MySQL (Or pretty much any DB)
NginX (Or pretty much any web front end)
Jenkins (And pretty much any other CI/CD Pipeline Application)
The list goes on and on and on of use cases where you need to be able to configure the application running within the docker container without creating 100's of copies of that same docker container.
In my Fortune 500 org we have about 100 Apache Containers running with slightly different config files for each customer (hard separation requirements by the customers require we don't run multiple customers in the same apache instance as Virtual Hosts).
I cannot move these to swarm / volume drivers to take advantage of orchestration / container failover without building a hundred or so one-off containers and then coding an entire stop/start infrastructure (that has to be modified each time a new customer onboards) for them.
This is one of the most simple/basic tasks with single server docker.
justincormack commentedon Aug 7, 2017
Illydth commentedon Oct 17, 2017
@justincormack Yea, so just to loop back around on this (apologies for the thread necro) Docker Config should (and in my case does) fix the use case for single file "volume" (bind) mounts.
Not sure how I missed that little feature but it does fix all the use cases in my prior message.
Thanks for the direction on this.
thaJeztah commentedon Oct 31, 2017
Yes, I think we should close this issue now that we have both configs and secrets for services. In addition, we added the
--mountoption fordocker run(already existed fordocker service create), which will produce an error if the source file/directory doesn't exist, instead of silently ignoring and creating a directory on the host.Closing this issue, but feel free to discuss.
masaeedu commentedon May 10, 2018
@thaJeztah Docker supports neither subpaths of folder-based named volumes (#32582), nor single-file named volumes (#30310), nor mounting of volumes from the filesystem where a docker client binary is invoked (out of the box anyway). As a result it's all but impossible to put a single local source file into an existing folder in a container running on a remote docker host. Since this issue is now closed, can fixing whichever of #32582 and #30310 is easiest to fix please be prioritized?
Using host volumes is not a solution because they basically reduce a shared docker host to SPOF filesystem-wise, defeating the point of containerization.
Regarding
docker configanddocker swarm: these only work for Swarm nodes, which not everyone is using. In many places test hosts are just ad-hoc docker-machines and production hosts are managed via kubernetes.replaysMike commentedon Apr 7, 2025
+1 for wishing this was a supported scenario today. To clarify, symlinks do not work for single files. If I symlink a source folder to a volume folder data persists between container updates. However, the symlinks to individual files are not persisted.