Docker's Architecture: Built from Quirky Compromises

A developer building a container runtime discovered why Docker’s design seems bizarre. Containers aren’t a discrete Linux feature but rather five separate kernel systems—namespaces, cgroups, networking layers—bundled together. They’re fundamentally restricted processes, traceable in /proc like any other running program.

Docker images are simply filesystem directories. The runtime downloads them and uses chroot to swap the process’s root directory, a straightforward but elegant mechanism powering the entire image abstraction.

Go presented unexpected engineering challenges for runc, Docker’s container runtime. Go’s inherent multithreading conflicts with the single-threaded requirements of critical Linux syscalls, necessitating a C module that runs before Go’s runtime initializes. Go’s lack of a true fork() primitive forced developers to work around it by re-executing the runtime with special markers. Root access requirements for kernel APIs create fundamental security constraints; rootless implementations counter this by rebuilding entire networking stacks in userspace.