Why is Docker-in-Docker considered bad?



In August 2013 Jérôme Petazzoni created Docker in Docker, dind for short, this allowed Docker containers to be created inside of Docker Containers, this functionality proved very popular resulting in Jérôme's GitHub Repository receiving over a thousand stars and three hundred forks.

As of Docker 1.8, released two years later in August 2015, Docker in Docker is directly supported by Docker out of the box. However, the use of Docker in Docker comes with a warning, seemingly related to Jérôme's Post: Using Docker-in-Docker for your CI or testing environment? Think twice. which focuses on the reasons why Docker in Docker is not a great choice for Continuous Integration.

Why is it considered bad to use Docker in Docker? Is it simply a case for avoiding Turtles all the way down? or performance considerations?

Turtles all the way down!

Richard Slater

Posted 2017-03-26T18:36:07.073

Reputation: 8 732

I'm not familiar with docker other than having read about it. But thinking about it, it feel like you have the host OS on the hardware, that host loads a container, then that container loads another one. Seems like a lot of overhead given that the idea is to deploy an image. A picture of a picture of a picture ... Also interested in actual answers to this q.No Refunds No Returns 2017-03-26T21:03:27.813

You are linking the answer to your question... or am I missing something?AnoE 2018-04-05T19:05:38.967



Continuous Integration Concerns

In short: Docker in Docker (dind) doesn't handle concurrency well.

The reason why you shouldn't use dind for CI is because Docker was designed to have exclusive access to the directory it uses for storage (normally /var/lib/docker). Dind doesn't respect this as all child processes use this directory concurrently. Every time you rebuild (from CI for example), anything related to your app in this directory could get wiped out and forced to start from zero. How would your users like it if they entered their payment details, clicked "Purchase", and suddenly found themselves back on the login screen as if they'd never done anything? That's just not good UX. Two rebuilds occur at once? That's really going to end badly for everyone involved (including your data integrity).

Other Concerns

From the link the OP posted, security concerns arise as the system will try to apply security policies in a very "CSS-like" fashion where a lower container could have access to an outer container's resources unless explicitly prohibited. Remember when you could access web server resources by doing something like "mywebsite.com/../another_folder/private_resource.txt"? Also, sometimes filesystems just don't play well with each other when they're nested in this way.

The Fix

Thankfully, the blog post in the OP has a good solution for the issue. Unless your needs are not met by "build/run/push Docker containers from your CI system itself running on Docker", you can use -v mode (add a data volume to your container) on the Docker socket (usually /var/run/docker.sock:/var/run/docker.sock) to allow the kind of access you need to the "shared" data volume. These containers will be started alongside the parent, instead of underneath, forcing synchronous IO. Now you have the same thing (almost) as dind but without the downsides that come with Docker not being build for concurrency.

Reference (from OP): Using Docker-in-Docker for your CI or testing environment? Think twice.

Peter G

Posted 2017-03-26T18:36:07.073

Reputation: 1 012

Here's one example of described approach (dood) for Jenkins, yet several issues reported while using it https://hub.docker.com/r/psharkey/jenkins-dood/

rombob 2017-03-27T23:26:20.430

From this explanation I still can't really tell if dind should be avoided in my case... My build agent runs in a docker container, and does the following: 1. Checkout repo. 2. Start container & mount repo. 3. Run some build-/test script inside container. Per agent, there is ever only one 'dind'-container running. Are there still issues with dind in this use-case?helmesjo 2017-11-12T11:41:41.377