Container Fundamentals

Containers package an application with its dependencies into an isolated unit that runs consistently across environments. They use OS-level virtualization — namespaces and cgroups on Linux — to provide process isolation without the overhead of full virtual machines.

itVirtualization, containers, and orchestration

Don't Panic — Container Fundamentals

A container is not a small virtual machine. It is an ordinary Linux process that the kernel has been persuaded to lie to about what exists.

Namespaces decide what that process is allowed to perceive — which other processes, which filesystems, which network interfaces, which hostname.

Cgroups, short for control groups, decide how much CPU and memory it may consume. Nothing is emulated: the kernel is the host's, shared with every other container on the machine.

That single fact settles most of the questions people arrive with. Why containers start faster than virtual machines: nothing boots. Why one host holds so many more: no guest operating system each. And why the two are not interchangeable as security boundaries — a kernel bug or one careless flag undoes this kind of isolation, while a virtual machine's boundary is drawn somewhere harder to erase.

Four nouns are worth keeping apart, because most early confusion lives in the gaps between them. An image is a read-only bundle: every file the program needs, plus the command that starts it. A registry hands images out. A runtime unpacks one and starts the process named in it. A container is that running process with its restricted view.

One image yields many containers, each with a writable layer that vanishes with it. Anything meant to survive goes into a volume, on purpose rather than by luck.

Get identity right early. A digest names exact content, so changing one byte makes it a different digest, whereas a tag is a movable label — 2.4 may point elsewhere next month and latest certainly will. Pin anything that matters to a digest, and never put a secret in an image, since deleting it in a later build step does not remove it from the earlier layer.

The surprise most people meet in production is signals. A container's main process runs as PID 1, and the kernel delivers a signal to PID 1 only if that process installed a handler for it. An application that never handles SIGTERM — the polite request to shut down — therefore never receives one.

The runtime waits out the grace period, sends SIGKILL, which cannot be caught, and every deploy quietly severs requests still in flight while looking like a normal restart on every dashboard. Install a handler, or run a minimal init program as PID 1. That is what "a process with a restricted view" costs the moment it is forgotten.

One more, about where security attention goes. A scanner counts known vulnerabilities in packages the running process largely never touches, and that count is visible, comparable and satisfying to reduce, so it absorbs the budget. The things that genuinely set the blast radius carry no score: a mounted runtime socket, a privilege added in a hurry, a writable host path, a credential with more reach than the job needs. Counting those is far shorter work and a much better predictor of what happens after one application is compromised.

Start with the Intro for the model whole. Commands and the hardening baseline are on the Cheatsheet. Field Notes explains what a minimal base image costs at three in the morning.

Don't Panic — Container Fundamentals

Relevant careers