Can we get a version of this which doesn't mount a volume?

[danjenkins]

I want to use the official image but can't because the volume command stops how I want to use the image. I want to load data into an image, commit that change and then use that image as is so that all my tests run against a data store in x condition. With this image, I can't do that

[stuartpb]

Well, there's nothing stopping you from forking this repo and creating images from the Dockerfiles with the VOLUME command removed, but de-volumizing directories in images / committing volumes really is something that should be supported within docker run (the same way as it lets you override CMD and ENTRYPOINT), or docker commit, without having to create an entirely separate base image (since otherwise, as @danjenkins points out, the VOLUME command doesn't really get an image anything but decreased flexibility).

@yosifkit @tianon @jfrazelle Thoughts? This feels kinda sorta maybe like moby/moby#6999.

[danjenkins]

@stuartpb that's exactly what I did, but because the project has to be private, I've had to just copy the Dockerfile and remove the VOLUME command. Not great because now it's not easy to keep up to date etc but it works :)

I'd love the ability to override the VOLUME or remove it in a Dockerfile that pulls in the base one.

[jessfraz]

Tbh I wish we could remove the volume command from Dockerfile entirely, but
that's a whole different story.

The Dockerfile syntax is frozen so no changes are being made to it so we
can strip it out of the daemon to the client.

Long story short there is not a way to do what you want.

On Wednesday, September 16, 2015, Dan Jenkins notifications@github.com
wrote:

@stuartpb https://github.com/stuartpb that's exactly what I did, but
because the project has to be private, I've had to just copy the Dockerfile
and remove the VOLUME command. Not great because now it's not easy to keep
up to date etc but it works :)

I'd love the ability to override the VOLUME or remove it in a Dockerfile
that pulls in the base one.

—
Reply to this email directly or view it on GitHub
https://github.com/stuartpb/rethinkdb-dockerfiles/issues/14#issuecomment-140695440
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[tianon]

Could you reconfigure rethinkdb to use a different directory?

[danjenkins]

My objective was to have an image with a sample set of data already within it; hosted on a private registry. For testing purposes etc etc - so having a volume at all stops that plan. I don't mind having a copy of the Dockerfile and doing it that way; it's just not the best way of doing it (even if it's the only way right now)

[tianon]

Right. My suggestion to accomplish that easily would be to change the configuration file of rethinkdb itself to point to a different (non-VOLUME) directory.

[danjenkins]

Oh I see what you mean @tianon - create a new Dockerfile which uses this one as a base, and then change the rethinkdb configuration to not even use that volume. That would work

[stuartpb]

You don't even need a new Dockerfile, just run with rethinkdb -d /testdata --bind all instead of the default rethinkdb --bind all.

[stuartpb]

@jfrazelle:

Tbh I wish we could remove the volume command from Dockerfile entirely, but
that's a whole different story.

I agree, to a certain extent, but that would be a change to the Docker build system, and, as you said:

The Dockerfile syntax is frozen so no changes are being made to it so we
can strip it out of the daemon to the client.

What I'm talking about wouldn't be a change to Dockerfiles in any way, shape, or form. I'm talking about adding options to post-Dockerfile commands like docker run (telling it to ignore volume mounts, instead keeping the directory as part of the copy-on-write layer) and/or docker commit (telling it to commit the data in a given volume as part of the image).

[stuartpb]

Revisiting this a year later: per @jfrazelle's sentiment about how the Dockerfile system would be better if there just altogether weren't a VOLUME command, and @danjenkins' point about the volumes being an active impediment, would it maybe make more sense to just strip the VOLUME directives out of the Dockerfiles altogether (so that the image no longer defines any volumes)? /cc @yosifkit @tianon

[yosifkit]

Currently it is the best way to communicate to the user about where permanent data is located in the image and ensures that users get better performance by default in the specified directory. When users want to embed data in the image, we usually point to the method of re-configuring the data directory of the service contained in the image or in the case of the mysql images, /docker-entrypoint-initdb.d/.