Images and containers

Images and containers

Docker's two core nouns. Every docker command you will ever type creates, runs, lists, or deletes one of these two things, so the distinction is worth locking in before touching the CLI. Mixing them up is also behind the most common beginner error messages: trying to run a container that is actually an image, or delete an image that is actually a container.

An image is a frozen, read-only package: a complete filesystem (OS files, Python, your libraries, your code) plus a bit of metadata like which command to start. Think of it as a snapshot of a machine that is known to work. Images are built once and never change.

A container is a running instance of an image. Docker takes the image, adds a thin writable layer on top, and starts your program inside it, isolated from the rest of the machine.

One image can start many containers, the same way one class can create many objects, or one git commit can be checked out into many working copies.

The commands that map to the nouns

Unit 2 covers these properly, and here is the shape:

docker pull nginx        # download an image
docker run nginx         # create + start a container from it
docker ps                # list running containers
docker images            # list images on this machine

Two facts to lock in.

1. docker run never modifies the image, because each container writes into its own private top layer.
2. Containers are disposable. Deleting one leaves the image untouched, so a fresh identical one starts in about a second.

That disposability is the workflow. A broken container is not repaired, it is killed and replaced from the known-good image.

One image, three containers

A concrete example you will meet again when we deploy in unit 8:

docker run -d --name web1 -p 8081:80 nginx
docker run -d --name web2 -p 8082:80 nginx
docker run -d --name web3 -p 8083:80 nginx

Three identical web servers from one download. Each container has its own name, its own writable layer, and its own published port, but the read-only nginx image exists once on disk. This is how real services scale out: not by installing the software three times, but by starting three instances of one image. (The -d, --name, and -p flags get full explanations in the next unit.)

Running the same image twice

Running docker run nginx twice leaves two independent containers created from the same read-only image.

Each docker run creates a new container with the same image underneath but a separate writable layer and a separate process on top.

The image itself never changes, and any number of containers can start from it. That is why scaling a service to ten replicas costs ten processes and one image rather than ten copies of the software.

Removing a container leaves the image

Deleting a container with docker rm does not delete the image it came from.

Removing a container deletes only that container's writable layer and its metadata. The image is a separate read-only object, so a fresh container can start from it immediately.

The asymmetry follows from which of the two is read-only and built once. Containers are disposable instances, and what they were created from stays behind for the next one.