Understanding Docker Architecture - Daemon, Client, and Container Runtime

Overview and What You Will Learn

When you type docker run nginx and a container appears in seconds, it looks like magic. It is not. That single command travels through four distinct software layers before a container process starts on your machine. In this guide you will learn exactly what those four layers are, what each one does, and why Docker was designed this way. You will also understand the Docker socket — the most important and most dangerous file on any Docker host — and what happens if it is exposed incorrectly.

By the end of this guide you will be able to explain how Docker works at the architecture level, understand why Docker Desktop behaves differently from Docker Engine on Linux, and know how to configure the Docker daemon for production use.

Why This Matters in Production

At Swiggy, every EC2 instance running containers has a Docker daemon running on it. When containers fail to start, when builds mysteriously hang, or when a security team raises a concern about the Docker socket — engineers who understand the architecture can diagnose and fix these problems in minutes. Engineers who only know docker run commands are stuck waiting for someone else to help.

Understanding the Docker daemon also explains why Kubernetes deprecated Docker in version 1.24 and switched to containerd directly — a change that confused thousands of engineers who did not understand the architecture underneath.

Core Principles

Docker's architecture has four layers. Each layer has a single responsibility and communicates with the next layer through a well-defined interface.

This separation of concerns is intentional. containerd and runc are independent projects that can be used without Docker. Kubernetes uses containerd directly — skipping dockerd entirely — which is why Docker was deprecated as a Kubernetes runtime.

Detailed Step-by-Step Practical Lab

Milestone 1: Understanding the Docker Daemon

The Docker daemon (dockerd) is a background service that starts when your system boots and runs continuously. It listens for API requests and manages all Docker objects on the host.

The daemon configuration file lives at /etc/docker/daemon.json. This is where you configure production settings:

The live-restore: true setting is critical for production — it tells the daemon to keep containers running if the daemon itself is restarted or upgraded. Without it, every daemon restart kills all running containers.

Milestone 2: Understanding the Docker Socket

The Docker socket is a Unix socket file at /var/run/docker.sock. The Docker CLI sends REST API calls to the daemon through this socket. Whoever can read and write to this socket has full control over Docker — which means full control over the host.

The Docker socket is the most common Docker security vulnerability. Mounting it inside a container gives that container root access to the host:

Milestone 3: Understanding containerd and runc

containerd was split out of Docker in 2016 and donated to the CNCF. It handles the actual container lifecycle — pulling images, managing filesystem snapshots, and starting container processes. The Docker daemon talks to containerd through a gRPC socket.

runc is even simpler — it reads an OCI bundle (a filesystem and a config.json file) and creates the Linux namespaces and cgroups that isolate the container. It then executes the container process and exits immediately. runc does not run continuously — it is a one-shot binary that sets up isolation and hands off.

Milestone 4: Tracing a docker run Command End-to-End

Here is the complete sequence of what happens when you run docker run nginx:

Milestone 5: Docker Desktop vs Docker Engine

Docker Engine is the native Linux installation — the daemon runs directly on the Linux host. Docker Desktop (on macOS and Windows) runs a lightweight Linux VM and runs Docker Engine inside it. This explains several behaviours that confuse engineers:

Common Mistakes

Troubleshooting Reference

PLACEMENT PRO TIP

**Tip:** On production Linux hosts, always add `"live-restore": true` to `/etc/docker/daemon.json` before running any workloads. Without it, every Docker daemon upgrade or crash kills all running containers. With it, containers keep running while the daemon restarts — zero downtime for daemon maintenance.

REMEMBER THIS

**Remember:** The Docker socket at `/var/run/docker.sock` is functionally equivalent to root access on the host. Treat it with the same care as an SSH private key. Never mount it into untrusted containers, never expose it over TCP without TLS, and audit which processes have access to it on every production host.

COMMON MISTAKE / WARNING

**Common Mistake:** Thinking that containers are separate virtual machines. Containers are Linux processes running on the host kernel with isolation provided by namespaces and cgroups. When you run `ps aux` on the host, you can see all container processes with their real PIDs. This is why a compromised container can be a serious security risk — it is running on the same kernel as everything else on the host.

COMMON MISTAKE / WARNING

**Security:** The members of the `docker` group on a Linux host have effective root access. Running `docker run -v /:/host alpine chroot /host` gives any docker group member a root shell on the host filesystem. Never add untrusted users to the docker group. On multi-tenant servers, use rootless Docker or Podman instead, which do not require a privileged daemon.