How Containers Work
How containers work: Linux namespaces, cgroups, and layered filesystems explained — what Docker actually does and how containers differ from virtual machines.
Containers package an application with its libraries and configuration into an isolated process that runs directly on the host kernel. Unlike virtual machines, which emulate entire computers, containers share the operating system kernel while using namespaces and cgroups to isolate files, networks, and resources.
Namespaces, cgroups, and layered filesystems
Three Linux kernel features do the real work. Namespaces give each container its own view of the system: a PID namespace with its own process tree, a mount namespace with its own filesystem root, and network and user namespaces isolating interfaces and identities. Control groups, or cgroups, cap and meter resources — CPU shares, memory limits, block I/O — so one container cannot starve its neighbors, and the kernel's out-of-memory killer targets the offending group first. The filesystem comes from stacked copy-on-write layers: each build instruction adds a read-only layer, and the running container gets a thin writable top layer, so a hundred containers share one base image cheaply. This layering works much like Git version control, where commits stack as deltas over shared history.
Containers versus virtual machines
Virtual machines emulate hardware: each guest carries a full kernel and virtual devices under a hypervisor, costing gigabytes of memory and seconds of boot time, but providing strong hardware-level isolation and the freedom to run different operating systems. Containers share the host kernel, so they start in milliseconds and add negligible overhead — but a kernel vulnerability can escape them, and they can only run workloads matching the host kernel. The tradeoff is density and speed against isolation depth, which is why multi-tenant clouds often stack both, running containers inside virtual machines. The ecosystem is tied together by content addressing: image layers are identified by cryptographic digests, the same idea as hash functions in content-addressed storage.
Images, registries, and orchestration
A container image is a manifest plus layers pushed to a registry; pulling resolves the manifest, fetches missing layers by digest, and assembles the bundle locally. Build files declare images reproducibly, though layer caching means instruction order matters for build speed. Multi-stage builds keep final images small by discarding compilers and intermediate artifacts, shipping only the runtime and the application. At runtime a daemon unpacks images and supervises processes, and health checks with restart policies turn crash loops into self-healing services. Namespaces and cgroups are the mechanism; everything above them is convenience. Orchestrators schedule containers across machines, restart failures, and wire up networking and storage — and like garbage collection for memory, they continuously reap dead containers and unused images so hosts do not fill with debris.
Tags
containers devops docker linux