Containers, Illustrated

A container is not a small VM. The runtime starts a host process with namespaces, cgroup membership, a root filesystem, and configured security restrictions.

Boundary: The exact setup belongs to the runtime and host configuration. Namespaces and cgroups are Linux mechanisms; their security properties depend on configuration.

Failure state: The process now sees the host’s corresponding namespace. Isolation is not an all-or-nothing property supplied by the image.

The process can have distinct PID, mount, network, UTS, and IPC views. The host still schedules it. A namespace alters a selected view; it does not create a second kernel.

Boundary: User namespaces and their mappings are optional and vary by runtime configuration. Namespaces alone are not a complete security boundary.

Failure state: With host networking selected, the process shares the host network namespace; localhost and port binding behave differently.

The kernel charges work to the process’s cgroup. Limits can bound use; without a configured memory limit, a container is not magically assigned a fixed memory budget.

Boundary: Controllers and available limits depend on host cgroup configuration. An OOM event is a kernel decision, not a Docker retry policy.

Failure state: The container still exists, but this cgroup has no configured memory ceiling from the container runtime.

Build cache reuses a step when its instruction and relevant inputs still match. Copying package files before source files lets a source-only edit reuse the dependency-install result.

Boundary: Modern builders can use mounts and optimizations beyond a one-instruction-one-layer sketch. The diagram shows a useful Dockerfile order, not a storage-driver implementation.

Failure state: A source edit now affects the dependency-install inputs and can trigger avoidable work.

Images contain ordered filesystem changes. Starting a container adds a writable layer and runtime configuration. A volume is a separately managed mount, not image content.

Boundary: “Immutable” describes image content after it is created. Registries, tags, layers, and storage drivers have their own implementation details.

Failure state: Container-local writable data is removed with the container. Data that must outlive it belongs in an explicit volume or external store.

Docker resolves an image, creates a container, supplies a writable layer and networking, then starts the configured process. The container remains running only while its main process runs.

Boundary: Docker’s daemon and default bridge are common examples, not the universal container architecture. Other runtimes expose the OCI lifecycle differently.

Failure state: When the main process exits, the container stops. A background child process does not automatically keep the intended workload healthy.

A published port creates a host-side forwarding path into the container network namespace. In a common Linux bridge setup, traffic crosses host rules and a veth attachment before reaching the process listener.

Boundary: Bridge, veth, NAT, and rootless forwarding details depend on the runtime/network driver; the path is a common Linux example.

Failure state: If the app listens only on 127.0.0.1 inside its namespace, the published path to its container address may fail.

A cgroup can account for and limit resources. Container PID 1 receives lifecycle signals and must handle them appropriately; the runtime can later escalate if the process does not exit.

Boundary: Exact OOM selection, signal handling, and runtime stop behavior depend on kernel, runtime, and configured timeout.

Failure state: The process ignores or mishandles the graceful signal. After the configured grace period, the runtime may force termination.

Namespaces limit what the process sees; capabilities, seccomp, Linux security modules, user mappings, and mount policy reduce what it may do. Host mounts and privileged mode can reopen dangerous paths.

Boundary: No single switch makes a container fully secure. The effective boundary depends on kernel, runtime, user privileges, filesystem mounts, and workload needs.

Failure state: A broad writable host mount gives the process access outside its intended filesystem boundary.

The builder emits image metadata and content-addressed layers. A tag is a human-friendly pointer that can move; the digest identifies specific content. The runtime pulls the relevant manifest and layers before creating a container.

Boundary: Multi-platform indexes can point to platform-specific manifests. A pull selects content for the target platform rather than downloading every platform image.

Failure state: If a tag is repointed, two pulls at different times can resolve different content unless a digest is pinned.

A running PID 1 proves that a process exists. It does not prove that the app listens on the right address, that the port is published, or that the container has permission and memory to answer.

Boundary: Example commands and output vary by runtime and host network driver. Treat this as a diagnostic order, not a universal CLI transcript.

Failure state: The process is healthy but listens only inside its own loopback; traffic forwarded to the container address cannot reach that listener.

A Linux container runs host-kernel-scheduled processes with isolated views. A VM runs a guest kernel over virtualized hardware. They are often stacked together in cloud environments.

Boundary: Strong isolation depends on implementation and configuration. This comparison is architectural, not a blanket security ranking.

Failure state: Broad host privileges can weaken the intended container boundary; the presence of a container label alone is not a security guarantee.