Images vs containers

The blueprint and the running thing.

Two words get used constantly and mixing them up causes real confusion, so pin them down now. An image is a read-only template: a snapshot of a filesystem plus some metadata (which process to start, which ports it uses). A container is a running instance of an image — the image’s files, plus a thin writable layer on top, plus a live process. The relationship is exactly like a program on disk versus a running process, or a class versus an object.

$ docker images                 # the templates you have locally
REPOSITORY   TAG       IMAGE ID       SIZE
nginx        1.27      a1b2c3d4e5f6   187MB
 
$ docker ps                     # the containers running right now
CONTAINER ID   IMAGE        STATUS         NAMES
7f8e9d0a1b2c   nginx:1.27   Up 2 minutes   web

One image, many containers

Because the image is read-only, you can start many containers from the same image and each gets its own writable layer and its own isolated process — they do not see each other’s changes. Run the nginx image three times and you have three independent web servers that happen to share the same starting files. This is why images are the unit you build and share, and containers are the disposable, running thing.

The container lifecycle

A container moves through a small set of states: created, running, stopped (exited), and finally removed. Stopping a container does not delete it — its writable layer and logs survive, so you can start it again or inspect what it left behind. It is only gone once you docker rm it. Understanding this saves you from the beginner surprise of “why do I have forty stopped containers.”

$ docker run -d --name web nginx:1.27   # created -> running
$ docker ps -a                          # -a shows stopped ones too
CONTAINER ID   IMAGE        STATUS
7f8e9d0a1b2c   nginx:1.27   Up 5 seconds
$ docker stop web                       # running -> exited (still exists)
$ docker rm web                         # exited -> gone for good