Pushing Environment Variables to all Docker Containers

[mrwiora]

Hi @ALL,

I'm currently working with Docker behind a HTTP Proxy.
It's great to have the option, to provide a HTTP Proxy to the Service by default. This is in case of CentOS/RedHat the File /etc/systemd/system/docker.service.d/http-proxy.conf with content:

[Service]
Environment="http_proxy=192.168.34.99:3128" "https_proxy=192.168.34.99:3128"

For Build I have the Option to provide the Proxy using the BUILD Commands

ENV http_proxy 192.168.34.99:3128
ENV https_proxy 192.168.34.99:3128

works great!

What did not work great for me, was providing Environment variables to all following Docker containers. This would be not only useful for setting Proxy Configuration...

So I would not have to run each container with an -e parameter (like "-e http_proxy=192.168.34.99:3128") but rather have this configured in a file like /etc/dockercontainerdefault.conf

Tell me if I just missed an existing configuration option.

[cpuguy83]

I think it is indeed interesting to be able to provide a default configuration for containers (and there may already be a few open issues on this).

This could also be accomplished by building your own images with the HTTP_PROXY built in.

[duglin]

indeed. We could, pretty easily, add a new property to .docker/config.json that allowed you to specify default 'docker create' env vars, or options in general.

[mrwiora]

puh.... I did not miss anything. Actually I would very appreciate this feature :)

[duglin]

LOL yea I guess you would have preferred: silly @mwiora, we already support it, just use .... :-)

[mrwiora]

oh no :D okay..... I try to find something.....

Update:
according to https://github.com/docker/docker/blob/master/cliconfig/config.go there is no environment variable section defined, is it?

do you have a sample of such an .docker/config.json?

I actually found a bug on http://docs.master.dockerproject.org/reference/commandline/cli/ - the provided json sample is malformed in line 2

[duglin]

We could extend the config file to include "createOptions" - e.g.:

{
    "auths": {
        ...
        }
    },
    "HttpHeaders": {
        "foo": "bar"
    },
    "createOptions": {
        "memory": "40M",
        "envVars": {
            "httpProxy": "..."
        }
    }
}

Seems it could be really handy for people where the options are needed a lot. For example, we've noticed that in some envs we need to specify a minimum of 40M for memory - this could save a lot of typing for people.

@cpuguy83 @tiborvass thoughts?

[mrwiora]

1+

[tiborvass]

I don't think this should be in the client config, since this is too specific IMO.

One solution for this issue is (excuse my bash):

$ cat ~/.bashrc
...
function docker() {
  local extra="-e HTTP_PROXY=1.2.3.4"
  if [ "$1" == "run" -o "$1" == "create" ]; then
    c="$1"
    shift
    $(which docker) $c $extra $*
  else
    $(which docker) $*
  fi
}
$ docker run --rm ubuntu env

The reason I don't like this or the client config solution is because it's changing the client when in fact what I think you want is to have a template that's applied to your builds. There can be interesting ideas in that direction too. However, for right now, I suggest you put the above in your bashrc.

My 2¢..

[mrwiora]

Initially I thought about a central configuration, since when multiple people are operating with an huge docker server, it would be great to have this configuration in a centralized position.
Furthermore the person who's installing the docker service as an centralized resource, would be able to configure this for all following docker containers.

Both .bash_rc and .docker/config.json are user-specific configurations.

[tiborvass]

@mwiora if there is tight control by the admins even on the kind of base images people can use, admins could provide images with HTTP_PROXY builtin (either as an ENV or as an ARG), not ideal but would solve the problem of centralization.

[mrwiora]

good point - thanks for sharing that thought. Unfortunately this option is very unflexible in case (especially in my) that something happens to the proxy and no_proxy values. Therefore I was looking for a more flexible way.

[duglin]

For env vars that can be hardcoded into images, I agree that build ENV is probably the best option.

I tend to look at this as a UX issue. Irrespective of how the end user got into their state, if they find themselves in the situation where they are typing the same -e or -m type of options on all of their docker run/create commands then it might be worth considering a way to make their life easier. Much in the same way you can specify the "inspect" format in the config file (instead of being forced to do it on each cmd line), it seems reasonable to think about some help here. But UX stuff is always subjective.

[LK4D4]

There are build-args now. I think it's enough for most use-cases.

[loganmzz]

Rebuilding all Docker Hub/Store images doesn't seem a valuable solution for me ... neither using a bash trick. There are just workaround for a very useful feature ...

Furthermore, it forces to add these settings to all generated images, which prevents it to be shared with other people ...

[ereOn]

Almost 2 years later and that issue is still not solved. Build args are not a solution.

[thaJeztah]

Docker 17.07 and up allow you to configure default proxy environment variables in the cli configuration file (~/.docker/config.json); see docker/cli#93

Setting that configuration will automatically apply the *_proxy environment variables as build args (during docker build`), and to be set on containers that are started from the CLI