Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client config.json proxy settings ignored #947

Closed
Ka0o0 opened this issue Feb 9, 2022 · 2 comments · Fixed by #959
Closed

Client config.json proxy settings ignored #947

Ka0o0 opened this issue Feb 9, 2022 · 2 comments · Fixed by #959
Labels
Milestone

Comments

@Ka0o0
Copy link

Ka0o0 commented Feb 9, 2022

Hi,

I'm currently trying to get Buildx with a docker-container driver up and running within our CI infrastructure. Our build server is behind a proxy and therefore image builds require the correct proxy settings to be configured. Currently, we directly invoke the docker build command and have configured the proxy settings within ~/.docker/config.json as described in the Docker documentation. What this does it that it automatically populate the correct env variables within the container during build time, e.g. http_proxy, https_proxy, etc. This does not influence the Docker daemon behavior which uses the operating system's configuration.

I was able to get the docker daemon to work by passing through the env variables via --driver-opt env.http_proxy=$http_proxy and additionally using a custom buildkit image with the company root-CAs included so that the images were able to be pulled. But what I'm still missing is the exact same behavior of that the correct env variables are configured within the to-be-built build container.

E.g.

FROM debian:stable-slim

RUN echo $http_proxy

Running docker build . will print whatever is configured within ~/.docker/config.json. However, when invoking docker buildx build . will print an empty string.

Is there a way to achieve that behavior?

@tonistiigi
Copy link
Member

@thaJeztah Is this config only for the cli requests or does the client really send these to the daemon with the API requests (As if --build-arg HTTP_PROXY was typed)? I don't quite understand this as why should the proxies be the same on client and daemon side?

@thaJeztah
Copy link
Member

Yes, it's a bit confusing; the CLI itself uses the proxy from it's own environment XX_PROXY env-vars. The proxy options in ~/.docker/config.json set defaults for containers (equivalent of setting --env XXX_PROXY=<proxy> .. and --build-arg XXX_PROXY=<proxy> ..); see the original PR that added it docker/cli#93 and the docs here: https://docs.docker.com/engine/reference/commandline/cli/#automatic-proxy-configuration-for-containers

Note that

  • the configuration sets both upper- and lowercase variants of these (as casing is not formalized and some software uses upper, other lowercase), so (e.g.) both HTTPS_PROXY and https_proxy are set
  • the configuration also allows both setting a default (when using "any daemon") as well as proxies to use depending on which daemon is connected to (e.g. it can set different proxies to use when connected to tcp://example.docker.com:2376). The feature was implemented before docker context existed, and was not (yet) integrated with that.
For Use Used for
docker (CLI) XX_PROXY env vars in environment Connections made by the docker CLI itself (e.g. connecting to engine API over http(s), and docker manifest subcommands which connect with a registry from the CLI, as well as docker login if unable to connect with the daemon)
dockerd (daemon) XX_PROXY env vars in environment (or set in systemd unit) Connections made by the dockerd itself (e.g. connections with registries for docker pull and docker search (next engine release also allows these to be configured through daemon.json)
docker run containers --env XX_PROXY or ~/.docker/config.json Connections made during build (e.g. RUN Dockerfile instructions)
docker build "containers" --build-arg XX_PROXY or ~/.docker/config.json Connections made by containers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants