Serve the build context

[jvassev]

This has to do with #6906 in a way.

So I need to install a huge (~400MB) rpm. I used to do it with:
COPY product.rpm /tmp
RUN rpm -iv /tmp/product.rpm && rm /tmp/product.rpm
As a result you end up with an image twice the size.

Since the rpm is already a sibling to the Dockerfile I started serving the whole build context over http befors the build starts and have a single RUN layer instead:

RUN rpm -iv http://build.context.local/product.rpm

The downside is you need to run at least "python -m SimpleHTTPServer" beforehand. Then run dnsmasq alongside with docker and to support parallel builds, pre-process the Dockerfile so that different build contexts are served on different base urls.

However to support this approach the docker daemon could easily run a http server exposing the whole build context on / for every build started. The hostname build.context.local is available only during build and can be different.

This is an alternative to mounting a volume during build. It seems not so intrusive - it is just as portable as RUNning "yum install". On the other hand not every tool out there might be as http-friendly as rpm.

[thaJeztah]

I'm -1 on this. I think this will add a lot of extra "moving parts" that are already possible with existing tools (which you mentioned) and not really something that belongs in the core functionality of Docker.

[jessfraz]

Hello!
We are no longer accepting patches to the Dockerfile syntax as you can read about here: https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax

Mainly:

Allowing the Builder to be implemented as a separate utility consuming the Engine's API will open the door for many possibilities, such as offering alternate syntaxes or DSL for existing languages without cluttering the Engine's codebase

Then from there, patches/features like this can be re-thought. Hope you can understand.