Docker Image vs. Container: Blueprint vs. Runtime

WHY IT EXISTS: Before containers, deploying a Python model meant installing dependencies directly onto a host and praying that numpy and system CUDA drivers did not conflict with another team's requirements. Docker solves this by bundling the application with its entire user-space environment into a single portable unit, so the image you test in CI is bitwise identical to what runs in production.

THE MENTAL MODEL: Think of an image as a stopped virtual machine template and a container as the actual powered-on machine. The image is read-only and immutable; once built, its layers never change. The container adds a thin writable layer on top where logs, temp files, and runtime mutations live. If you delete the container, that writable layer disappears, while the image remains untouched.

HOW IT WORKS: An image is built from a Dockerfile and stored as a stack of layered filesystem diffs. Each instruction like RUN or COPY creates a new layer. When you execute docker run, the Docker engine unpacks those layers using a union filesystem, creates an isolated process namespace, cgroup, and network stack, and mounts the writable container layer. Multiple containers can share the same underlying image layers, which saves disk and speeds up startup because the kernel pages the read-only layers once.

WHEN TO USE IT: Use images when you need reproducible artifacts that version your environment alongside your code. Use containers when you need to execute that environment, whether for a one-off training job, a long-running inference API, or a local Jupyter notebook with exact dependency pins. In MLOps, images travel through registries from CI to staging to production, while containers are the ephemeral workers that actually train or serve.

WHEN NOT TO USE IT: Do not use containers when you need bare-metal GPU performance without the overhead of the Docker runtime, though this gap is shrinking. Do not treat containers as persistent databases: any data written inside a container without a volume mount is lost when the container exits. And do not build a new image for every code change if your artifact is a 5 GB CUDA base layer; layer caching exists to prevent that pain.

ONE CANONICAL EXAMPLE: A data science team packages a PyTorch training script into an image based on nvidia/cuda:11.8-cudnn8-runtime-ubuntu20.04, pinning torch==2.0.1 and transformers==4.30.0. They push this image to an internal registry. During a hyperparameter sweep, a Kubernetes Job spawns fifty containers from that same image, each mounting a shared NFS volume for the dataset and writing model checkpoints back to S3. The image guarantees every trial runs in the exact same environment, while the containers provide isolation so a segfault in one trial never crashes another.