Docker Isn't a VM. Here's What It Actually Is.

#devops #docker #beginners #linux

https://www.youtube.com/watch?v=YwqUwVnMYT0

Everyone says Docker is a lightweight virtual machine. Same diagram in every tutorial — hardware, hypervisor, guest OS on one side; hardware, kernel, containers on the other. That diagram isn't wrong, but it's hiding something important.

A container doesn't create a fake computer. It doesn't boot an operating system. There is no guest kernel. A container is just a process — a regular Linux process running on the same kernel as everything else.

But the kernel plays a trick. It gives this process a restricted view of the world using two features.

Namespaces: What the process can see

Namespaces control visibility. The most dramatic one is the PID namespace — put a process in its own PID namespace and the entire process tree disappears. It thinks it's PID 1. It thinks it's the only thing running. But the host still sees it. Same process, two completely different views.

Network namespaces do the same trick with networking — the process gets its own IP address and ports. Two containers can both listen on port 80 because they each have their own network namespace.

Mount namespaces give it a different filesystem. Same kernel, different view.

Cgroups: What the process can use

Cgroups set hard limits. This container gets 2GB of memory. That one gets half a CPU core. Exceed your memory limit and the kernel kills your process. Exceed your CPU limit and you get throttled.

That's the whole model: namespaces restrict what it sees, cgroups restrict what it uses. No virtual hardware. No second kernel. Just isolation applied to a normal process.

The filesystem trick that makes it practical

When you write a Dockerfile, each instruction creates a read-only layer. Say your base image is 200MB. Spin up 50 containers from it — a VM approach costs 10GB. But with containers, all 50 share the same read-only layers. Each container just gets its own thin writable layer on top.

When a container needs to change a file, it copies just that file to its writable layer. Everything else stays shared. This is copy-on-write, and it's why containers are so storage-efficient.

What this means in practice

Speed. A VM boots an entire OS (tens of seconds). A container starts a process (often under a second).

Density. Where you might run 10-20 VMs on a server, you can run hundreds of containers — each one is just a process with no second OS eating resources.

The tradeoff. Every container shares the same kernel. If the kernel has a vulnerability, every container on that host is exposed. VMs provide stronger isolation because each runs its own kernel. That's why in production, it's common to run containers inside VMs — you get VM isolation with container density.

Watch the full animated explanation above — it visualizes namespaces, cgroups, and union filesystems step by step.