Docker Image vs. Container: Blueprint vs. Runtime
A Docker image is a read-only blueprint; a container is a live instance with a writable layer. You build an image once in CI and run many containers from it in production. The footgun is mutating a running container without updating the image recipe.
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.
Interview question
A data scientist installs a package inside a running container without rebuilding the image. What happens when the container is deleted and a new one starts from the same image?
- a.The package persists because pip modifies the underlying read-only image layers.
- b.The package is automatically committed to the parent image when the container stops.
- c.The package remains because all containers spawned from an image share writable state.
- d.The package is lost because it only existed in the container's writable layer.Correct
Why? this is the answer
The card explains that images are immutable and containers add a thin writable layer for runtime mutations, which disappears when the container is deleted. Option A is tempting because beginners often assume changes inside a container alter the image, but the image's read-only layers are never modified by runtime actions.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles