dockerd, containerd and runc

While Docker was originally a monolithic application, it has evolved into a modular system where containerd serves as the core industry-standard container runtime responsible for managing the complete lifecycle of containers.

Architecture of Docker

Docker follows a client-server architecture. The main components interact to build, run, and distribute containers:

• Docker Client: The primary way users interact with Docker. When you run commands like docker run, the client sends them to the Docker Daemon via a REST API.
• Docker Daemon (dockerd): A background process that manages Docker objects such as images, containers, networks, and volumes. It receives requests from the client and handles the high-level logic.
• containerd: When the daemon needs to run a container, it hands off the request to containerd. Containerd handles low-level operations like image pulling, storage management, and container execution.
• runc: This is the lowest-level component. Containerd uses runc to interface directly with the Linux kernel (using features like namespaces and cgroups) to create the actual isolated container process.
• Docker Registry: A storage system for Docker images, such as the official Docker Hub. The daemon pulls images from the registry when they aren't available locally.

Workflow Example

When you execute docker run:

1. The Client sends the command to dockerd.
2. dockerd pulls the image from the Registry if it's not local.
3. dockerd instructs containerd to prepare the container environment.
4. containerd uses runc to start the container on the host operating system.