when to use docker:dind when setting up a ci/cd system

Question

I'm just new to gitlab, new to docker. I am very familiar with CI/CD best practices. I'm trying to understand / identify specific use cases where using docker:dind would benefit me and my team.

I've been reading this article: https://www.caktusgroup.com/blog/2020/02/25/docker-image/

In our environment, we have HP blades set up (dev, staging, production), each running docker daemons.

One use case that I can think of is if a developer wants to try something locally on his / her desktop... that's running a different version of Docker than on our servers. They can maybe use a docker:dind image locally but specify a version that matches our servers? Not sure.

Can someone help me come up with some practical examples of when / why this is useful? Thanks.

Answer 1

For basically all routine use, including CI systems you need to configure yourself, bind-mount the host's Docker socket into the environment and use that. You shouldn't use Docker-in-Docker at all in most cases.

The canonical reference for this (still, 5 years later) is Jérôme Petazzoni's Using Docker-in-Docker for your CI or testing environment? Think twice. I would suggest using Docker-in-Docker is appropriate:

1. If you're actively developing on Docker itself (you've checked out https://github.com/moby/moby and are editing the source) and you need a sandbox to run your modified daemon; or
2. If you have a very strong understanding of Docker concepts, and neither you nor anyone you work with will be confused by images being in "the wrong" Docker daemon or bind mounts coming from the wrong "host system"; or
3. If you have a CI system or other tool that very specifically supports it as a zero-configuration option.

There are a couple of "canned" solutions that break most of the normal rules, but still work well. The most prominent example I can think of here is kind ("Kube.netes in Docker"), which breaks both the "don't run Docker-in-Docker" and the "one process per container" rule, to run an entire Kube.netes cluster in a single Docker container. It's really useful, but it also hides almost all of the details about "where are my containers" from you. This is the sort of "zero-configuration option" I'm thinking of.

I would not worry about one developer having a slightly different version of Docker than your CI or production systems. I've only run into one version incompatibility with Docker proper. As of right this instant potentially the "classic" vs. BuildKit build systems could do something different, but I wouldn't introduce a very complex alternate setup to guard against this.