Added DOCKER_DAEMON_ARGS environment variable support

[Jack12816]

This image is really awesome! But it lacks the support for an environment variable based docker daemon configuration. It would be really helpful to support both approaches, the entrypoint arguments and an additional DOCKER_DAEMON_ARGS variable.

This comes in very handy for a CI build, when an user can't change the way how a dependent service is started, except of passing environment variables.

Moreover it's documented that way on dind itself.

[tianon]

I'm not sure I understand the use case for this, can you elaborate?

When I need daemon arguments on this image, I run it like docker run ... docker:1.11-dind --storage-driver aufs --etc, so IMO this would be the responsibility of a higher-level tool which relies on environment variables to supply to docker run directly.

[Jack12816]

Sure. My usecase is Gitlab CI where I want to build, test and deploy the
production docker image to the production registry.

Gitlab CI is able to run the defined jobs on docker containers (via
gitlab-ci-multi-runner). It possible to define "services" which are started and
linked to your build container. In my case the build container is
docker:latest and docker:dind as a service. So I'm able to access the
docker daemon inside the build container. Everything is fine. But I can't
manipulate the way how gitlab-ci-multi-runner is starting the dependent
service. The only opportunity is to pass extra environment variables. With the
help of the documented DOCKER_DAEMON_ARGS variable, I'm able to add an
registry mirror (via --registry-mirror=http://mymirror:6000 to the docker
daemon, which would save internet traffic and build time.

I think the additional DOCKER_DAEMON_ARGS variable does not hurt anyone when
it is supported. To the contrary it comes in very handy to use cases like mine.

[yosifkit]

This sounds like a failing of the docker runner in the gitlab-ci-multi-runner module. The services list should really be a similar definition to the top layer where you can define things like image: and script: and not just a list of strings that are images to run.

I would probably work around it by just using the shell runner since the yaml syntax is limited, but there would be extra concerns like the need to clean up the containers at the end or on error that the docker runner probably just does for you.

On a side note, I would probably not use the docker runner for dind or any other privileged requiring containers since the documentation seems to imply that is it set on the runner so your container and all services run by it would be privileged, which is a security issue.

See also, https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/

[Jack12816]

The services list should really be a similar definition to the top layer where you can define things like image: and script: and not just a list of strings that are images to run.

I agree on your point. Unfortunately it is a far more hard thing to request and get this feature on gitlab-ci-multi-runner than these 2 lines of code to support the environment variable. (But I will create an issue on gitlab-ci-multi-runner to target this)

I would probably work around it by just using the shell runner since the yaml syntax is limited, but there would be extra concerns like the need to clean up the containers at the end or on error that the docker runner probably just does for you.

The shell runner is not an option for me due to parallel builds and the TCP port pollution on the host machine while testing the resulting docker images.

On a side note, I would probably not use the docker runner for dind or any other privileged requiring containers since the documentation seems to imply that is it set on the runner so your container and all services run by it would be privileged, which is a security issue.

I am aware of the security concerns. The gitlab instance is private and the runner/machine restricted to an project/team.

See also, https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/

I don't like passing the host docker daemon socket inside the container, because this volume needs to be defined on the .gitlab-ci.yml inside the project. So the code/projects builds up dependencies to its CI system (also a non generic approach when the absolute location of the socket changes on different systems). The environment variable can be injected via the gitlab-ci-multi-runner. (See docs, environment) With the --registry-mirror=http://mymirror:6000 option the inner docker daemon does not suffer from data corruption and it is possible to save traffic on the internet when the local registry mirror is on the same machine/near on the local network. Without this option the CI build is also able to complete successfully with a longer runtime/more traffic. This is really important to me.

---

For others with the same needs, I created a patched docker:dind image.

See: https://hub.docker.com/r/jack12816/docker/

It just uses docker:dind as base and replaces the entrypoint as proposed in this PR.