Docker Image vs Container
1. Docker Image
- A Docker image is a read-only template used to create containers.
- It includes everything needed to run an application: code, libraries, dependencies, environment variables, and configuration files.
- Images are immutable; once created, they do not change.
- You can think of an image as a blueprint or snapshot of your application environment.
- Images are stored in Docker registries (e.g., Docker Hub).
Example:
docker pull python:3.14This command pulls a Docker image with Python 3.14.
2. Docker Container
- A Docker container is a running instance of a Docker image.
- It is a live environment where your application runs.
- Containers are ephemeral—they can be started, stopped, deleted, and re-created.
- You can interact with a container (e.g., via shell access).
- Containers are isolated from the host system and from each other.
Example:
docker run -it python:3.14This command runs a container using the Python 3.14 image.
Key Differences Table
| Feature | Docker Image | Docker Container |
|---|---|---|
| Nature | Blueprint/Template | Running instance of an image |
| State | Static (Read-only) | Dynamic (Can change state) |
| Mutability | Immutable | Mutable (Can be changed during runtime) |
| Storage | Stored in Docker Registry or locally | Lives in memory/runtime |
| Lifespan | Persistent (unless deleted) | Temporary (deleted after stopped unless saved) |
Summary
- Image = Template
- Container = Running Application based on the Template
Interview angle
- “Image versus container?” - an image is an immutable stack of read-only layers plus metadata; a container is a running instance with a thin writable layer on top. Many containers share one image’s layers.
- “What happens to data written inside a container?” - it goes to the writable layer and disappears when the container is removed. Anything that must persist needs a volume or a bind mount.
- “Why are images layered?” - caching and sharing. Layers are content-addressed, so unchanged layers are reused across builds and shared between images, which is why ordering Dockerfile instructions well makes builds dramatically faster.