@davetucker Works as expected. Just tested it with Beta 13.
Thanks for responding so quickly with this feature! This still didnāt work for me.
Hereās some output from attaching to the docker VM via screen right after starting up docker for mac:
`
moby:~# curl http://google.com
curl: (7) Failed to connect to google.com port 80: Connection refused
moby:~# export http_proxy=http://myproxy.mycompany.com:80
moby:~# export https_proxy=$http_proxy
moby:~# curl http://google.com
301 Moved
The document has moved here. `Are you definitely running Beta 13? If you have your proxy config completed in System Preferences
, this should automatically appear inside Moby. Also, you may want to try with curl -L
to follow redirects.
I tried this and Iām seeing two problems with this
- My company relies on Proxy auto-configuration (PAC) for correctly setting the proxy and defining exclusions. This obviously is not picked up by Docker for Mac. If I set an http_proxy explicitly in the system settings I loose the PAC configuration and have to define exclusions manually.
- The no_proxy environment value is copied unchanged from the system settings. On OSX its possible to define exclusions with ā*ā as the wildcard character (e.g. *.my-company.com). There is almost no Linux/Unix software that understands this format including golang. On Linux/Unix its common that the no_proxy environment variable just contains a list of hostnames suffixes (e.g. my-company.com). So to make the no_proxy environment variable work for docker the no_proxy settings from OSX should be stripped from *. and CIDR notations and if your at it your best remove spaces from the value entirely because some linux software trips over that as well.
Both problems could be mitigated by providing explicit configuration settings in the Docker.app settings as suggested by a previous post.
I have the same problem here. I have PAC configuration. When I set http proxy directly, other applications have problems.
Thanks for the feedback. Re: PAC, this is unfortunate
Iāve opened issue (#3516) on our tracker to add support for this.
Re: no_proxy formatting, this has also been reported in this post, weāre working on a fix - issue (#3514)
As for providing UI for setting proxy configurationā¦ Iāve opened an issue for that too. Ideally it will display the values that have been auto-detected and allow you to override them.
Yes, Iām definitely running beta 13. After seeing @databus23ās comment, I realized that I am also on a PAC configuration which is why it isnāt working.
This tracker is not public by any chance?
This post is only concerned about whitespace. Could you also add the adjustment of wildcard notations to the mix so that it is in a format that unix tools understand it?
No the tracker isnāt public, but the issue numbers will appear as fixed in the changelog.
The adjustment of wildcards is tracked in (#3535)
I also use auto proxy settings on our corporate network, and when I try to run:
$ docker run hello-world
Unable to find image āhello-world:latestā locally
Pulling repository docker.io/library/hello-world
docker: Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/hello-world/images. You may want to check your internet connection or if you are behind a proxyā¦
See ādocker run --helpā.
When I manually set the proxy information, INCLUDING the login information, I get:
$ docker run hello-world
Unable to find image āhello-world:latestā locally
Pulling repository docker.io/library/hello-world
docker: Error while pulling image: Get https://index.docker.io/v1/repositories/library/hello-world/images: Proxy Authentication Required.
See ādocker run --helpā.
+1 from me as well, the auto-proxy config seems to complicate things. A setting allowing us to just set the proxy in the VM seems like a good fix.
Setting the proxy at the system preferences is a decent workaround, but poses an issue in that the change affects every app on the system that uses the connection. This can lead to unexpected connection problems when a client isnāt explicitly going through the OS level proxy, which is why we much prefer the previous method of setting the proxy on the Docker daemon itself and letting the user set proxy settings other clients themselves.
My company implements Man In the Middle sniffing of all HTTPS connections, so Iām getting this error when I try to pull using beta 15:
$ docker pull fedora:latest
Pulling repository docker.io/library/fedora
Error while pulling image: Get https://index.docker.io/v1/repositories/library/fedora/images: x509: certificate signed by unknown authority
I need a way to be able to install our official corporate MITM certificate.
Not sure what happened. With Version 1.11.2-beta15 (build: 9168) it appears as though proxy support is no longer working for me.
$ docker pull busybox
Using default tag: latest
Pulling repository docker.io/library/busybox
Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/busybox/images. You may want to check your internet connection or if you are behind a proxy.
How can this be debugged and the VM checked for settings etc.?
Additionally also note that the screenshot for proxy details in https://beta.docker.com/docs/mac/networking/ is invalid because the Web Proxy Server field should not have the http://
in it but simply the hostname or IP. Using it will not work in OS X, however with or without it proxy is not working in docker pull
scenario for me atm.
On this particular issue, a reset from the UI did not work; but a full uninstall and install again fixed the issue.
If mac proxy settings is set with mac local ports, docker for mac will set proxy with VMās local port causing networking failure.
I would absolutely love for āDocker for Macā to support a local proxy. Iām running SquidMan on my Mac, which is āgraphical installer and manager for the Squid proxy cache. It is designed to operate as a āpersonalā proxy server.ā.
I want this to work because Iām tired of docker builds taking minutes instead of seconds because Ubuntu has to constantly download the same packages over and over again.
Thanks!
My company also implements MITM sniffing and will require this functionality.