Docker builds images and runs containers using the Docker Engine on a host machine. While these two terms are often used together, understanding the distinct boundary between an Image (the blueprint) and a Container (the running instance) is fundamental to mastering Docker.
Docker Image
A Docker Image is a read-only template containing a set of instructions for creating a Docker container. It is analogous to a class in Object-Oriented Programming (OOP)—a blueprint from which multiple objects (containers) can be created.
Unlike VM snapshots, which are single files, Docker images are built from a series of read-only layers. Each instruction in a Dockerfile adds a new layer to the image.
Key Characteristics of an Image:
- Immutable: Once built, an image cannot be changed. If you need to alter the application code or update a dependency, you must build a new image. This immutability guarantees consistency.
- Portable: Because the image contains the application code, runtimes, libraries, and environment variables, it runs identically on any machine with Docker installed. This solves the infamous "it works on my machine" problem.
- Sharable: Images can be pushed to a central registry like Docker Hub, allowing teams around the world to use the exact same development, testing, and production environments.
Docker Container
A Docker Container is a runnable instance of a Docker Image. If an image is the blueprint of a house, the container is the actual house built from that blueprint.
When you start a container, Docker takes the read-only image and adds a thin, temporary read-write layer on top. Any changes made within the running container like creating new files, modifying logs, or installing temporary packages occur in this top read-write layer.
You can create, start, stop, move, or delete a container using the Docker API or CLI. You can connect a container to one or more networks and attach persistent storage (volumes) to it
Run Docker Container
docker run --publish 8000:8080
--detach --name alias_name application_name:1.0
Here an application running at port 8080 in a container is connected to port 8000 at the host machine. Now the host can access the application using URL localhost:8000
Difference between Docker Images and Containers
| Feature | Docker Image | Docker Container |
|---|---|---|
| Analogy | The Blueprint (Class) | The Building (Object/Instance) |
| Nature | A logical entity; a read-only template. | A real-world, runnable entity; a process. |
| Mutability | Immutable. Cannot be changed once built. | Mutable (temporarily). It has a read-write layer for runtime changes. |
| Resources | Does not consume CPU/RAM when stored (only disk space). | Consumes CPU and RAM only when running. |
| Creation | Created by building a Dockerfile. | Created by running an image using the docker run command. |
| Sharing | Can be pushed to and pulled from Docker Hub. | Cannot be shared directly. You must "commit" a container into a new image to share its state. |
| Layers | Made up of multiple read-only layers. | Made up of image layers plus one top read-write layer. |
| Connectivity | Cannot connect to or enter an image. | You can attach shell sessions (docker exec) to a running container. |
| Existence | Can exist independent of containers. | Cannot exist without a base image. |
Difference between Docker Container and VM Image
| Docker Container | VM Image |
|---|---|
| Docker Container can be started within seconds. | The VM image will take minutes to start. |
| Docker container resource usage is very less. | The VM image is very intense. |
| The isolation is at the process level. | The isolation is at the OS level. |
| Docker container manages the dependencies are managed in the application level. | VM image manages the dependencies at the system level. |