Adding Docker Opts to entrypoint

[endzyme]

Allowing docker opts in entry point to pass arguments to the daemon via environment variables as well as CMD arguments.

[yosifkit]

I am not sure what is gained with this change. If you really want to set an environment variable with your docker options, this would be equivalent:

$ docker run --privileged --name some-docker -d docker:1.8-dind $DOCKER_OPTS
# vs, new  change:
$ docker run --privileged --name some-docker -d -e DOCKER_OPTS docker:1.8-dind

I feel like any extra flag options to the docker daemon should be explicit rather than inferred.

[endzyme]

@yosifkit thanks for the feedback - I was having trouble getting --insecure-registry to work with environment variables. Perhaps it was my method of testing. I'll go back to the drawing board if this is expected to work. Thanks again.

[endzyme]

After a quick test - I could not get --insecure-registry to take using env vars.

To reproduce:

$> docker run --name dind_run --rm -it --privileged -e DOCKER_OPTS="--insecure-registry <some_insecure_reg:port>" docker:1.12-dind

$> docker exec -it dind_run
#> docker pull <some_insecure_reg:port>/something
Error response from daemon: Get https://<...>/v1/_ping: x509: cannot validate certificate for <...> because it doesn't contain any IP SANs

The following works

$> docker run --name other_run --rm -it --privileged  docker:1.12-dind --insecure-registry <insec_reg:port>

$> docker exec -it other_run sh
#> docker pull <some_insecure_reg:port>/something

[tianon]

Right, what @yosifkit was pointing out is that DOCKER_OPTS isn't supported by this image, but really doesn't need to be since you can accomplish what it provides already in a very similar way. What's the use case for providing an environment variable versus a command?

If it's that you've got a local DOCKER_OPTS variable that you want to provide as flags to your DinD, you can do something like this:

$ docker run ... docker:dind $DOCKER_OPTS
...

(which has your local shell do the expansion instead of relying on the image to expand)

On the other hand, if the use case is docker-compose.yml, then something like this should already work:

    docker:
        image: docker:dind
        restart: always
        tty: true
        privileged: true
        command: [
            '--log-level', 'debug',
            '--storage-driver', 'overlay',
            '--cluster-store', 'consul://cluster-store:8500',
            '--cluster-advertise', 'eth0:2375',
        ]

(or any other supported YAML syntax for an array)

If you absolutely need to be able to provide an environment variable, then changing the default command to something like the following should do the trick:

$ docker run ... -e DOCKER_OPTS='...' docker:dind sh -c 'exec dockerd-entrypoint.sh $DOCKER_OPTS'
...

[endzyme]

Thanks for the info @tianon - Sorry about that confusion. So unfortunately my PR is due to a limitation on some other software I've been using mainly GitLab CI. The DSL allows you to provide "services" as dependencies to the builds (in my case DinD) but it does not allow for providing CMD args, or anything outside of Environment Variables.

[tianon]

Ahh, then you probably want to read the discussion in #12.

[endzyme]

Looks like my PR is a duplicate of #12! Sorry about that! - The conversation makes sense to me. I'll see what it might take to extend the GitLab stuff. Thanks again for the feedback!