Description
Use Case:
My build process for Gentoo images requires the /usr/portage tree. At ~800M it is larger than most of my final images and I don't want it included in the images as it is not needed post-build. As docker files don't support, and are philosophically incompatible with, bind-mounts from the host, I currently manage my build process with docker run and /usr/portage declared as a volume then bind-mounted from the host.
It would be preferable to stick /usr/portage and other build time dependencies in a data image/container and then declare VOLUMES-FROM build-deps-container-or-image as a step in a dockerfile. This would allow host-independent use of build-time deps and is, thus, preferable to allowing escalated privileges or bind-mounts in dockerfiles.
I think some of the use cases in #1916 would be compatible with this.
It's probably preferable to implement this with the volumes coming from a base image rather than from a base container.
Options:
- VOLUMES-FROM that is semantically equivalent to
docker run -volumes-from. Unfortunately, this and the original -volumes-from option limit you to the volume paths declared in the base container. - VOLUMES-FROM-IMG with configurable source and target paths and the source being an image not a container.
VOLUMES-FROM-IMG base-image base-image-dir:[container-dir] .... - VOLUME-FROM-IMG with the same semantics as (2) but only a single volume allowed per line.
The volume mount should persist through all subsequent docker build commands to the end of the build process. The resulting image, however, would not contain any additional metadata beyond what VOLUME already creates.
I discussed this with @shykes on twitter (https://twitter.com/solomonstre/status/417450365823381504) but couldn't find the issue he mentions. Apologies if this is a duplicate.