machine 0.3 does not work if docker daemon needs http_proxy

[lasdecoeur]

Hi,

I saw that docker-machine now delete the initial /etc/default/docker file (ubuntu with openstack driver) and put his DOCKER_OPTS in a new one.

What if there is some "export http_proxy" in this file (from a previous installation) ? The daemon started by machine hasn't got internet and is not able to pull images.

I searched some issues about that and found nothing.

A solution is to do docker-machine ssh after and put new lines in this file and restart the daemon, but it could be nice to be able to give to docker-machine (with a file or CLI options) to set those variables ?.

Any help/advices ? Thanks.

[hairyhenderson]

This has been brought up a few other times, but from different angles...

I think all we need is some kind of --proxy setting on create which would be delegated to the provisioners to set http_proxy/https_proxyin the environment when downloading stuff, and also in the engine config file.

A bunch of other requests like these have been closed due to plans to move to cloudinit, but those don't seem to be materializing as quickly as previously thought ;)

/cc @nathanleclaire @ehazlett

[sthulb]

If we could, we should detect the proxy and then pass it through, if it's a local machine.

[hairyhenderson]

@sthulb +1, though that's definitely only relevant for the local drivers

[ehazlett]

@hairyhenderson good point re: cloudinit. I think we could add a --proxy option. I'll look into this.

[nathanleclaire]

I think all we need is some kind of --proxy setting on create which would be delegated to the provisioners to set http_proxy/https_proxyin the environment when downloading stuff, and also in the engine config file.

I'm in favor of the general idea (we've had enough requests for setting the proxy for daemon in particular that I think we should support it), I am not sure if we should conflate provisioning-time proxy with daemon run-time proxy or not though. Having a proxy for the daemon would imply --engine-proxy or similar.

If we could, we should detect the proxy and then pass it through, if it's a local machine.

Hm, maybe an option/flag to do so, but I'm hesitant on automatic behaviors such as this. The user should be in the mindset of thinking of created machines as independent entities with their own behaviors. Conflating this has already caused us some pain before, e.g. with volumes.

[sirlatrom]

@nathanleclaire I can imagine multiple scenarios when the proxy used for docker-machine would be a different one than that used by the engines it creates and configures

[stephanbuys]

@nathanleclaire I would propose the ability to simply pass through an environment variable during machine create, currently the Docker Engine works fine with proxies if the environment is configured before the engine is started (usually as part of the init script or something like /etc/default/docker).

How about something like docker-machine create -d virtualbox --engine-env HTTP_PROXY=http://192.168.0.1:3128 dev

[hairyhenderson]

@stephanbuys - that's definitely part of it, but when a proxy is required usually it's needed for installation as well, so it's not just an engine-specific environment variable - it needs to be set in other places too.

I definitely think there's a place for a general option like --engine-env, but the scope for --proxy is slightly wider IMO.

[udryan10]

@ehazlett have you gotten a chance to do any work on this? If not, I just about have a PR ready that I can submit. In my fork I added the following flags as I thought it made the most sense:

   --engine-http-proxy          Specify an http proxy to use with the engine
   --engine-https-proxy         Specify an https proxy to use with the engine
   --engine-no-proxy            Specify no proxy to use with the engine

I agree with @nathanleclaire that automatically pulling from environment variables is an automatic behavior that may create some undesirable results. ie.. I may be running my localhost with a proxy but I want to create an engine that does not use proxies - controlling this with flags gives me full control over this.

[nathanleclaire]

@udryan10 I haven't had a chance to work on this and I don't think @ehazlett has either so we welcome the contribution!

[ehazlett]

closing as #1497 is merged.