Week 1: Containers vs. Virtual Machines & Docker Architecture

1. Virtual Machines vs. Containers

A virtual machine virtualizes hardware: a hypervisor gives each VM its own virtual CPU, memory and disk, and each VM runs a full guest operating system — its own kernel, its own init system, its own everything. A container virtualizes nothing at the hardware level. It's a regular process on the host, running the host's kernel, that's been given the illusion of its own filesystem, network stack and process tree.

VIRTUAL MACHINES                        CONTAINERS
+-----------------------------+          +-----------------------------+
| App A     | App B            |          | App A     | App B            |
| Bins/Libs | Bins/Libs         |          | Bins/Libs | Bins/Libs         |
| Guest OS  | Guest OS          |          +-----------------------------+
+-----------------------------+          |     Docker Engine (shared)   |
|          Hypervisor          |          +-----------------------------+
+-----------------------------+          |        Host OS Kernel        |
|            Host OS           |          +-----------------------------+
+-----------------------------+          |          Physical Server      |
|         Physical Server      |          +-----------------------------+
+-----------------------------+

That single difference — sharing the host kernel instead of booting a new one — is why containers start in milliseconds instead of minutes, and why a container image is megabytes instead of gigabytes. It's also why the isolation is weaker: a kernel vulnerability can, in principle, be exploited to escape a container in a way that's structurally impossible against a VM's hardware-virtualized boundary.

2. The Linux Primitives: Namespaces & cgroups

Containers aren't a Docker invention — Docker is a friendly interface over two Linux kernel features that have existed for years: namespaces, which control what a process can see, and cgroups (control groups), which control what a process can use.

PID namespace      # its own process tree — PID 1 inside, invisible to other containers
NET namespace      # its own network interfaces, IP address, routing table
MNT namespace      # its own filesystem mount points — its own view of "/"
UTS namespace      # its own hostname
IPC namespace      # its own inter-process communication (shared memory, semaphores)
USER namespace     # its own UID/GID mapping (root inside != root outside, if configured)

# Every container is placed in a cgroup that caps its resource usage:
cpu     # how much CPU time the container's processes can consume
memory  # a hard memory ceiling — exceed it and the kernel OOM-kills the container
pids    # how many processes/threads it can fork (stops fork bombs from taking the host down)
io      # disk read/write throughput limits

Put together: namespaces make a container think it's alone on a machine, and cgroups make sure it can't hog the machine even if it tries. Every docker run flag you'll learn — --memory, --cpus, --network — is really just a friendly wrapper around configuring one of these two primitives.

3. The Docker Engine Architecture

When you type docker run nginx, four components hand the request down the chain, each doing one job:

docker CLI  --(REST API over a Unix socket)-->  dockerd (the daemon)
                                                      |
                                                      v
                                                 containerd  (manages container lifecycle)
                                                      |
                                                      v
                                                    runc  (actually creates the namespaces/cgroups
                                                           and starts the container process)

docker CLI is just a client — it doesn't run containers itself, it sends requests to dockerd, the background daemon. dockerd handles image builds, networks and volumes, and delegates the actual "start/stop/ monitor this container" work to containerd, a smaller, more focused daemon shared by other tools (Kubernetes itself talks to containerd directly, without Docker in the loop, in most modern clusters). runc is the lowest layer — a tiny CLI tool, following the OCI (Open Container Initiative) spec, that does the actual namespace/cgroup setup and execs your process into it.

# This is why "Docker containers" and "Kubernetes containers" are the same thing
# under the hood — both ultimately run through an OCI-compliant runtime (often
# containerd + runc). Kubernetes doesn't need Docker installed at all; it just
# needs something that speaks the Container Runtime Interface (CRI).

4. Installing Docker & Running Your First Container

Install Docker Desktop (Mac/Windows) or Docker Engine (Linux) from docker.com, then verify it's working:

docker --version
docker info          # confirms the daemon is running and reachable
docker run hello-world   # pulls a tiny image and runs it end-to-end

That last command is doing more than it looks like: pulling an image from Docker Hub (if you don't have it locally), creating a container from it, starting it, running its command, and printing its output. Let's do it more deliberately with a real, long-running container:

docker run -d --name my-nginx -p 8080:80 nginx
# -d          detached — runs in the background, returns your terminal immediately
# --name      a human-readable name instead of a random one
# -p 8080:80  publish container port 80 to host port 8080

docker ps                     # see it running
docker logs my-nginx          # see its stdout/stderr
docker exec -it my-nginx bash # get an interactive shell INSIDE the container
docker stop my-nginx          # send SIGTERM, then SIGKILL after a grace period
docker rm my-nginx            # remove the stopped container (doesn't remove the image)

Open localhost:8080 in a browser while it's running — you're talking to a process that, from the outside, looks exactly like a tiny, disposable Linux server, and from the inside genuinely believes it's the only thing running on its machine.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.