When you type docker run, you're not just executing a simple command. You're kicking off a conversation. Docker operates on a client-server architecture. Your terminal, running the Docker command-line interface (CLI), is the client. It sends instructions to a background service, the Docker daemon, which is the server.

This communication isn't magic; it happens over a REST API, typically through a local Unix socket. The CLI packages your command into an API request, sends it to the daemon, and the daemon gets to work. This design is powerful because your client doesn't have to be on the same machine as the daemon. You can control a remote Docker host from your local terminal, as long as you have the right permissions and network access.

The Docker daemon, or dockerd, is the persistent background process that manages Docker objects like images, containers, networks, and volumes. It's the brain of the operation, listening for API requests and handling the entire container lifecycle.

In the early days, dockerd did everything. Over time, its responsibilities were broken down into smaller, specialized components to create a more modular and robust system. Today, dockerd doesn't directly run containers. Instead, it delegates.

When a request to run a container comes in, dockerd hands it off to another process: containerd. This component is a container supervisor. Its sole job is to manage the complete lifecycle of containers on a host: starting them, stopping them, pausing, and handling networking and storage. It pulls the image, creates the necessary resources, and then passes the final step to another tool.

The final handoff goes to runc. This is a lightweight, low-level tool that does one thing: it runs containers. runc is the reference implementation of the Open Container Initiative (OCI) specification, a set of standards for container formats and runtimes. containerd tells runc what to do, and runc interacts with the operating system's kernel to create and run the isolated process we call a container. This separation of concerns—daemon for API, containerd for lifecycle, runc for execution—makes the whole system more flexible and maintainable.

So how does runc actually isolate a container? It leverages features built directly into the host operating system's kernel, primarily namespaces and control groups.

Namespaces are the key to isolation. They work by wrapping a set of system resources and presenting them to a process to make it look like it has its own dedicated instance of that resource. For a container, Docker uses several types of namespaces:

• PID (Process ID): Isolates the process tree. Inside the container, its main process is PID 1. It can't see or signal processes outside its namespace.
• NET (Network): Provides an isolated network stack. Each container gets its own private network interfaces, IP address, and routing tables.
• MNT (Mount): Isolates filesystem mount points. A container has its own root filesystem and cannot access the host's filesystem, except for explicitly mounted volumes.
• UTS (UNIX Timesharing System): Isolates the hostname and domain name. This allows each container to have its own unique hostname.
• IPC (Inter-Process Communication): Isolates resources like message queues and shared memory, preventing processes in different containers from communicating directly.

While namespaces provide isolation, they don't limit resource consumption. A container could still monopolize all the host's CPU or memory. That's where control groups, or cgroups, come in.

Cgroups are a kernel feature that allows you to allocate and limit the hardware resources available to a group of processes. Docker uses cgroups to enforce the resource constraints you can specify with docker run, such as --cpus or --memory. This ensures that no single container can starve the host or other containers of necessary resources.

The final piece of the puzzle is how Docker handles files. Docker images are made of multiple, read-only layers. When you run a container, Docker adds a thin, writable layer on top of the image layers. This entire stack is managed by a storage driver that uses a Union File System.

A Union File System can merge several directories, known as branches, into a single, cohesive view. When you modify a file in a running container, you're not changing the underlying image. Instead, the change is written to the top writable layer using a copy-on-write strategy. The original file in the read-only image layer is hidden, and the new version exists only in the container's layer.

This approach is incredibly efficient. It allows hundreds of containers based on the same image to run concurrently, sharing the same read-only layers and only storing the unique changes for each container. This saves a tremendous amount of disk space and makes starting containers nearly instantaneous.

This architecture, from the client-server model down to the kernel-level features, is what makes Docker a powerful and efficient platform for running applications.