Containerization — Core Concepts

The Problem Containers Solve

Before containers, deploying software was genuinely painful. You’d write an app on your laptop running Ubuntu 20.04 with Python 3.8 and a specific version of a database library. Then you’d try to run it on a production server with a slightly different Ubuntu, Python 3.6, and a library version from two years ago. Chaos.

The old solution was “configure the server to match your laptop.” This worked, sort of, until you had twenty developers with twenty laptops and fifty servers. Then configuration drift set in — environments slowly diverged, mysterious failures appeared, and every deployment was a small gamble.

Virtual machines helped, but they were heavy. A VM packages an entire operating system. Booting one takes minutes. Running fifty of them on one server is expensive.

Containers hit the right balance: lightweight enough to run hundreds per server, isolated enough to avoid conflicts.

How Containers Actually Work

The Linux Primitives

Containers aren’t magic. They’re built on two Linux kernel features that have existed since 2008: namespaces and cgroups.

Namespaces are isolation walls. When a process runs inside a namespace, it can only see the things the namespace gives it. It thinks it has its own file system, its own network, its own list of running processes. From inside the container, it looks like you’re alone on the machine. From outside, you can see all the containers.

cgroups (control groups) are resource limits. You can tell a container: “you get 2 CPU cores and 512MB of RAM, no more.” If the container tries to use more, the kernel blocks it. This stops one misbehaving container from starving everything else.

Docker — the tool that made containers mainstream in 2013 — wrapped these kernel features in a clean interface that developers could actually use without reading a systems programming textbook.

Images vs. Containers

This distinction trips people up constantly.

An image is the template. It’s the lunchbox before anyone opened it — a frozen, read-only snapshot of your code, dependencies, and configuration. Think of it like a class in programming.

A container is a running instance of an image. When you “run” an image, Docker creates a container — a live, writable copy. You can run twenty containers from the same image simultaneously. Kill a container and it’s gone. The image is untouched.

Images are built from Dockerfiles — text files that describe, step by step, how to construct the environment:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "main.py"]

This says: start from an official Python image, add my code, install my dependencies, and run main.py when the container starts. Anyone with this Dockerfile can build the exact same image anywhere.

Layers and Caching

Images are stored in layers — each instruction in a Dockerfile creates one layer. If you change one line of code but not the dependencies, Docker only rebuilds the layers after the change. The dependency layer is cached. This makes builds fast.

It also makes image distribution efficient. If two images share the same base layer (like python:3.11-slim), it’s only stored once on disk.

Docker vs. The Container Ecosystem

Docker popularized containers but didn’t invent them. Google had been running containers internally since around 2006 with a system called Borg. Docker’s contribution was packaging the Linux primitives into something a web developer could learn in an afternoon.

By 2015, other formats emerged and the industry needed a standard. The Open Container Initiative (OCI) was formed to define what a container image is — format, runtime, distribution. Docker images are OCI-compliant. So are images built with Podman, containerd, and other tools. You’re not locked to Docker’s specific runtime anymore.

Container Registries

Images need somewhere to live. Container registries are like GitHub for images — you push images there, and servers pull them when deploying.

Docker Hub is the default public registry. Private registries exist for companies that don’t want their images public: Amazon ECR, Google Artifact Registry, GitHub Container Registry.

A typical workflow: developer builds image on laptop → pushes to registry → production server pulls from registry → runs container. The registry is the handoff point.

What Kubernetes Does (That Docker Doesn’t)

Docker runs containers on one machine. Kubernetes runs containers across many machines.

Kubernetes is an orchestrator — it decides which container runs on which server, restarts containers that crash, scales them up when traffic spikes, scales them down when traffic drops, and manages networking between them. Released by Google in 2014 (based on Borg’s lessons), it became the dominant orchestration tool by around 2018.

The relationship: Docker (or containerd) runs the actual containers. Kubernetes decides what to run, where, and how many. They work together.

Common Misconception: Containers Are Not Virtual Machines

A VM virtualizes hardware — it has a fake CPU, fake RAM, fake disk. This requires a hypervisor and a full OS inside. A container virtualizes the OS — it shares the host kernel but has its own filesystem and process space. No fake hardware. No second OS.

This is why containers start in milliseconds instead of minutes, and why you can run hundreds of containers on a laptop that would buckle under ten VMs.

The tradeoff: less isolation. A vulnerability in the shared kernel can affect all containers on a host. VMs have a harder wall between them. For most applications, containers are isolated enough. For high-security environments, VMs (or a combination) are still used.

One Thing to Remember

An image is the recipe; a container is the meal. Docker packages the recipe so anyone can cook the same dish. Kubernetes runs the restaurant — hundreds of containers, on dozens of servers, keeping everything running even when things break.