Docker¶

Prerequisites: none strictly required — helpful to have seen a Dockerfile before.

← Cloud | Next: Infrastructure as Code →

Why This Exists¶

"It works on my machine" is a statement about environments, not code. Docker's entire value proposition is collapsing "works on my machine" into "works," by packaging the process with everything it assumes exists — a specific libc, a specific set of env vars, a specific file at /etc/config.yml — into one artifact that runs identically on a laptop, a CI runner, and a production node.

The interview-relevant failure mode is treating Docker as "a lightweight VM." It is not. An image is a blueprint; a container is a running instance of that blueprint — the same relationship a class has to an object. Get that model right and layer caching, multi-stage builds, and "why is my container 1.2GB" all follow logically instead of needing to be memorized.

Containers vs. Virtual Machines¶

flowchart TB
    subgraph VM["Virtual Machines"]
        direction TB
        HW1[Hardware] --> HYP[Hypervisor]
        HYP --> OS1[Guest OS] & OS2[Guest OS]
        OS1 --> A1[App A]
        OS2 --> A2[App B]
    end
    subgraph DK["Containers"]
        direction TB
        HW2[Hardware] --> HOST[Host OS + kernel]
        HOST --> ENG[Container engine]
        ENG --> C1[Container A]
        ENG --> C2[Container B]
    end

That last row is the honest trade-off: containers are cheaper and faster because they give up the hardware isolation boundary. This is why multi-tenant, security-sensitive workloads sometimes still reach for VMs (or gVisor/Firecracker-style microVMs) around the container.

Image Layers and the Build Cache¶

An image is a stack of read-only layers, each one a diff from the layer below, plus a thin writable layer added at container-start (copy-on-write). Docker caches each instruction's layer by hashing the instruction and its inputs — a cache hit skips re-execution entirely.

flowchart TB
    L1["FROM python:3.12-slim"] --> L2["COPY requirements.txt ."]
    L2 --> L3["RUN pip install -r requirements.txt"]
    L3 --> L4["COPY . ."]
    L4 --> L5["CMD [...]"]
    L5 --> RW["Writable layer (per-container)"]
    style RW fill:#e65100,color:#fff

The instruction that determines your CI build time is instruction order, not instruction count. COPY . . before pip install means any source change — even a comment — invalidates every layer below it, forcing a full dependency reinstall on every build. Put things that change rarely (dependency manifests) before things that change often (source code):

# Bad: any code change busts the pip-install cache
COPY . .
RUN pip install -r requirements.txt

# Good: cache survives until requirements.txt itself changes
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Multi-Stage Builds¶

The image you build with (compiler, dev headers, test framework) is rarely the image you should ship. Multi-stage builds let one Dockerfile use a fat builder stage and copy only the compiled artifact into a minimal runtime stage:

# Stage 1: builder — has the full Go toolchain
FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

# Stage 2: runtime — no compiler, no source, no shell if you want it minimal
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

This single change typically drops image size from ~900MB (full Go toolchain) to under 20MB (static binary + nothing else), and it shrinks the attack surface: no shell, no package manager, no source code in the shipped artifact.

Networking¶

The concept that surprises people moving from localhost-based dev: on a user-defined bridge network, Docker runs an embedded DNS server, so containers reach each other by service name, not by IP. docker-compose.yml with services api and db — api connects to db:5432, not to an IP it has to discover. This is the same mental model Kubernetes Services extend later (see Kubernetes) — name-based service discovery, not IP-based.

Storage: Containers Are Not Where Data Lives¶

The writable layer survives docker stop / docker start — the same container instance keeps its filesystem across a stop-start cycle. It does not survive docker rm, and it does not survive the far more common case of replacing a container: a new deploy that runs docker run (or a fresh Compose/Kubernetes rollout) creates a brand-new container with a brand-new, empty writable layer, even though nothing was ever explicitly "deleted." Anything that must outlive a container being removed or replaced needs to live outside it:

Security Baseline¶

• Run as non-root (USER in the Dockerfile) — by default (no user namespace remapping), a container escape as root is a host-root escape, because container root and host root are the same UID 0. This is specifically what user namespace remapping (userns-remap, or Docker/Podman's rootless mode) closes: it maps container UID 0 to an unprivileged UID on the host, so a container-root escape lands as an unprivileged host user instead of host root. That mapping is opt-in and not Docker's default configuration — don't assume it's in place; verify it explicitly, and treat "run as non-root inside the container" as the baseline mitigation you control regardless of whether namespace remapping is also configured.
• Minimal base images (distroless / alpine / scratch) — fewer packages, fewer CVEs, smaller attack surface.
• Scan before you ship, not after (Trivy, Grype, or your registry's built-in scanner) — a CI gate, not a dashboard nobody reads.
• Never bake secrets into layers. ENV API_KEY=... or a COPY .env is in the image history forever, even if a later layer deletes the file — docker history and docker save | tar -xO both recover it. Inject secrets at runtime (mounted file, env var from a secret manager) instead.
• Pin tags to digests in production, not :latest. myapp:latest is not a version — it is a pointer that moves, and "which commit is actually running" becomes unanswerable during an incident.

Trade-offs¶

Interview Questions¶

Key Takeaways¶

Previous: Cloud | Next: Infrastructure as Code