Docker-in-Docker in Gitlab Runners
Tony Wooster

Kamil, GitLab CI/CD Lead here. Thanks for this blog post.

Technically what are you describing is not docker-in-docker as you use host docker.sock approach that is outlined and proposed by It is in most cases the best one that you can use as it is the fastest one. All subsequent builds can use docker layer caching due to shared docker engine. However, it is susceptible to the problems that you outlined: name clashing of Docker builds, left-over containers, etc. Technically, today, neither `docker.sock` nor `docker:dind` are secure. Using either of those you can exit the container separation and do harm to the host system, the one running GitLab Runner and for example steal secrets. The current secure way is to use docker-machine approach to create ephemeral machines at cost of increased infrastructure cost.

Since the currently proposed approach, and most commonly used, that we describe in our documentation are not exactly the best, we thought about making Docker build workflow more integrated by proposing this concept: You still have the performance of `docker.sock` approach, but you get proper security with container separation and proper resource cleanup. It is not yet scheduled as of today, but anyone interested can up-vote it. It will make clear to us that this feature should be implemented.