Q: What happens internally during docker run internals execution?

The command docker run -d -p 80:80 --name web nginx is executed. The Docker CLI parses CLI flags, translates them into an OCI container creation schema, and sends a REST request over the Unix domain socket /var/run/docker.sock to the Docker daemon (dockerd).

# Simulating the CLI call using curl against dockerd Unix socket
sudo curl --unix-socket /var/run/docker.sock \
  -X POST http://localhost/v1.43/containers/create?name=web \
  -H "Content-Type: application/json" \
  -d '{"Image": "nginx", "HostConfig": {"PortBindings": {"80/tcp": [{"HostPort": "80"}]}}}'

• CLI Translation: CLI validates inputs and converts flags into JSON API payload.
• Socket Communication: dockerd receives the HTTP request over /var/run/docker.sock.

dockerd passes the container specification to containerd via gRPC. containerd checks if the requested image layers exist locally. If missing, it pulls the OCI image manifest, unpacks tarball layers into the content store, and mounts an Overlay2 union filesystem.

# Inspect the Overlay2 filesystem mounts for a running container
docker inspect web --format '{{.GraphDriver.Data.MergedDir}}'

• Lowerdir: Read-only container image layers stacked on top of each other.
• Upperdir: Read-write scratch layer storing container modifications.
• Mergeddir: Unified view of the filesystem presented inside the container.

containerd generates an OCI config.json bundle and launches a lightweight process called containerd-shim. The shim keeps container standard IO (stdin/stdout/stderr) and exit status descriptors open so the container remains running even if dockerd or containerd restarts.

# View containerd-shim processes running on the host
ps -ef | grep containerd-shim

• Daemonless Containers: Decouples the lifecycle of the container from the management daemon.
• Process Adoption: Prevents zombie processes by serving as the subreaper for the container process tree.

The shim invokes runc (the reference OCI runtime). runc issues the Linux clone() and unshare() system calls with flags that create isolated kernel namespaces.

# Inspect namespaces of the container process (PID <pid>)
sudo lsns -p <pid>

• PID Namespace: Isolates process IDs; the main container process becomes PID 1 inside the container while appearing as a standard PID on the host.
• NET Namespace: Provides private network interfaces, routing tables, and firewall rules.
• MNT Namespace: Isolates filesystem mount points, executing pivot_root into the Overlay2 merged directory.
• IPC, UTS, USER Namespaces: Isolates inter-process shared memory, hostname, and UID/GID mappings.

runc creates a dedicated control group under /sys/fs/cgroup/ to enforce CPU, memory, PIDs, and I/O resource limits.

# Inspect active cgroup limits applied to the container
cat /sys/fs/cgroup/system.slice/docker-<id>.scope/memory.max

• Memory Limits: Enforces memory.max; kernel OOM killer terminates process if limits are breached.
• CPU Quotas: Configures cpu.max CFS scheduler periods to prevent container CPU starvation.
• Security Hardening: Applies default seccomp BPF syscall filters and drops Linux capabilities (e.g. CAP_SYS_ADMIN).

The Docker bridge network driver creates a virtual ethernet (veth) pair. One end is attached to the docker0 bridge on the host; the peer end is placed inside the container's NET namespace as eth0. dockerd configures host iptables PREROUTING rules to forward host port 80 to container port 80.

# Inspect Docker iptables port-forwarding rules
sudo iptables -t nat -L DOCKER -n -v

• veth Interface: Virtual wire moving Ethernet packets between host and container network namespaces.
• iptables DNAT: Translates incoming packets on host port 80 to the container IP on port 80.

Structural comparison of the key daemon and runtime components executing during docker run internals: