Docker

Docker packages an application together with everything it needs to run — code, runtime, system libraries, configuration — into a single unit called a container, so it behaves the same on your laptop, a teammate's laptop, and a production server.

The key idea that makes this cheap is that a container is not a virtual machine. A VM virtualizes hardware and runs a full guest operating system (its own kernel) on top of a hypervisor, which is why VMs are measured in gigabytes and take tens of seconds to boot. A container virtualizes at the operating-system level instead: it shares the host machine's kernel, and is just an isolated, resource-limited process (or group of processes) using Linux kernel features — namespaces (what a process can see: its own filesystem, network interfaces, process list, hostname) and cgroups (what a process can use: limits on CPU, memory, I/O). That's why containers are measured in megabytes and start in a fraction of a second — there's no second kernel to boot.

Two terms to keep straight from the start:

• Image — a read-only template: your application plus its dependencies, built once from a set of instructions (a Dockerfile) and stored as a stack of immutable layers.
• Container — a running (or stopped) instance created from an image, with a thin writable layer of its own on top. You can start many independent containers from the same image, the same way you can create many objects from one class.

Images are shared and distributed through a registry — Docker Hub is the default public one, though most teams eventually run or use a private registry (GHCR, ECR, GCR, Artifactory, ...).

The official Docker Engine install on Ubuntu (Docker's own apt repository, not the older docker.io distro package, which lags behind):

sudo apt update && sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update && sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

The docker command you type is a thin CLI client. It talks over a REST API to dockerd, the background daemon that does the actual work: pulling images, building them, and managing containers, networks, and volumes. Under the hood, dockerd delegates to containerd (a separate container-lifecycle daemon) which in turn uses runc, a low-level tool that creates the namespaces/cgroups and actually starts the container process according to the OCI (Open Container Initiative) runtime spec. You'll rarely touch containerd or runc directly, but knowing they're there explains why other tools (Kubernetes, Podman) can reuse the same layers of this stack without going through Docker at all.

A Dockerfile is a plain-text recipe: each instruction produces one new, cached layer on top of the previous one. A minimal example for a small Python app:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "app.py"]

CMD and ENTRYPOINT are easy to mix up. With only CMD set, docker run image echo hi replaces the whole default command with echo hi. With only ENTRYPOINT set to ["ping"], that same command line instead runs as ping echo hi — the arguments are appended, not substituted. Using both together is the common pattern for CLI-style images: ENTRYPOINT fixes the binary, CMD supplies default arguments that a caller can still override.

Every instruction in a Dockerfile is cached as its own layer. On a rebuild, Docker reuses a cached layer as long as the instruction's text and its inputs (the copied files, for COPY/ADD) haven't changed — but the moment one layer's cache is invalidated, every layer after it must be rebuilt too, even if they wouldn't otherwise have changed. That's why the example Dockerfile above copies requirements.txt and installs dependencies before copying the rest of the application code: source code changes on every commit, but dependencies rarely do, so ordering it this way means a typical rebuild reuses the (slow) dependency-install layer and only re-runs the (fast) final copy.

A container's writable layer disappears the moment the container is removed — anything written there (a database's data files, uploaded content) is lost with it. Three ways to persist data outside that layer:

• Named volumes — storage that Docker creates and manages itself (under /var/lib/docker/volumes on Linux). The default choice for most persistent data: portable, and not tied to any particular host directory layout.
• Bind mounts — a specific path on the host filesystem, mapped directly into the container. Useful for local development (edit code on the host, see it live in the container) or when you need a known host path.
• tmpfs mounts — storage that lives only in host memory, never written to disk, and vanishes when the container stops. Useful for secrets or scratch space you don't want persisted anywhere (Linux only).

Every container gets network access through a Docker network. A common gotcha: on the default bridge network, containers can only reach each other by IP address. Create your own user-defined bridge network instead, and Docker gives every container on it automatic DNS resolution by container name — the standard way multi-container apps talk to each other without hardcoding IPs.

Real applications are usually more than one container — an API, a database, a cache. Compose lets you describe the whole stack declaratively in one docker-compose.yml file (services, the networks and volumes they share, environment variables) instead of typing out long docker run commands by hand.

services:
  web:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - dbdata:/var/lib/postgresql/data

volumes:
  dbdata:

Note the space: docker compose (a plugin bundled with modern Docker installs) is the current, actively developed tool. The old standalone docker-compose (hyphenated, a separate Python binary) is the deprecated predecessor — if a tutorial uses the hyphenated form, the space form is almost always the drop-in replacement today.

A naive Dockerfile often ships the entire build toolchain (compilers, dev headers, package caches) inside the final image, when the running application only needs the compiled output. A multi-stage build fixes this: use one stage to build, and copy only the finished artifact into a clean, minimal final stage.

FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN go build -o /out/app .

FROM gcr.io/distroless/static-debian12
COPY --from=builder /out/app /app
ENTRYPOINT ["/app"]

The final image here contains nothing but the compiled binary and a minimal runtime base — no Go toolchain, no shell, no package manager. That's both smaller (faster to pull and start) and a much smaller attack surface (there's barely anything in it for an attacker to exploit even after a compromise).