Using Docker-in-Docker for your CI or testing environment? Think twice.
The primary purpose of Docker-in-Docker was to help with the development of Docker itself. Many people use it to run CI (e.g. with Jenkins), which seems fine at first, but they run into many “interesting” problems that can be avoided by bind-mounting the Docker socket into your Jenkins container instead.
Let’s see what this means. If you want the short solution without the details, just scroll to the bottom of this article. ☺
---------------
And the simplest way is to just expose the Docker socket to your CI container, by bind-mounting it with the -v flag.
Simply put, when you start your CI container (Jenkins or other), instead of hacking something together with Docker-in-Docker, start it with:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
Now this container will have access to the Docker socket, and will therefore be able to start containers. Except that instead of starting “child” containers, it will start “sibling” containers.
Try it out, using the docker official image (which contains the Docker binary):
docker run -v /var/run/docker.sock:/var/run/docker.sock \
-ti docker
This looks like Docker-in-Docker, feels like Docker-in-Docker, but it’s not Docker-in-Docker: when this container will create more containers, those containers will be created in the top-level Docker. You will not experience nesting side effects, and the build cache will be shared across multiple invocations.
November 23, 2016 at 9:52:41 AM UTC
- permalink
-
-
https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/