Initially I had some hesitation here (still not 100% sold), but I think this should be ok.
I can't see why this would break the image portability.

The portability of the build itself is probably still fine as people can rely on the same kind of functionality that networks provide (DNS discovery) even without this change.

-- EDIT --
Maybe need to make sure to not allow --net=host or --net=container

Thanks @sandyskies! Following the discussion on #10324 I'm not sure we should implement this though; there's quite some concerns around adding this option, but let's wait for other maintainers to comment here as well

edit: just see @cpuguy83 commented already (sorry GitHub didn't show his comment yet)

I think --net=host options is what most guys want most as we can see in the issue mentioned about. In some occasion, bridge network mode is not allowed because of security reason and lack of ip resource. So if some guys want to build a image from a Dockerfile in this particular occasion, he just can't connect to network, which makes him unable use apt-get or yum command to manager software.
A solution to this is to run a container with --net=host option, and finally commit as a image. So I think using --net=host option when build a image from Dockerfile will be just fine, otherwise people will use the way I mentioned about to achieve this purpose. @cpuguy83 @thaJeztah

ping @tiborvass @calavera could you have a look at this please? what are your thoughts?

It is impossible to install uhd-host Ubuntu package during "docker build" as there are missing files that are required by it (/proc/sys/net/core/rmem_max and /proc/sys/net/core/wmem_max). These files are created by --net=host option when calling docker run.

@ptrkrysik Can this PR fix ur problem or not？

I messed this PR with issue that there is no --net=host during 'docker build'. The discussion here seemed much more fruitful than in #10324 (which messes two separate issues). Sorry for confusion. I haven't yet checked if this PR is what is needed to fix issue with installation of uhd-host package.

We just discussed this PR in our maintainers review session, and would like to look into the use-cases in #10324 to see if this is the best solution, or if there are other solutions that may be better. @justincormack is going to have a look at those, and @vdemeester has some alternative approaches that may be worth investigating.

There seem to be a bunch of reasons for this feature request mainly discussed in #10324, will try to summarise:

1. People who have desktop hosts that do not work with docker networking usually due to VPN settings outside your control, so they use --net=host for all docker run commands, but cannot build.

   If anyone in this situation is using a Mac, then we have VPN mode in the new Docker for Mac, which should fix this by doing all network requests from the host. If you have this problem and use a Mac, please sign up on https://beta.docker.com/ and email beta-feedback@docker.com mentioning this issue and we can give you an accelerated invite to test this. This will be available for Docker for Windows in future as well, and we will try to support any issues with VPNs here.

2. People with a similar issue on AWS/other clouds.

   This does not seem to be a common problem, and I think the cloud boxes are just not configured correctly and should be fixed. Network isolation is a normal Docker feature and should work, and --net=host is normally only required for a few use cases, such as higher performance on 10Gb networking, but this does not apply to build.

3. People who want to disable networking for build for full reproducibility.

   This is a pretty unusual use case, I quite like it, but I don't know that it is best addressed by a patch that allows more networking options.

4. People who want to run local services that run while a build is taking place, for example a database to run tests against.

   This is not the recommended way to run your tests. You should run tests using docker run using the built artefact, not at build time. This will not work with an external builder, and means that your build is not self contained. Build should be limited to just build and potentially small self contained tests, not integration tests. We also do not want to support things in build that cannot be built elsewhere because they require additional services, for example as automated builds on services like Docker Hub.

5. People who want to modify the hosts file during a build to point a name at an external host without using DNS.

   This PR does not address this. There are workarounds discussed in the issue, which are a bit ugly but will work if people really need to do this.

Overall I think that adding features to support what are essentially not properly working docker installs that do not have working network isolation, is probably a mistake, as there does not seem to be any justifiable use case on working docker install, so I have to recommend that we do not go ahead with this PR.

@justincormack Ur summarise doesn't include my use case. The commany I work for has a strict security policy ,iptable_nat is not allowed to use in production environment, and we are not allow to allocate ip freely. Therefor bridge network mode is not a option in our production environment, host network mode is the only one choice(We consider performance as well) . Without this pr, there is no way I can use networking When build a image from Dockerfile.

I think many people have the same use case as I do, include cloud vm u mentioned in number 2( I don't agree about that u think this is not a common issue. Cloud providers providing a guest os that bridge network mode won't work should be common issue.)

@sandyskies It is not really recommended that you do builds on your production servers, you should be aiming to do them in your CI pipelines. I don't think there is any security reason why your CI machines should not use NAT in general, even if production is restricted like that.

Can you give me an example of a cloud provider guest image that does not work with bridged networking?

Note that you should be able to use bridged networking without NAT as well if you allocate routed IP addresses to the bridge (ipv4 or ipv6).

@justincormack As I mentioned , routed IP addresses could not be allocated freely in my company.

In #10324
junlian1 mentioned that:
+1 --net=host
Also, on a cloud vm. run works with --net=host, but I can't build a docker container.

michaeljoy mentioned that:
+1 --net=host
"docker build" does not work often times in various permutations of AWS EC2 VPC's as well, while docker run works perfectly fine on 1.8.1. The divergent networking behavior between docker build and docker run needs to be sorted.

I don't think this is just a coincidence.

@justincormack Another use case:

Users who build images with dependencies on private rubygems servers and/or npm repositories, and where they are hosting said repositories inside docker.

Workarounds include passing IP addresses to docker build via --build-args, or bypassing ruby/npm repositories' HTTP interfaces and reaching directly into their file volumes.

@rkuzsma that's not a use case that we want to support; building a Dockerfile should be reproducible, and requiring other containers or services to be started in order to build the Dockerfile make them non-reproducible, unless you're in exactly the same setup, so not something we want to support.

Unless I'm mistaken (and I'm hardly an expert in Docker so I may very well be), you can already induce the unreproducible build situation. The ADD instruction can take a URL (without any host restrictions) and the Docker bridge is able to access resources on localhost, by default. I was just able to build an image that fetched a file from a local web server.

