What Is a Docker Image?
A Docker image is a read-only template that contains everything needed to run an application: application code, a runtime, system libraries, environment variables, and configuration files. Images are the blueprint from which containers are created — a container is simply a running (or stopped) instance of an image with a thin writable layer added on top.
Cricket analogy: A Docker image is like a fully prepared kit bag containing the bat, pads, gloves, and strategy notes needed to play, and a container is like the actual player walking onto the field using that kit bag plus whatever gets added to it, like sweat and scuffs, during the innings.
Images vs. Containers
It helps to think of an image like a class in object-oriented programming, and a container like an object instantiated from that class. You can start many containers from the same image, each with its own writable layer, network settings, and process space, without ever modifying the underlying image.
Cricket analogy: An image is like a coaching manual's standard batting technique, and a container is like an individual batter who learns that technique and plays their own innings; many batters can learn from the same manual, each developing their own stance and scoring pattern, without changing the manual itself.
An image is immutable. Running docker run never changes the image itself — it only adds a new writable container layer on top. To change the image, you must rebuild it and, optionally, push a new tag.
Image Identity: Repository, Tag, and Digest
Every image is identified by a repository name (e.g. 'nginx'), an optional tag (e.g. ':1.27-alpine', defaulting to ':latest' if omitted), and a content-addressable SHA256 digest. The digest uniquely identifies the exact bytes of the image, which makes it useful for pinning a dependency so it can never silently change.
Cricket analogy: A repository name like 'nginx' with a tag like ':1.27-alpine' is like a player's team name plus jersey number for a specific season, defaulting to the current season if unstated, while the SHA256 digest is like a unique DNA test confirming it's exactly that player and not a similarly numbered lookalike.
# Pull an image by tag
docker pull nginx:1.27-alpine
# List local images
docker images
# REPOSITORY TAG IMAGE ID CREATED SIZE
# nginx 1.27-alpine b0c8f7e0c2a1 2 weeks ago 54.5MB
# Pull an image pinned to an exact digest
docker pull nginx@sha256:2ab30d6ac53580a6db8fa5468d4a5f279e0d9e...
# Inspect full image metadata
docker inspect nginx:1.27-alpineWhere Images Come From
Images are built from a Dockerfile using docker build, or downloaded ('pulled') from a registry such as Docker Hub, GitHub Container Registry, or a private registry. By default, Docker resolves unqualified names like 'nginx' against Docker Hub's official images namespace.
Cricket analogy: Building an image from a Dockerfile with docker build is like a coach hand-drafting a brand-new training regimen from scratch, while pulling from Docker Hub is like downloading a proven, publicly published regimen from the national board's official archive by default.
Never blindly run images from unknown sources in production. Because an image bundles a full filesystem and can define an ENTRYPOINT that executes arbitrary code, pulling and running an untrusted image is equivalent to running untrusted code with container privileges.
Inspecting an Image's History
The docker history command reveals the layers that make up an image and the Dockerfile instruction that produced each one, which is useful for understanding image size and debugging unexpected bloat.
Cricket analogy: docker history revealing which Dockerfile instruction produced each layer is like reviewing match footage frame by frame to see exactly which delivery caused a batter's dismissal, useful for diagnosing why a team's overall performance ballooned unexpectedly.
docker history nginx:1.27-alpine
# IMAGE CREATED CREATED BY SIZE
# b0c8f7e0c2a1 2 weeks ago CMD ["nginx" "-g" "daemon off;"] 0B
# <missing> 2 weeks ago STOPSIGNAL SIGQUIT 0B
# <missing> 2 weeks ago EXPOSE map[80/tcp:{}] 0B
# <missing> 2 weeks ago COPY docker-entrypoint.sh / 1.2kB- An image is a read-only, layered template; a container is a running instance of an image plus a writable layer.
- Images are identified by repository:tag, and precisely pinned by a SHA256 digest.
- The default tag when none is specified is 'latest' — this is a moving target, not a guarantee of the newest stable version.
docker pulldownloads an image;docker imageslists local images;docker historyshows how an image was built layer by layer.- Never run images from untrusted sources without vetting them first.
Practice what you learned
1. What is the primary difference between a Docker image and a Docker container?
2. What does the tag ':latest' actually guarantee?
3. Which command shows the layer-by-layer build history of an image, including the Dockerfile instruction that created each layer?
4. How can you guarantee you are pulling the exact same image bytes every time, regardless of tag reassignment?
5. By default, where does Docker look when you run `docker pull redis`?
Was this page helpful?
You May Also Like
Writing a Dockerfile
A practical guide to Dockerfile syntax and the core instructions used to build a custom image from scratch.
Image Layers and Build Caching
How Docker's layered filesystem and build cache work, and how to order Dockerfile instructions to maximize cache hits and minimize image size.
Container Registries
How container registries store, version, and distribute Docker images, covering tagging conventions, authentication, and push/pull workflows.
What Is Containerization?
An introduction to containerization as a lightweight, OS-level virtualization technique for packaging and running applications with their dependencies.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics