Feature request: Mount volume when run docker build

[ghost]

We now using Docker build to compile our project and then delivery the result executable binary to small docker container, we need new feature, mount volume when run docker build

Build binary

docker build -f BuildDockerfile  -v $(pwd):/out   --rm -t mybuild  (and other arguments)

After build finish, will generate two file , one executable binary, and one configure file

Make production light weight container image

example production Dockerfile

FROM scratch

ADD mybinary /mybinary
ADD main.conf /main.conf

EXPOSE 80

ENTRYPOINT ["/mybinary", "-c", "/main.conf"]
CMD []

and we can run docker build again to generate a light weight container images container the must have files to run an instance with docker

[phemmer]

Take a look at #7115. I think this is a cleaner solution to your end goal.

[ghost]

Looks great Proposal.

[ghost]

Thanks for your tips.

[ryenus]

@phemmer,

Is it possible to reopen this request?

Now it's late 2016 already, the linked issue is from 2014 and still open, and adding -v support for docker build shouldn't be much work as it's already there in docker run.

This would greatly speed up building an docker image from existing host files, especially when the host files are huge.

During docker build, for smaller files, in the Dockerfile, one can use wget to download, but not good for huge files. In this case it would be really helpful to able to mount a host volume and use the host file directly to avoid data copy/download over network.

[phemmer]

I can't control whether it's open or closed. But I think you'll find you get a lot of resistance to a build -v option. The docker team has been very opposed to flags which introduce non-reproducability between builds. Even the --build-arg was introduced after much contestation.

Personally I'm also for not putting in hacks or temporary solutions just because the ideal solution hasn't been implemented yet. If the feature is added it should be because it has merit on its own.

But I'm not associated with the docker project, so just consider me part of the peanut gallery.

[binarytemple-external]

Yes, but it's really useful when you want to expose something like .ssh/id_rsa without ever writing to disk during a sequence of build dependencies.

[graingert]

@thaJeztah dupe of #14080 ?

[thaJeztah]

@graingert yes it is, sorry, should've added that 👍

[sjlongland]

In my case, where this would be useful would be on Debian systems: mounting /var/cache/apt as a volume, so you're not re-downloading the same .deb files over and over again. (Truly "unlimited" Internet quota just doesn't exist, especially here in Australia, and it even if there was, there's time wasted waiting for the download.)

Or another scenario, you're doing a build, but it also produces test reports such as failure listings and code coverage reports that you don't need to ship with the image, but are useful artefacts to have around. These could be written to a volume when a CI server goes to build the image for the CI server to pick up and host.

Or tonight, I'm doing some Gentoo-based images for myself, I'd like to mount /usr/portage from the host. It is not hard for a Dockerfile to realise, "hey, /usr/portage (in the container) is empty, no problems I'll just grab that" when running without the volume mounted, OR, it just uses the volume as-is, saving time fetching a fresh copy.

Adding those smarts is a trivial if statement in a Bourne shell script… IF the underlying logic to mount the volume is present in the first place. Right now for my Gentoo images, I'm having to pull /usr/portage every time I do a build (luckily the mirror is on my LAN) which means it's a good few minutes wait for that one step to complete.

So lots of reasons why this is a worthwhile proposal, and I'm doubtful that the nested builds proposed in #7115 is going to help in the above instances.

[graingert]

@sjlongland this issue is currently closed because it's a duplicate of #14080 please move your comment over there.

[graingert]

please comment on #14080 instead

[thaJeztah]

Yes, let's lock this issue to prevent the discussion from diverging