Exporting base dir as volume by default uses unnecessary disk space

[jimmidyson]

Data in Docker volumes are copied to a host dir when a container is started. This can lead to wasted disk space & create problems if there are a large number of containers running from maven plugin created images.

As an example, I had an image created with 67MB of JARs in /maven. /maven was marked as a volume in the image. When running a container from this image, the JARs were copied to a directory under /var/lib/docker/vfs/dir/<CONTAINER_ID>/... which led to 67MB of disk usage per container. When running 1000s of containers this actually lead to out of disk space issues.

Perhaps defaulting exportBaseDir to false would make sense? It's nice be able to use the base dir as a volume for development, but the drawbacks for production usage should be noted.

[jstrachan]

also using a maven property "docker. exportBaseDir" would be nice so folks can enable/disable it in a root pom.xml easily.

[rhuss]

At least the property already exists: docker.assembly.exportBase (but should probably called docker.assembly.exportBaseDir which I will rename for the next release)

[jimmidyson]

Ah OK! Didn't see that - thanks.

[rhuss]

Rereading the docs I have to confess that I probably completely misunderstood Docker's volumes concept when I implemented this feature. I thought that VOLUME is required for an export in the Dockerfile so that -v will work when creating a container. In fact, both are equivalent and will do the very same.

Also, the initial use case was to create a data container holding the artefacts which are mounted by appserver containers which deploy artefacts during startup. For this scenario, exporting /maven makes sense, because only a single container will exist which is reused by potentially many app server container. (However, just learned that docker rm -v is necessary to avoid dangling volumes).

For the other scenario, where a base image with the runtime context is used, an export doesn't make sense at all and can be quite harmful.

My suggestion is to make the default dependent on whether a from configuration is used: If from is used, exportBaseDir is false by default, otherwise its true. Ok, its a bit more "magic" but I think its not too smart as the use cases are quite orthogonal. Also, if someone uses an alternative from for a data container setup (instead of the standard "busybox"), it will immediately croak that the volume doesn't exist when starting the container (fail fast). Much better then a disk overflow which happens much later. And the fix is trivial, add a exportBaseDir=true.

If there are no objections, I will

• Set exportBaseDir's default to false if a base image (from) is used, keep it as true otherwise.
• Rename property docker.assembly.exportBase to docker.assembly.exportBaseDir
• Update documentation :)

[jimmidyson]

That sounds great to me. Thanks @rhuss

[jstrachan]

@rhuss thanks!