How does Docker actually isolate a process — what's really different from a VM?

#"Lightweight VM" is a useful lie

Docker containers get introduced as "lightweight virtual machines" so often that most engineers repeat the phrase without ever being asked to defend it in an interview. It's a useful first mental model and a dangerous final one, because the two technologies isolate a process using completely different mechanisms, with completely different security and performance implications. Understanding the difference is the fastest way to sound senior in a DevOps conversation.

#What a VM actually virtualizes

A virtual machine virtualizes hardware. A hypervisor (Type 1 like ESXi/KVM, or Type 2 like VirtualBox) presents each VM with virtual CPUs, virtual memory, and virtual devices. Each VM then boots its own, independent kernel on top of that virtual hardware — its own Linux or Windows kernel, its own device drivers, its own process table, completely unaware that the "hardware" underneath it is emulated. Two VMs on the same physical host are as isolated from each other as two separate physical machines, because neither one shares a kernel with the other.

#What a container actually isolates

A container virtualizes nothing at the hardware level. Every container on a host runs as an ordinary process, scheduled by the same Linux kernel as every other container and the host itself. What makes it look like an isolated machine is a combination of kernel features that change what that one process can see and use:

Namespaces answer "what can this process see?" A process in a PID namespace genuinely cannot see, signal, or ps the processes running in a sibling container or on the host — the kernel simply filters them out of view. But it is still the same kernel, scheduling the same underlying threads on the same CPU cores.

#cgroups: the other half of the equation

Namespaces control visibility; cgroups (control groups) control consumption. A cgroup lets the kernel cap and account for how much CPU, memory, disk I/O, and even how many process IDs a group of processes can use. This is what backs docker run --memory=512m --cpus=1.5: the kernel's cgroup v2 controller enforces a hard memory ceiling (an out-of-memory kill scoped to that cgroup, not the whole host) and a CPU quota (a fraction of a core per scheduling period), and exposes live usage numbers that docker stats reads directly from /sys/fs/cgroup.

Put together: namespaces make a process think it's alone; cgroups make sure it can't hog the machine even though it isn't. Docker also relies on a union/overlay filesystem (OverlayFS) to stack read-only image layers under a thin writable layer per container — this is why pulling an image is fast (shared, cached layers) and why a container's disk writes vanish when it's removed unless you mount a volume.

#A real Dockerfile, and where each isolation piece shows up

# Stage 1: build the binary in a full Go toolchain image
FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /out/api ./cmd/api

# Stage 2: ship only the binary in a minimal runtime image
FROM alpine:3.19
RUN apk add --no-cache ca-certificates \
 && addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /out/api /app/api
USER app
EXPOSE 8080
ENTRYPOINT ["/app/api"]

The multi-stage build keeps the final image small by discarding the Go compiler entirely — the runtime image never sees go build, only the compiled binary. USER app matters more than it looks: without it, the process inside the container runs as UID 0. Thanks to the MNT and PID namespaces that UID 0 can't see the host filesystem or host processes, but if a container-escape bug is ever found in the runtime, "root inside" being mapped to "root on the host" (no USER namespace remapping) turns a contained bug into a host compromise. EXPOSE 8080 doesn't open a port by itself — it's documentation consumed at docker run -p; the actual port binding happens in the container's own NET namespace.

#VM vs. container, side by side

🧠 Check your understanding
0/3 · 0/3 answered
1. A container and the host it runs on both show process IDs starting from a small number for their own "first" process. Which kernel feature makes this possible?
OverlayFSThe hypervisorThe PID namespacecgroups
2. You run a container with `--memory=256m` and it starts allocating far more than that. What actually happens?
The container is automatically moved to another hostThe host itself runs out of memory and rebootsDocker silently ignores the limitThe kernel's cgroup controller kills the process once it exceeds 256MB, scoped to that container
3. Why is a container generally considered a weaker security boundary than a VM?
Containers cannot use TLSContainers share the host's kernel, so a kernel vulnerability can potentially be exploited across container boundariesVMs cannot run LinuxContainers do not support networking