Hi Eliot,

Looks like this version addresses the issue I had (creating volumes in the base container made it impossible to add repos or webapps in using Dockerfiles).

that's also one of the issues the earlier Dockerfile of Dirk and Michael had -- and I also had issues with that when I started with Docker. It's somewhat counter-intuitive that you have to `EXPOSE` ports to publish them, but not define `VOLUME`s to bind them.

Defining a volume in a Dockerfile results in a bind-mount of a new, empty folder (if not defined otherwise through `--volume[-from]`) during container instanciation. So you can very well add files into the image -- but they're hidden by that bind mount in the running container.

Regards, Jens

The problem was that I wanted to add files to the /webapp directory, but once the Dockerfile defines it as volume you can't modify it as part of the container definition, you can only mount to it from outside.

My general approach is to have two images, one without the volumes, for use in defining derived containers, and a working image that defines the volumes so they are ready for mounting from other containers or from the host.

I suppose another way to handle it is to not define the volumes at all and then do it in Docker-compose scripts (I'm using docker-compose to manage all my related containers and provide a convenient way to manage everything through one command).

The way it meant to be is usually adding logic/program code to derived images, and putting data/information into volumes. How those are managed depends on personal needs, preferences and the available infrastructure.

THis way you can "throw away" containers at any time, they don't have any state left any more. To publish a new version, you simply start a new container from the updated image accessing the data, but don't have to pass any application logic into the container.

Relying on docker-compose is a good thing to do, it also easons up migrating to a Docker swarm or other infrastructure management tools.