add NO_PROXY variable to shellinit with boot2docker ip #345
Conversation
databus23
changed the title
|
@tianon Any feedback on this? Since docker 1.5 @ehazlett I think this is also something to consider for |
databus23
force-pushed
the
no_proxy_env
branch
from
2e5c07c to
1b15af5
Compare
|
I'm running in the same issue and I guess everyone running behind a corporate proxy. Currently my workaround is: This patch would be a nice addition. +1 |
|
This doesn't strike me as totally insane, but it does seem kind of fragile, especially since we're making assumptions about how the user wants to use their proxy -- what if they really did want it proxying their boot2docker communications as well? |
|
@tianon I fail to come up with a valid use case where a user would want to proxy their boot2docker communication. As boot2docker is virtualbox-only we are always talking about a local VM in a private network only reachable from the host system itself. The proxy would have to run run on the host system or inside boot2docker which makes no sense to me. The far more likely scenario is a (corporate) network where an http_proxy is required to connect to the internet and the http_proxy environment variable actually gets in the way of a user using boot2docker. Additionally the resulting error message from docker is not really helping in understanding the problem. With 192.168.59.103 being the boot2docker ip there is no indication at all that there is a proxy involved. I originally thought the problem was related to something with the docker TLS setup and it took me a while to understand the error is generated by our corporate proxy. I think the boot2docker experience with docker 1.5 is in almost all cases not optimal if an http_proxy environment variable is set and users will have an unnecessary hard time getting boot2docker to work. If we can agree to to proceed on this I would also hope to get something similar included in docker-machine for all the local vm providers (e.g. fusion, virtualbox) because it will suffer from the same problems. |
|
Yeah, I guess that makes sense.
@ehazlett would you mind giving us your thoughts from the Machine PoV too?
:+1: I want very much to avoid creating unnecessary disparity in the basic
functionality between boot2docker-cli and docker-machine, so as long as you
think this is something reasonable for Machine too, I'm convinced.
|
|
@tianon sorry for the delay. yes this makes sense as a lot of users would have proxy issues. we are going to do it in machine too. |
|
@tianon Now that we have established that machine also is adding this can we proceed on this pull request for boot2docker-cli? |
|
@tianon Any chance we can make progress on this PR? This is really annoying in our corporate network. |
|
LGTM cc @gmlewis @Moghedrin |
| //if a http_proxy is set, we need to make sure the boot2docker ip | ||
| //is added to the NO_PROXY environment variable | ||
| if os.Getenv("http_proxy") != "" || os.Getenv("HTTP_PROXY") != "" { | ||
| //get the ip from the docket/DOCKER_HOST |
|
A bunch of style-related comments... otherwise LGTM. I'm not merging, as I would prefer the style comments be addressed. |
The docker client respects the HTTP_PROXY environment variable for api calls since version 1.5. This kind of breaks the boot2docker scenario because docker is running on a local VM which most most certainly won't be reachable by the proxy. This commit changes `boot2docker shellinit` to append the DOCKER_HOST to the NO_PROXY variable.
no_proxy_var -> name no_proxy_value -> val
|
@gmlewis Thanks for the feedback, I incorporated your suggestions and rebased against the current master. |
|
Fixes look solid! 👍 Let's merge as soon as Travis is green. 💚 |
add NO_PROXY variable to shellinit with boot2docker ip
The docker client started to respect the HTTP_PROXY environment variable for api calls with version 1.5.
This kind of breaks the boot2docker scenario for us because docker is running on a local VM in a private network which is not reachable by our corporate proxy.
This pull request changes
boot2docker shellinitto additionally append the DOCKER_HOST to the NO_PROXY variable.I think this is a useful change in general because even before the docker client used HTTP_PROXY it was not possible to access http(s) ports exposed by containers without modifying the NO_PROXY var.