[shykes]

Hey StavrosK,

This is by design, "I want the postgres db data to live outside the container" is a deployment-specific decision, and should not be hardcoded into the container itself. You (or someone you distribute this container to) might not want the db data to live outside the container, or might want it to live at a specific path on his machine. That's why a Dockerfile lets you specify that /var/lib/postgres is persistent, but doesn't let you specify how to persist it.

Now, if I remember our IRC discussion correctly, in your case you're hitting a limitation of docker's implementation of volumes, which is that the container cannot specify an initial state for its volume - it can only start empty. That is a limitation that we're going to fix. But we need to make sure we fix it without breaking portability of containers.

I hope this helps.

[StavrosK]

Yep, it does help, thanks. Your reason is very clear and sane, it's just frustrating for me because my process is: I launch a VM, see all my memory being eaten up for nothing, then say "man, I'm so going to turn this into an awesome docker container", and, 30 minutes later, I hit a snag and have to quit.

Your proposal of having the container specify an initial state would certainly work. Exactly how to do this will take some thinking (what if the external volume has some files in it? What if it's empty but the user needs it empty? Etc), but I think this is a necessary feature for a large variety of use cases.

Thanks for the reply!

[zgohr]

Hey shykes,

This is something I'm still not quite clear on. According to the issues in mention here: https://github.com/dotcloud/docker/issues/1185 it is possible to do what StavrosK is asking. What am I missing? Why would a volume need an initial state when when the goal can be accomplished with a bind mount?

I also +1'd the documentation issue because I can't seem to wrap my head around what the current state of volumes and mounting is. Appreciate any direction you could point me in.

[shykes]

> Why would a volume need an initial state when when the goal can be accomplished with a bind mount?

This is in the special case where you want the application itself to determine the initial state of the volume. For example, the developer might want the database pre-loaded with a certain schema, default data and so on. External volumes/bind mounts are a way for the sysadmin to override how and where the contents of a volume are stored.

Re: documentation, you can take a look at this example: http://docs.docker.io/en/latest/examples/couchdb_data_volume...

I hope this helps! Feel free to join the IRC channel (#docker on freenode), it's unusually active and helpful, I'm very proud of how nice the people are on there :)