Docker

Everything a Docker round tends to touch, from how an image is built to why docker stop hangs for ten seconds.

Containers vs VMs

• A container is an ordinary Linux process, isolated by namespaces (what it can see: pid, net, mnt, uts, ipc, user, cgroup) and limited by cgroups (what it can use: CPU, memory, PIDs, I/O).
• Image = read-only layers + config (entrypoint, env, user). Container = image + a thin writable layer + runtime state. One image, many containers.
• Engine stack: docker CLI → dockerd (REST API, builds) → containerd (images, lifecycle) → runc (OCI runtime that creates the namespaces and cgroups).
• On macOS and Windows, Docker Desktop runs Linux containers inside a lightweight Linux VM.

Images, layers & build cache

• Each RUN, COPY and ADD adds a filesystem layer; ENV, CMD, EXPOSE, LABEL and friends only change metadata.
• Layers are content-addressed and shared between images. A container’s writes go to a copy-on-write layer that is deleted with the container.
• Deleting a file in a later layer hides it but doesn’t shrink the image: clean up in the same RUN.
• Cache rule: a step is reused if the instruction and its inputs are unchanged. COPY/ADD compare file checksums (not mtimes); RUN compares only the command string. After the first miss, every later step rebuilds.
• Tags (nginx:1.27) are mutable pointers; digests (nginx@sha256:…) are immutable. latest is only the default tag, not “the newest”.
• Inspect with docker history img and docker image inspect img; rebuild with --no-cache, refresh the base with --pull.

Interview tip

Order a Dockerfile from least to most frequently changed: base image → OS packages → dependency manifest (package.json, go.mod) → install → source. Then a code change only rebuilds the last layers.

Dockerfile instructions

CMD vs ENTRYPOINT, exec vs shell form

• Exec form ["node", "server.js"]: a JSON array (double quotes), no shell, no $VAR expansion; your process is PID 1 and receives signals.
• Shell form node server.js: runs /bin/sh -c "node server.js"; variables expand, but the shell sits in front of your app and may not forward SIGTERM.

Multi-stage build & .dockerignore

FROM golang:1.25 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/app

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /out/app /app
USER 65532:65532
ENTRYPOINT ["/app"]

• Compilers, sources and caches stay in build; only the binary ships. Final stage options: scratch, distroless, -slim, alpine.
• docker build --target build . stops at a stage (useful for tests); BuildKit skips stages the target doesn’t need.
• Build secrets: RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci with docker build --secret id=npmrc,src=$HOME/.npmrc .. The secret never lands in a layer.
• Dependency cache across builds: RUN --mount=type=cache,target=/root/.cache/go-build go build ….
• .dockerignore (context root, .gitignore-like syntax) keeps .git, node_modules, .env, build output and logs out of the context: smaller uploads, fewer cache misses, no leaked secrets.

CLI cheat table

docker run flags

• always vs unless-stopped: both restart on crash; after a manual docker stop, always comes back when the daemon restarts, unless-stopped doesn’t.
• --cpus is a hard quota; --cpu-shares is only a relative weight under contention.

Volumes, bind mounts & tmpfs

• A new, empty named volume is pre-filled with the image’s files at that path; a bind mount hides whatever the image had there.
• -v silently creates a missing host path (as a directory); --mount type=bind fails instead.
• Anonymous volumes (from VOLUME or -v /path) pile up: docker volume prune (add -a for unused named ones too).

Networking

• On the default bridge, containers can only reach each other by IP; name resolution needs a user-defined network (--link is legacy).
• localhost inside a container is the container itself. Reach the host via host.docker.internal (Docker Desktop; on Linux add --add-host=host.docker.internal:host-gateway).
• A server must listen on 0.0.0.0, not 127.0.0.1, or -p forwards to nothing.

Docker Compose

services:
  api:
    build: .
    ports: ["8080:8080"]
    environment: { DB_HOST: db }
    depends_on: { db: { condition: service_healthy } }
  db:
    image: postgres:16-alpine
    environment: { POSTGRES_PASSWORD: example }
    volumes: [pgdata:/var/lib/postgresql/data]
    healthcheck: { test: ["CMD-SHELL", "pg_isready -U postgres"], interval: 5s }
volumes: { pgdata: {} }

• Commands: docker compose up -d --build, ps, logs -f api, exec api sh, config (render the merged file), down (containers + network), down -v (also volumes).
• Each project gets its own network; services find each other by service name (db:5432).
• depends_on alone only orders startup; condition: service_healthy plus a healthcheck waits for readiness.
• compose.yaml is the preferred file name, compose.override.yaml merges automatically, and the top-level version: key is obsolete.
• .env in the project directory feeds ${VAR} interpolation in the file; env_file: sets variables inside the container.
• docker compose (V2, a CLI plugin) replaced the old Python docker-compose.

Smaller, safer images