On the other hand, we also have unreproducible builds by not being able to access any network content. Essentially no images can be built when connected with a Cisco VPN client. Fetching something from localhost is bad, sure. But that's a policy/cultural/people problem that's easily solvable with communication. Not being able to use --net options is a technical hurdle that simply can't be cleared in many environments.

The absence of this option is creating unreproduceable builds for many
people, including me. In some systems docker cannot touch iptables in any
way, which means unless a user is able to specify the network and/or IP the
build will run on, it is very well possible the build instance won't be
able to access the internet. Can't get more unreproduceable than this.

Gonçalo Luiz

On 23 June 2016 at 19:24, Jess Frazelle notifications@github.com wrote:

-1, this could create unreproducable builds which is one of the reasons
docker is so awesome.

Say for example the Dockerfile uses net host to contact a service on
localhost to download arbitary content. Also what does this mean in terms
of things building on hub or any other bash executioner as a service.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#20987 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AFPBTvlwkWXuC_AJavbEvS6bOabP4cX7ks5qOs9bgaJpZM4HqP8i
.

I am agree with @gedl . The absence of --net host may cause much more unportable builds. People use the same Dockerfile ,and they are under different environment, one can connect to network and one are unable to because without this option. Do u think they can build the exact same image from that Dockerfile ? @jfrazelle

@mrjana @aboch Do either of you have any ideas about how to solve the vps issues that people are having during builds?

Wanted to chime in and say that the lack of --net=host during build is causing issues inside an Azure VM as well. When I do docker run, all is fine and dandy. docker build will fail.

@crosbymichael If the user has VPN enabled it will hijack the main routing table so bridge network which also needs routing may be affected. There is nothing we can do there as this is really the security policy in VPN which in most deployments disables "split tunneling" mode.

As far as users having issues with cloud providers we should try to understand what they are. Because there shouldn't be any and if there is any that should be fixed first because that probably affects docker run over bridge network as well.

@dend Can you explain what issues you are having in an Azure VM when doing a docker build? Is it possible to provide daemon logs when this happens so we can understand the different between docker run and docker build?

@mrjana But, Docker already has a solution for this for "docker run". This PR is about extending that same functionality to "docker build", which would address the issue.

@mrjana I have a Stack Overflow question that documents my case.

I also bump into this limitation today. As others pointed out, I don't see how this feature makes building less reproducible considering that network traffic that is already allowed during a docker build already introduces substantial amount of non-determinism (apt-get update if frequently user on moving targets).

+1 I badly need this.
I need to pull from git repo only accessible via vpn when building my private image.
I can't pull during build or from a container without specifying the --net=host option on running the container!

Hi @sandyskies we are reconsidering this - would you like to rebase it and we can look at reviewing and merging it.

I extended this in master...tonistiigi:net-builder to add builder directives for net and add-host. This way author of Dockerfile can define if it should only be used in a special configuration and if the user doesn't pass correct arguments they get an error before the build starts.

# net = none
# add-host = myserver

from ubuntu
run wget http://myserver/foo

The values are comma separated list of keys. Negation is supported with !. host,bridge reads as "host or bridge". !none means any network option but none is allowed.

Let me know if this seems reasonable compromise and I'll add more integration tests.

@tonistiigi that seems like it could be useful in some cases.

Shouldn't the option be called --network to match the corresponding option on the docker run command?

Or does this (--net) option on docker build only do a subset of what docker run --network does?

@Bill It should probably match the new name, but they both do the same thing. This issue and pull request predate the soft rename of --net to --network in c0c7d5e.

ping @sandyskies could you have a look at @tonistiigi's comment? #20987 (comment)

This is being carried in #27702, so I'll close this PR

@thaJeztah sorry ，it takes a long time in design-review， as someone else has make the another pull
request ,it is ok to close this PR.

@sandyskies no worries! your commit is preserved in #27702, thanks so much for starting the work on this