Moving a file from the host system to a container via docker cp

[jamtur01]

The docker cp command can currently copy a file from the container to the host. It should also be able to do the reverse.

Ping @crosbymichael

[hadim]

+1

[bruno-]

+1

[maci0]

+1

[LK4D4]

+1

[crosbymichael]

This there a reason why this cannot be accomplished with an ADD in the Dockerfile?

[thaJeztah]

@crosbymichael I think the difference here is that docker cp can be used on a running container. Since this command allows copying from a container to the host, allowing it to work in the other direction makes sense (and is something a user will expect)

Interactively adding/updating a file in a running container can be very convenient, other options (running sshd, volumes, FTP?) could work, but won't be appropriate in many cases.

[crosbymichael]

Do you have an example of some file you would copy into a running container?

[thaJeztah]

(Trying to provide a reasonable example here; at this moment I'm using docker for development-environments and use volumes to share files between the host and container)

I'm thinking of configuration-files that may change during the lifetime of a container; sometimes you don't want to shutdown or re-build a container to change that.

@crosbymichael Is it ok if I reverse the question? Are there any particular reasons to not implement copying to the container?

The point is, that at this moment there is (afaik) no way to 'enter' a container to make small changes (interactively) without installing a service for that (e.g. sshd). Docker 'enter' (nsenter?) isn't ready yet (or at least only considered for debugging).

[lorin]

@crosbymichael I was thinking about implementing an Ansible connection plugin for Docker. Currently, if you want to use Ansible to configure a Docker container, you need to run an ssh server insde the container or you need to install Ansible inside of the container itself. With a connection plugin, you wouldn't need to do either of these things.

To implement an Ansible connection plugin, you need to be able to:

• run an arbitrary command
• copy an arbitrary file into the container
• copy an arbitrary file out of the container

This feature is the missing element. I know this can be worked around using docker -v ... run cp ..., but having native support for copying files into containers would make the implementation cleaner.

[crosbymichael]

@thaJeztah The reason why i dont want to implement this is be cause ADD works well and can be reproduce to make image over a over. It's not one off command the modifies the container state.

[thaJeztah]

@crosbymichael I think I get the point; in some perspective, containers should be built once (preferably via a Dockerfile) and regarded an immutable, deployable 'package'. To make changes, the container should be rebuilt and committed.

While this is a reasonable assumption for production purposes (and for deployment), my use case is a bit different;

We use dockers to create development environment/sandboxes. Specifications of those environments are not always pre-defined and may need some tweaking / modifications. Having to stop/rebuild a container for each change (to make use of ADD) seems a bit silly. Installing a SSH server on each container feels like too much overhead (but is our current approach, combined with volumes for source files) and lxc-attach is no longer an option with the native driver.

Being able to use cp to interactively add files is not a "must-have", but I'm silently hoping that some features will be added to allow 'interactive' sessions with a container; i.e. Transferring data to/from the host and entering the container. (I think work was in progress to add a docker enter command as replacement for lxc-attach?)

I hope my information is useful!

[apatil]

@lorin +1 to the ansible plugin.

[divoxx]

+1

[schickling]

+1

[ahazem]

@lorin +1 for the ansible plugin as well.

[carltonbrown]

+1. Begging please for this. Sometimes I just need to add one tiny file to learn how to make a container work... almost REPL-like functionality if you think about it.

[jaloren]

+1

[jamshid]

without this feature, people resort to copying into /var/lib/docker/aufs/mnt/ directly (eg, http://stackoverflow.com/questions/22907231/copying-files-from-host-to-docker-container)

[timfayz]

+1 highly support

[coco98]

+1 Need to copy SSH keys temporarily to the container to clone a private repo.

[brunoric]

+1 on that.

[l3iggs]

+1, this is my number one feature request for docker

[docbill]

For example, I have a docker container that has taken the place of a server I use to run a reporting server. For the most part it works well. The pain in the neck though is each time users run they need to add configuration files. I have one container container for oracle-xe where I used a volume. This works well for oracle-xe I'm happy just setting up one folder and using with every container made from that image. However, it is not an adequate solution for my reporting tool server. For the reporting tool, I really don't want copying data onto one container to impact another container. So that means creating a new folder for every container, doing a chattr on that folder so SELinux allows it to be used as a volume, keeping track what folder is mapped to which container, and clean-up of those folders when they are no longer used. Yuck!

Currently I use scp for the reporting tool. From within the container I scp to and from 172.17.41.1. That works, but is again a pain as it means repeatedly typing in my login credentials, as the container doesn't even know what user is running it, let alone that user's private keys. This approach means I can never use the container in a non-interactive mode...

"docker cp" offers a great alternative for copying data out of the container, but there really is no good way to get the data into the container. Certainly I could create a new image each time. But that means each and every time I create a new container, I also have to create a new Dockerfile, do a new build, and clean-up the new image when I'm done. Yuck. Certainly I could write a script to do all of this. But then since the script is not part of the container, it breaks the pattern that I should just be able to run my image everywhere.

Currently if I don't want to use scp, I can run my image anywhere, after manually installing and hacking a bunch of scripts to maintain per container images or volumes.

[jaloren]

From my point of view, the feature addresses a huge usability issue with docker builds: prototyping sucks.And prototyping is a really important part of the image design process for docker. The best way to find out is trying it out. I am not even a little bit interested going through an entire docker build JUST because my prototyping requires copying over a handful of configuration files or a script that I didn't realize I needed 5 minutes ago. Like others have mentioned we've hacked around this by using ssh and scp but that's way overkill.

allowing me to docker cp arbitrary files into a running container neatly addresses that concern.

[timhaak]

Agree that the main time this is needed is during prototyping. You have your container running and you quickly need to add something while trying to get the build correct.

Right now you would have to add ssh and have that started and then have it removed from the final build.

This I believe falls into the same space as nsenter.

[comron]

+1 as well. For me I need the same thing as @tanmaig, I want to copy a temporary ssh key into the container that isn't known when the container image is built.

[coco98]

@comron The workaround I figured is that you just mount a data volume from the host to the computer. Then run SSH from the host computer etc, and copy data/git clone into the volume and it'll be available in the docker container. I guess the key idea behind not having the 'cp from host to container' is to force the stateless-ness of a docker.

[tobegit3hub]

The workaround way by docker exec is inefficient when the file is large.

+1 for the PR to extend docker cp.

[docbill]

It looks like #13171 is likely to be approved. One of the things that is problematic with the docker exec solution, is I find sometimes docker exec kills the container when exiting. As such is best avoided for running services.

[cpuguy83]

@docbill docker exec should not kill a container upon exiting (note, I'm +1 for the PR to add the docker cp functionality).

[alzarei]

+1

This is a very much appreciated feature for development. Although it is not the best practice for deployment! Please let the experienced users choose themselves!!

[artworkad]

• 1

e.g. use case: copy mongo dump from host to mongo container in order to restore the data

[ebuchman]

+1

This would especially be useful for data-only containers, where you might want to copy in a new configuration or private key.

[thaJeztah]

@ebuchman for secrets (private keys etc.) you might want to subscribe to #13490, which is all about that.

[rantoniuk]

+1 to merge and set milestone.

[deathemperor]

+1 I need it like right now at this moment

[baldwinSPC]

+1 This would be handy. I need it as well for a production app we're building.

[missedone]

+1 on this as it's really must have feature for me, for now as a workaround, i transfer the file via stdin of "docker exec" REST API call, but it's not convenient
please milestone this, thanks

[thaJeztah]

The pull requests implementing this are currently on the roadmap for 1.8; see #14058 and #13171. (That's no guarantee that they will make it though)

[jlhawn]

🎉 be sure to try out the Release Candidate for Docker 1.8 when it comes out!

[duglin]

Congrats Josh!!!

-Doug

Sent from my iPhone

On Jul 21, 2015, at 5:11 PM, Josh Hawn notifications@github.com wrote:

be sure to try out the Release Candidate for Docker 1.8 when it comes out!

—
Reply to this email directly or view it on GitHub.

[erikh]

+1 congrats. Been watching this thing for a long time now. :)

-Erik

On Jul 21, 2015, at 6:09 PM, Doug Davis notifications@github.com wrote:

Congrats Josh!!!

-Doug

Sent from my iPhone

On Jul 21, 2015, at 5:11 PM, Josh Hawn notifications@github.com wrote:

be sure to try out the Release Candidate for Docker 1.8 when it comes out!

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub #5846 (comment).

[sunnycmf]

👍 congrats!