Docker from First PrinciplesPost 17 of 18 · 18 of 18 written

17. Question bank

Docker · 17 of 184 min readOct 2026

Thirty questions, roughly in order of depth. Answer each out loud before reading the answer; if you can explain all thirty from the mechanisms rather than from memory, you’re fluent. The answers are short on purpose, and each points back to a Part.

Foundations

  1. What is a container, in kernel terms? A process tree with its own namespaces, a cgroup with limits, the image’s filesystem as its root, and reduced privileges. There is no kernel object called “container” (Part 2).
  2. Why does uname -r inside an Ubuntu container on a Fedora host print Fedora’s kernel? Containers share the host kernel; only user space comes from the image (Part 2).
  3. Why does Docker on macOS need a VM? Linux containers need a Linux kernel, and macOS doesn’t have one (Part 4).
  4. Image versus container? An image is read-only layers plus config; a container is a running process with a writable layer added on top (Part 3).
  5. Why doesn’t RUN rm big.file shrink the image? Layers are immutable; the delete only adds a whiteout in a new layer while the bytes stay in the old one (Part 3).
  6. Tag versus digest? A tag is a movable name, a digest is a hash of exact content. Pin digests for reproducibility (Part 3).
  7. What happens, component by component, when you type docker run? The CLI calls the Engine API; dockerd asks containerd, which pulls the image if needed; containerd starts a shim; the shim calls runc; runc creates namespaces and cgroups, pivots the root and executes your process, then exits while the shim stays (Part 4).
  8. Why is membership in the docker group equivalent to root? Whoever controls the daemon can start a container that mounts the host’s filesystem as root (Part 4).

Running containers

  1. Why does docker stop take 10 seconds for some containers? PID 1 isn’t handling SIGTERM, often because a shell is PID 1, so Docker waits and then sends SIGKILL (Part 5).
  2. What does exit code 137 mean, and how do you distinguish its causes? 128 + 9, killed by SIGKILL; State.OOMKilled tells a memory kill from a stop timeout (Part 5).
  3. Why does instruction order matter in a Dockerfile? The first cache miss rebuilds every later layer, so stable steps go first (Part 6).
  4. ENTRYPOINT versus CMD? ENTRYPOINT is the program; CMD supplies default arguments, replaced by whatever follows the image name in docker run (Part 6).
  5. When do you use a multi-stage build? Whenever building needs tools that running doesn’t: compilers, CUDA headers, caches (Part 6).
  6. Volume versus bind mount? Docker manages a volume’s location; a bind mount is a host path you choose. Volumes suit service data, bind mounts suit code and datasets you handle from the host (Part 7).
  7. Why not write checkpoints into the container’s filesystem? Copy-on-write makes it slow, and the data disappears with the container (Parts 3 and 7).
  8. Your API works inside the container but not from the browser. First suspect? It’s bound to 127.0.0.1 inside its own network namespace (Part 8).
  9. How do containers find each other by name? Docker’s embedded DNS on user-defined networks; the default bridge doesn’t provide it (Part 8).
  10. Is -p 8888:8888 safe on a cloud VM? No: it listens on all interfaces and on Linux bypasses ufw. Bind to 127.0.0.1 and tunnel (Part 8).

GPUs and AI images

  1. Does the image contain the NVIDIA driver? No. The kernel driver is on the host, and the toolkit injects matching user-space driver libraries at start (Part 10).
  2. nvidia-smi says CUDA 12.4 and the container uses CUDA 12.1. Problem? No. That number is the newest CUDA the driver supports, not what’s installed (Part 10).
  3. Do you need an nvidia/cuda base image to run PyTorch on a GPU? No; CUDA PyTorch wheels bundle the runtime libraries. You need a devel image only to compile CUDA code (Part 10).
  4. Why does a DataLoader crash with a bus error in Docker but not on bare metal? Workers share batches through /dev/shm, which is only 64 MB in a container (Part 10).
  5. Can Docker limit how much GPU memory a container uses? No. Use MIG, MPS or the framework’s own memory settings (Part 10).
  6. Why can’t containers on your Mac use its GPU? They run in a Linux VM with no access to Metal; run GPU inference natively and call it through host.docker.internal (Part 10).
  7. You built an image on the Mac and the server says “exec format error”. Why? The image is arm64 and the server is amd64; build with --platform linux/amd64 (Part 11).
  8. What makes a published experiment reproducible? The Dockerfile and lockfile explain the build; the pushed image digest, logged with each run, preserves the exact bytes (Parts 1 and 11).

Production and beyond

  1. Should model weights go in the image? Only when you want one immutable artifact for a fixed model; otherwise mount a cache or download at start (Parts 7 and 11).
  2. Liveness versus readiness for an LLM server? Liveness means the process responds; readiness means the model is loaded and can serve. Route traffic only on readiness (Part 12).
  3. Why might Docker be forbidden on a university cluster, and what do you use instead? Its daemon runs as root on shared machines; Apptainer runs containers as your own user, built straight from Docker images (Part 15).
  4. How would you safely run LLM-generated code? No network, read-only filesystem, non-root, tight limits, a timeout, and a stronger runtime such as gVisor or a microVM (Part 13).

Questions to keep asking

When you meet a new tool or error, these five questions usually lead to the answer: Which component produced this message? Is this happening at build time or at run time? Which namespace is involved: whose localhost, whose /, whose PID 1? Is it in the image, or provided by the host? What exactly is pinned, and what can change underneath me?