• Size: multi-stage builds; slim, distroless or scratch bases; apt-get update && apt-get install -y --no-install-recommends … && rm -rf /var/lib/apt/lists/* in one RUN; a tight .dockerignore.
• Alpine is tiny but uses musl libc: glibc-built binaries and some wheels break or run slower.
• Run as a non-root USER; never use --privileged casually; mounting /var/run/docker.sock gives root on the host.
• Pin base images by version (or digest for reproducibility), rebuild often to pick up patches, and scan (Docker Scout, Trivy).
• At run time: --read-only with --tmpfs /tmp, --cap-drop ALL then add back only what’s needed, no-new-privileges, memory/CPU/PID limits, rootless mode or user namespaces where possible.

Gotcha

Secrets in ENV, ARG or a COPYed file persist in the image: ARG values show up in docker history, and a file deleted in a later layer is still in the earlier one. Use RUN --mount=type=secret at build time and inject secrets at run time.

PID 1 & signals

• docker stop sends SIGTERM (or the image’s STOPSIGNAL) to PID 1, waits 10 s by default (-t, --stop-timeout), then sends SIGKILL.
• The kernel skips default signal actions for PID 1: without a handler, SIGTERM is simply ignored, so every stop waits the full timeout and ends in exit 137.
• PID 1 must also reap orphaned children, or zombies accumulate.
• Fixes: exec form; exec "$@" at the end of entrypoint scripts; handle SIGTERM in the app (stop accepting work, drain, close connections); docker run --init or tini to forward signals and reap zombies.
• Wrappers like npm start or sh -c add a parent process that may not pass signals on; run node server.js directly.

#!/bin/sh
set -e
# one-time setup, then hand PID 1 to the real process
[ -n "$DB_HOST" ] || { echo "DB_HOST is required" >&2; exit 1; }
exec "$@"   # used with ENTRYPOINT ["/entrypoint.sh"] and CMD ["node", "server.js"]

Debugging a crashing container

1. docker ps -a for the status and exit code, then docker logs --tail 50 app.
2. docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}} {{.State.Error}}' app.
3. Check what actually runs: docker image inspect -f '{{.Config.Entrypoint}} {{.Config.Cmd}} {{.Config.User}}' app:1.0.
4. Reproduce by hand: docker run -it --rm --entrypoint sh app:1.0, then start the command yourself. Distroless has no shell: use its :debug variant or docker cp files out.
5. Watch docker stats (memory near the limit?) and docker events; docker diff app lists files changed in the container.

Quick answers

• Image vs container? An image is the read-only template; a container is an instance of it with its own writable layer and process.
• CMD vs ENTRYPOINT? ENTRYPOINT is the executable; CMD gives default arguments (or the default command); docker run args replace CMD.
• COPY vs ADD? COPY for local files; ADD only when you need local tar extraction or a URL/git source.
• ARG vs ENV? ARG exists only during the build; ENV is stored in the image and set in every container.
• Why did my data disappear? It was written to the container layer, which docker rm deletes; use a volume.
• How do two containers talk? Put them on the same user-defined network (or Compose project) and use the container or service name, not localhost.
• EXPOSE vs -p? EXPOSE is documentation (and feeds -P); only -p/-P opens a port on the host.
• stop vs kill? stop sends SIGTERM and waits (10 s default) before SIGKILL; kill sends SIGKILL right away.
• save/load vs export/import? save writes an image with all layers and metadata; export flattens one container’s filesystem with no history or config.
• Dangling image? An untagged <none>:<none> image, usually left when a tag is rebuilt; docker image prune removes them.
• Why is the build cache useless? COPY . . comes before the dependency install, or a huge unignored context changes on every build.
• Is a container as isolated as a VM? No: it shares the host kernel, so harden it (non-root, dropped capabilities, seccomp, limits).
• Why does my container exit immediately? PID 1 finished: the process forked into the background or the CMD was a one-off command.

Gotchas & traps

• RUN apt-get update on its own line is cached forever, so later installs use stale package lists: combine it with the install.
• Exec form doesn’t expand variables: CMD ["echo", "$HOME"] prints $HOME. Use ["sh", "-c", "echo $HOME"] when you need a shell.
• Single quotes in exec form are invalid JSON, so Docker silently treats the line as shell form.
• Windows CRLF line endings in an entrypoint script give exec /entrypoint.sh: no such file or directory.
• A bind mount over /app hides the image’s node_modules; add an anonymous volume for /app/node_modules in dev setups.
• Bind-mounted files keep host UIDs, so a non-root container user can get permission denied.
• The default json-file log driver doesn’t rotate logs: set max-size/max-file or use the local driver before the disk fills.
• On Linux, published ports are opened through Docker’s own iptables rules and can bypass firewalls such as ufw.
• An unhealthy status doesn’t restart anything in plain Docker (Swarm replaces the task; Kubernetes ignores HEALTHCHECK and uses its own probes).
• docker compose down -v deletes named volumes, including your database.