Docker is weird

Embarking on a personal quest to build a container runtime from scratch, the author discovers that Docker, despite its ubiquitous presence, operates on several 'weird' and often misunderstood principles. This deep dive demystifies the magic, revealing the raw mechanics beneath the abstraction.

• Containers Aren't Virtual Machines: Unlike VMs, containers are merely isolated processes, leveraging existing kernel features rather than emulating hardware. They are visible as regular processes in /proc.
• The Linux Trench Coat: The concept of a 'container' doesn't exist as a single Linux feature; instead, it's a clever orchestration of several primitives: namespaces for isolation (process, network, mount, etc.), cgroups for resource limiting, and network trickery for connectivity.
• Images Are Just Folders: Docker images are essentially packaged directories. When run, Docker uses chroot or pivot_root to make this directory the container's new root filesystem.
• Go's Conundrums for Runtimes: The article posits that Go, the language powering Docker's runc, has design choices (like a natively multi-threaded runtime and lack of true fork) that complicate its use for container orchestration, necessitating custom C modules and workarounds.
• Root Privileges (Historically): Many Linux kernel APIs crucial for container runtimes traditionally required root access, explaining why the Docker daemon typically runs as root. While rootless options now exist, they often involve reimplementing networking in userspace.

Ultimately, the author concludes that tackling the challenge of reimplementing a widely used tool is an incredibly effective way to deepen one's understanding of its underlying mechanisms and design trade-offs.