Containers & Docker
The problem
'It works on my machine' is a real, recurring failure mode — an application's dependencies, versions, and environment differ subtly between a developer's laptop, a test server, and production, and those differences cause bugs that only appear after deployment. Containers package an application with its exact environment so it runs identically everywhere.
Why now
Processes and threads already established process isolation as the OS's way of separating running programs; a container is that same isolation, packaged with its own filesystem view so an application's entire environment — not just its memory — travels with it, using the shell and filesystem tools already covered to build that packaged environment.
Mental model
A container is a process with a disguise: it uses the same OS kernel as the host (unlike a full virtual machine, which runs a whole separate OS), but has its own isolated filesystem, process list, and network interface, so from inside it looks like a complete, private machine. An image is the frozen recipe for that environment; a container is a running instance of it — the same class/instance relationship as any other template-and-copy pattern.
Requires
- Processes & ThreadsOperating Systems
A container is fundamentally an isolated process (or group of processes) using OS-level isolation features; you need the process isolation concept already established before a lighter-weight, filesystem-inclusive version of it makes sense.
- The Shell & Filesystem NavigationLinux
Building and inspecting container images (via a Dockerfile and CLI commands) is done entirely through shell commands operating on a filesystem; you need that comfort level before container tooling is legible.
Unlocks
Used in
- Docker as the dominant containerization tool across the industry
- Consistent environments across development, testing, and production
- Kubernetes and other orchestration systems, which manage fleets of containers
- CI/CD pipelines that build, test, and deploy applications as container images
Projects
- Write a Dockerfile for a small application, build an image, and run it as a container, confirming it behaves identically regardless of the host machine's own environment
- Compare a container's resource footprint (startup time, memory) to a full virtual machine running the same application, and explain the difference
Examples
- A Dockerfile's FROM node:20 line specifies the base environment, guaranteeing the same Node.js version everywhere the image runs
- Two containers running on the same host share that host's kernel but each see their own isolated filesystem, unaware of the other's existence
Resources
Mastery checklist
- I can write a Dockerfile that builds a runnable image for a simple application
- I can explain the difference between a container and a full virtual machine
- I can explain the relationship between an image and a running container
- I can debug a container that fails to start by inspecting its logs