The core mechanism behind Docker in Docker (DinD) involves spawning a fully independent Docker daemon inside an active container. The host container thus operates its own isolated Docker runtime, capable of building, shipping, and orchestrating child containers. While powerful, this pattern introduces extra resuorce consumption, potential security risks from privileged access, and added operational complexity.

Setting Up a Self-Contained Docker Daemon

Start by obtaining the official DinD image:

docker pull docker:dind

Launch the instance with elevated permissions and a recognizable name:

docker run --privileged -d --name docker-host docker:dind

The --privileged flag grants the inner daemon necessary hardware access. Confirm the daemon is running with docker logs docker-host.

Operating Inside the Nested Engine

Attach to the running instance and open a shell:

docker exec -it docker-host sh

Inside this environment, the Docker CLI interacts with the daemon operating within the same container. Verify connectivity by listing active processes:

docker ps

An empty table is expected because no child workloads have been defined yet.

Launching Workloads in the Inner Engine

Create a detached container from an Nginx image inside the nested runtime:

docker run -d --label app=frontend nginx

Inspect the newly created container:

docker ps

The output now includes the frontend workload. You can further interact with it using standard Docker commands, for example stopping it with docker stop $(docker ps -q --filter label=app=frontend).

Tearing Down Resources

Before exiting the inner shell, remove the nested workload and any related artifacts:

docker rm -f $(docker ps -aq)

Leave the shell:

exit

Finally, remove the DinD container from the host:

docker rm -f docker-host