What a container actually is

Every explanation of containers you have read probably started with a shipping metaphor. The metaphor is not wrong, but it does not help you debug anything at two in the morning.

A container is a normal process with a restricted view of the machine. On a Linux host, ps shows it in the ordinary process list, because that is what it is. On macOS and Windows it is a process inside the Linux VM that Docker Desktop runs for you, which is the same thing one level down.

What does the restricting

Namespaces decide what the process can see. Give it its own PID namespace and it believes it is PID 1 with no other programs on the box. Its own network namespace and it has private interfaces, so port 80 inside means nothing to port 80 outside. Its own mount namespace and it sees a different filesystem root.

Cgroups decide what it can use, such as a memory ceiling or a share of CPU. When a container dies for using too much memory, the cgroup set the limit and the kernel's out-of-memory killer did the killing.

The root directory itself comes from a union filesystem: read-only layers with one thin writable layer stacked on top. That layering is why images are cheap to ship, and it is the reason the next lesson exists.

Why this matters immediately

Two consequences fall straight out of it.

Containers start fast because nothing boots. A virtual machine has a kernel to bring up before it can run anything; a container is a process that starts and has restrictions applied as it does.

A Linux container also needs a Linux kernel, which your Mac does not have. Docker Desktop runs a small Linux VM and puts your containers inside it. That hidden boundary is why file access between host and container can feel slow. It is not why --platform exists, though: that flag is about CPU architecture and target OS, and it matters on an ARM Mac pulling an amd64 image.

Virtual machines, for contrast

The isolation row is the one to remember. A container shares the host kernel, so a kernel escape is an escape onto the host, and a VM does not have that shape of weakness. For your own services that trade is usually worth it. For code submitted by strangers, however, pick the stronger boundary.

Size varies more than people expect. The sample project in this course produces a 234 MB image, almost all of it the node:24-slim base rather than the application.

Check yourself

Knowledge check2 questions

Question 1 of 2

What is the fundamental difference between a container and a virtual machine?

A container cannot access the networkAA container shares the host kernel instead of booting its ownBA container can only run a single process, everCA container is written in GoD

Next