How Docker Works: Under the Hood of Containerization

Traditional Virtual Machines (VMs) run on a Hypervisor (like ESXi, Hyper-V, or KVM) and require a full Guest Operating System. This incurs massive overhead: slow startup times, large disk footprints, and significant memory consumption since each VM needs its own kernel, memory management, and system libraries.

Docker containers, on the other hand, perform virtualization at the operating system level. They share the host kernel and isolate processes using built-in Linux kernel primitives. Because there is no guest kernel running, container processes start in milliseconds and run at near-native hardware speed.

Docker uses Namespaces to wrap resources into an isolated system view, preventing a container process from seeing or interacting with other host processes. The key namespaces are:

- PID (Process ID): Isolates process tree. Inside the container, the primary process runs as PID 1, completely unaware of other processes on the host.

- NET (Network): Provides isolated network interfaces, routing tables, and port spaces. Each container gets its own virtual ethernet interface (veth).

- MNT (Mount): Isolates the filesystem mount points. The container processes only see the container filesystem, pivot_rooted to prevent path traversal.

- IPC (Interprocess Communication): Restricts access to shared memory segments, semaphores, and message queues.

- UTS (Unix Timesharing): Isolates hostname and domain name settings.

While namespaces isolate what a process can *see*, Control Groups (cgroups) restrict what a process can *consume*. Cgroups prevent a single container from starving the host or other containers of resources.

Cgroups control hardware resources like CPU shares and limits, physical memory boundaries (triggering OOM killer if exceeded), block I/O bandwidth, and process creation counts (preventing fork-bomb attacks).

Docker images are built as a stack of read-only layers. When a container runs, Docker attaches a thin, writable layer on top. This is achieved via Union File Systems, primarily OverlayFS (overlay2).

OverlayFS overlays directories on a single host and presents them as a unified folder tree. The key layers are:

- LowerDir: The read-only directories containing the base image libraries and binaries.

- UpperDir: The writable directory capturing modifications (additions and updates) made inside the container.

- MergedDir: The virtual directory visible inside the container representing the merged state of LowerDir and UpperDir.

If a container process writes to a file from the LowerDir, OverlayFS copies the file to the UpperDir before executing edits. This is called Copy-on-Write (CoW), preserving the base image layer unchanged.