Skip to content

Volume bind mount for Dockerfile#8394

Closed
namhyung wants to merge 2 commits intomoby:masterfrom
namhyung:volume-bind-mount
Closed

Volume bind mount for Dockerfile#8394
namhyung wants to merge 2 commits intomoby:masterfrom
namhyung:volume-bind-mount

Conversation

@namhyung
Copy link

@namhyung namhyung commented Oct 4, 2014

This patch adds support to bind mount for VOLUME command in Dockerfile. AFAIK currently a volume only can be bind-mounted with docker run command (-v option), but with this change, one can use VOLUME command in a Dockerfile to specify such bind mount when building an image too.

Current VOLUME command in a Dockerfile cannot bind mount with a host
directory.  Add support it to the VOLUME command too so that users can
specify something like below in their Dockerfile:

  VOLUME  /this/is/host/dir:/container/foo
  VOLUME  /another/host/dir:/container/bar:ro

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
@unclejack
Copy link
Contributor

Making a change to allow bind mounts from the Dockerfile would allow images to bind mount arbitrary directories and files from the host by default.

NOT LGTM

@cpuguy83
Copy link
Member

cpuguy83 commented Oct 4, 2014

NOT LGTM

@unclejack
Copy link
Contributor

I'm closing this now because it's not going to be merged for very good reasons:

  • adding bind mounts to images would break one of the basic Docker principles of not making images depend on specific host details (what if the bind mounted directory/file doesn't exist on other hosts or it can be found somewhere else? what if I need to run two containers which would need to access the same resources?)
  • adding these bind mounts would also be a security risk: a specially crafted image could bind mount /etc, /home and many other directories to copy and upload sensitive information; the security risk would be unacceptable

@unclejack unclejack closed this Oct 5, 2014
@buzypi
Copy link

buzypi commented Oct 15, 2014

@unclejack and @cpuguy83 : I would like to discuss this usecase a little further and request your suggestion on this.

Let's say I want to create an image for MySQL and so I have a "RUN apt-get -y install mysql-server" in my Dockerfile.

When building the image MySQL creates a data directory /var/lib/mysql in the image. This data directory contains some metadata required for MySQL to start.

However, I later want to store the data in a mounted volume and not store it directly in the container. So, when I later run a container using this image, I have to somehow pull out the installed directory into a hosted volume because, without this, I won't be able to start MySQL. (in other words I cannot mount a blank directory as /var/lib/mysql/).

So I now have 2 choices:

  1. What this patch does - allow volumes to be mounted during build
  2. I have to somehow move the data directory out after installation either by accessing btrfs or aufs or run a container and stop it and run docker cp.
  3. (Any other way?)

I am sure most databases' data directories work in a similar way and this page in the Docker documentation clearly lists that Docker does recommend mechanisms to mount db data directories externally: https://docs.docker.com/userguide/dockervolumes/#creating-and-mounting-a-data-volume-container

I am not suggesting that this patch is the way to go and I clearly understand the issues outlined by @unclejack. However, I am not sure what's the right way of doing this.

Request your suggestion.

@cpuguy83
Copy link
Member

@buzypi
Volumes handle this now.
Let the seed data be part of the image, when you use "docker run -v /var/lib/mysql" docker automatically copies this data out into the volume for you.

@buzypi
Copy link

buzypi commented Oct 15, 2014

@cpuguy83 Oh cool, I didn't know that. Let me try this. I thought Docker mounts are like OS filesystem mounts where a mount will hide the host directory at the same location.

@buzypi
Copy link

buzypi commented Oct 15, 2014

@cpuguy83
This seems to work as you mentioned:
docker run --name="dbtest" -v /var/lib/mysql -d my-mysql:0.0.1
But this does not work and the container does not start as the directory is empty:
docker run --name="dbtest" -v /data/mysql:/var/lib/mysql -d my-mysql:0.0.1

@cpuguy83
Copy link
Member

@buzypi Well, i started using Docker @ 0.6.5, and ever since then at least.

The way volumes work is when you "-v /foo", docker creates a dir on the host. Docker copies that data that was in "/foo" (if any exists, or creates /foo if /foo didn't already exist) into the new dir on the host, then mounts that host dir into the container at /foo.

@buzypi
Copy link

buzypi commented Oct 15, 2014

@cpuguy83 Agreed, but then this does not allow me to host a directory of my choice. I see that this is inside /var/lib/docker/vfs/dir/. Is there a way to mount a host directory of our own and also copy data during the initial run?

@cpuguy83
Copy link
Member

@buzypi Docker will specifically not copy data into a user specified dir (for now).
I hope to reverse this decision (assuming the dir provided is empty).

@buzypi
Copy link

buzypi commented Oct 15, 2014

@cpuguy83 So for now the workaround seems to be this:

docker run --volumes-from dbtest -v /data/:/data/ my-mysql:0.0.1 cp -pr /var/lib/mysql /data/
docker run --name="dbtest2" -d -v /data/mysql:/var/lib/mysql/ my-mysql:0.0.1

And then discard dbtest

@cpuguy83
Copy link
Member

Yep, I do this frequently (or something close to it) for config files and such.

@buzypi
Copy link

buzypi commented Oct 15, 2014

@cpuguy83 Ok thanks. That seems like a good enough solution for now.

@thaJeztah
Copy link
Member

I hope to reverse this decision (assuming the dir provided is empty).

@cpuguy83 I was looking for the same recently. Is there a proposal for that, so that I can give my +1 on that?

@cpuguy83
Copy link
Member

@thaJeztah No proposal as such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants