Add `copy` to the yaml configuration

[riquito]

I want to deploy different services using the same image but with a different configuration file. Currently to achieve that I can

• build as many images that inherit from a common image plus a different COPY in each
• mount a single file volume

The first solution isn't feasible and the second it's overkill. I just want to copy a file, not keep it in sync

Proposed configuration:

myservice:
    image: foo/bar
    copy:
        - src:dest

[axklim]

+1

[burningalchemist]

+1 for reopening or different solution without volumes.

Currently using Environment variables in docker-compose.yml and j2 in docker-entrypoint.sh for parsing them to configuration files before running the main app of the container. Works for me, though it's a custom image and it can't be used out of the box with already available complete images.

[budzek]

+1

[patrickjm]

+1

[b0laj1]

+1

[mizanRahman]

+1

[oiwn]

+1

[kooliahmd]

+1

[nubitech]

+1

[storytime]

+1

[mmontossi]

+1

[jeroiraz]

+1 for reopening

To add the possibility to have a different yaml file for each container instead of a config based on environment variables

[ecoulon]

+1 very needed feature

[damianvalderrama-olx]

+1 , nice to have feature!

[andreymaznyak]

+1

[vlean]

+1

[jjortega]

+1

[konstan]

+1

[hieudang9]

+1 reopening. Bookmarked

[shatil]

+1 this is a much-needed feature.

If there was some way to mark a shared volume as a layer, so the volume remained RO but the writes applied to a layer atop, I'd live happily without a copy directive. I'd like to share, for example, an extracted build artifact, but the service writes to that directory (logs or PID file, etc.).

[christabone]

+1

[MichalKalita]

+1

[omani]

+1

[OlegVorobyov]

+1

[sergio-jara]

+1

[Julien00859]

+1

[kolyaflash]

+1

[ikrauchanka]

+1

[che]

+1

[ghost]

+1 For reopening as it would be a very useful feature

[Julien00859]

Maybe the template feature of https://github.com/jwilder/dockerize can help some of you

[BlueHotDog]

+1

[hubun]

+1

[sylvain261]

+1

[tindleaj]

+1

[vegasbrianc]

+1

[zmellal]

+1 to reopen the issue

[leshcat]

+1

[zmellal]

Use docker secrets, in this example secrets are used with nginx image to copy server certificat and the config file https://docs.docker.com/engine/swarm/secrets/#intermediate-example-use-secrets-with-a-nginx-service

[washtubs]

That's a good point. Honestly it seems that since we already have secrets, we should have copy, as secrets are, in a way, just a specific type of file that you would copy over. Namely, one which is more carefully provisioned, which we don't need for config files.

It beats host mounting a volume for every configuration file you want included.

[Oleffka]

As said before:

... volumes:

• ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
• ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro ...

[washtubs]

The reason copy is better, a) in swarm environments, where hosts are in fact separate machines, you should not have to have the exact same file in the same place on every machine. b) Copy can also be restricted to the folder compose is in, whereas a host mount requires an absolute path. c) I think the point of docker is to minimize the number of places that the contained application breaks into the host. Host mounts, even when configured as read-only, create a responsibility on the host to have and preserve files. We shouldn't have to use host mounts to solve this simple problem.

I think copying could be modeled similarly to the docker build process, where the Dockerfile is usually shipped in a git repository, along with all the files it needs to send to the build context. The Dockerfile isn't permitted to send anything that exists outside of it's directory structure, even if it's symlinked correctly. We could have a similar thing with compose, where src is restricted to the directory (and those below) of the docker-compose.yml. Basically, the workflow would be, docker-compose creates the container, and then for every src:dst pair, find the src under the current directory, and copy it into the unstarted container, then start the container.

Currently, avoiding host mounts can be achieved by adding additional Dockerfiles and building the conf files into amended images, but this seems like overkill to me, as it involves retagging a new image, or forcing users to use docker-compose build attribute instead of the more preferable (IMO) image attribute. If you're already using the build attribute in your service definition, and you want to do things this way, you are forced to pollute your otherwise agnostic image builder with a highly opinionated configuration file that should just belong to compose and the deployment process.

[paulwilton]

+1 for docker-compose copy feature

[and1990]

+1

[Xplouder]

+1

[kfrendrich]

+1

[rajeshkaushik]

+1 for copy.

[PMDubuc]

+1 for docker-compose copy feature. I think the arguments in favor above are compelling.

[ykalinov]

+1 for copy

[armadadean]

+1 for copy.

Although in my POV. It can become handy but it can also become out of control or abused for many users and can even make volume obsolete. If you just need files to be put onto the container especially for swarm then you can just use configs or secrets; But for my case like putting static folders in a nginx container, I have to use multi-stage builds in my Dockerfile to put those static folders in the container which takes a lot of process before my goal is achieved. So I think adding a copy option could be very useful