Description
Scenario: I'm injecting some environment specific configuration that extends whatever is already packed into the container. These are various conf.d folders provided by various software (supervisord, php, nginx) and which already contain some files in the included conf.d folder to begin with. I want to provide these files before running CMD/ENTRYPOINT commands.
Problem: The obvious issue by using a volume mount on a folder is that the complete folder contents are replaced by whatever is provided from the volume. The running container is missing the defaults provided, before the volume is mounted.
Workaround 1: Currently, the only way I can move forward is to mount individual config files to their respective conf.d locations. It's not comfortable to do this, because I basically have to generate the complete docker run command.
Workaround 2: Another way to get the files into the running container is with docker cp, but there's a race condition between copying the file, and executing whatever is in cmd/entrypoint.
Suggestion (for docker run): add some kind of switch flag like `-V [source]:[destination] which would copy the files into the filesystem set up for the container, before running CMD/ENTRYPOINT.
Suggestion (for service create): There's already a --mount option, which might have already everything available to do this, but docs are scarce. There's a type=bind/volume/gluster which I asume is the name of the volume driver. Is it possible to create a "copy" volume driver, which would be close to what COPY/ADD inside the Dockerfile do?
What I would like is ideally the following:
Swarm: docker service create --mount type=copy,source=[source],target=[destination]
Docker: docker run -V [source]:[destination] image
Both should be equivalent to running something like this Dockerfile:
FROM image
COPY [source] [destination]
Except that the resulting image wouldn't be commited & used for docker run/service.
Is it possible to create something like this with a custom storage driver? I'll gladly review some docs for it if it's possible and evaluate if it's feasible to develop this on my side, because I'm not sure how high on your priority list this feature request would land.