Snapshot of jpetazzo/dind: 2.5k★, Shell. Docker in Docker
Snapshot summary built from the project's own GitHub metadata — there's no written TopGit review yet. The page will update automatically when a full review is published.
WHY NO REVIEW YET
TopGit writes full reviews for the most-starred, most-requested repositories. This page is a snapshot until then — see the READ ME tab for the original README in full.
There is only one requirement: your Docker version should support the
--privileged flag.
A word of warning
If you came here because you would like to run a testing system like
Jenkins in a container, and want that container to spin up more containers,
then please read this blog post
first. Thank you!
Another word of warning
This work is now obsolete, thanks to the combined efforts
of some amazing people like @jfrazelle and @tianon, who also
are black belts in the art of putting IKEA furniture together.
If you want to run Docker-in-Docker today, all you need to do is:
docker run --privileged -d docker:dind
... And that's it; you get Docker running in Docker, thanks to
the official Docker image, in its "Docker-in-Docker" flavor.
You can then connect to this Docker instance by starting
another Docker container linking to the first one (which is
a pretty amazing thing to do).
For more details about the docker:dind official image,
explanations about how to use it, customize it to use
specific storage drivers, and other tidbits of useful
knowledge, check its documentation on the Docker Hub.
If you read past this paragraph ...
... Then you're probably an archaeologist, a masochist, or both.
Seriously, though: the information below is here mostly
for historical value, or if you want to understand how those
things work under the hood.
You've been warned!
Quickstart
Build the image:
docker build -t dind .
Run Docker-in-Docker and get a shell where you can play, and docker daemon logs
to stdout:
docker run --privileged -t -i dind
Run Docker-in-Docker and get a shell where you can play, but docker daemon logs
into /var/log/docker.log:
docker run --privileged -t -i -e LOG=file dind
Run Docker-in-Docker and expose the inside Docker to the outside world:
docker run --privileged -d -p 4444 -e PORT=4444 dind
Note: when started with the PORT environment variable, the image will just
the Docker daemon and expose it over said port. When started without the
PORT environment variable, the image will run the Docker daemon in the
background and execute a shell for you to play.
Daemon configuration
You can use the DOCKER_DAEMON_ARGS environment variable to configure the
docker daemon with any extra options:
docker run --privileged -d -e DOCKER_DAEMON_ARGS="-D" dind
It didn't work!
If you get a weird permission message, check the output of dmesg: it could
be caused by AppArmor. In that case, try again, adding an extra flag to
kick AppArmor out of the equation:
docker run --privileged --lxc-conf="lxc.aa_profile=unconfined" -t -i dind
If you get the warning:
WARNING: the 'devices' cgroup should be in its own hierarchy.
When starting up dind, you can get around this by shutting down docker and running:
If the unmount fails, you can find out the proper mount-point with:
$ cat /proc/mounts | grep cgroup
How It Works
The main trick is to have the --privileged flag. Then, there are a few things
to care about:
cgroups pseudo-filesystems have to be mounted, and they have to be mounted
with the same hierarchies than the parent environment; this is done by a
wrapper script, which is setup to run by default;
/var/lib/docker cannot be on AUFS, so we make it a volume.
That's it.
Important Warning About Disk Usage
Since AUFS cannot use an AUFS mount as a branch, it means that we have to
use a volume. Therefore, all inner Docker data (images, containers, etc.)
will be in the volume. Remember: volumes are not cleaned up when you
docker rm, so if you wonder where did your disk space go after nesting
10 Dockers within each other, look no further :-)
Which Version Of Docker Does It Run?
Outside: it will use your installed version.
Inside: the Dockerfile will retrieve the latest docker binary from
https://get.docker.io/; so if you want to include your own docker
build, you will have to edit it. If you want to always use your local
version, you could change the ADD line to be e.g.:
ADD /usr/bin/docker /usr/local/bin/docker
Can I Run Docker-in-Docker-in-Docker?
Yes. Note, however, that there seems to be a weird FD leakage issue.
To work around it, the wrapdocker script carefully closes all the
file descriptors inherited from the parent Docker and lxc-start
(except stdio). I'm mentioning this in case you were relying on
those inherited file descriptors, or if you're trying to repeat
the experiment at home.
kojiromike/inception is
a wrapper script that uses dind to nest Docker to arbitrary depth.
Also, when you will be exiting a nested Docker, this will happen:
TopGit's last sync did not record any GitHub topics for jpetazzo/dind. GitHub topics appear in the right sidebar of a repository page; that's the authoritative place to check.
How active is development on jpetazzo/dind?
The most recent commit recorded on jpetazzo/dind was 8.1 years ago, based on the GitHub push timestamp. The repository has 556 forks — one of the better signals of community interest.
How many stars does jpetazzo/dind have?
jpetazzo/dind has 2.5k GitHub stars — refresh the page for the live number, or check github.com/jpetazzo/dind. TopGit mirrors GitHub's count but does not claim minute-by-minute accuracy.
What language is jpetazzo/dind written in?
jpetazzo/dind is written primarily in Shell. GitHub's language field is based on the largest share of bytes in the default branch.
Where do I read more about jpetazzo/dind?
This TopGit page is a snapshot — the READ ME tab shows the project's own README content (links stripped, images preserved). The GitHub repository at github.com/jpetazzo/dind is the definitive source.
Read full README in the tab above.
Want a second opinion on dind?
Ask an AI that can read this page — one click and you get its take on dind.