Key idea
A container isn't a small computer. It's an ordinary program on its host, given its own view of files, processes and network, and a share of CPU and memory. Underneath, every container on the host shares one thing: the host's kernel.
Machine, virtual machine, container
Path 1 drew this picture in Virtual machines and containers. This time, look inside the container.
What a container gets of its own
- Files: the image's file system, not the host's. The app sees only what the image put there.
- Processes: the app is process 1, and it can't see programs outside its container.
- Network: its own address and ports. Two containers can both listen on 8080 without clashing.
- Limits: a cap on memory and a share of CPU, set when it starts.
What it shares
The kernel is the part of the operating system that talks to the hardware: it starts programs, hands out memory, and sends network traffic. A container has none of its own. Two containers built on different Linux distributions, Alpine and Debian, report the same kernel version: the host's. The distributions supply the files; the kernel underneath is one and the same.
See it for yourself (optional; you'll run containers properly in module 3)
docker run starts a container, and --rm deletes it when it exits:
docker run --rm alpine:3.22 uname -r
docker run --rm node:22-slim uname -r
Both print the same kernel version, such as 6.12.76-linuxkit.
Why this matters
Starting is fast. Nothing boots. Starting a container is starting a program, so it takes about a second.
The image must suit the kernel. Linux containers need a Linux kernel. On macOS and Windows, Docker Desktop runs a small Linux virtual machine and your containers share its kernel. The processor matters too. Most servers use Intel or AMD processors (amd64); Apple silicon Macs and many small boards use arm64. An image is built for one of them, so an amd64 image on an arm64 Mac runs under emulation, which lesson 3.1.1 set up.
The walls are thinner than a VM's. A flaw in the shared kernel can reach every container on it. That's why providers run containers inside virtual machines, and why good images don't run the app as the all-powerful root user, which Non-root users and least privilege in images covers.
Check yourself