Lesson 2 of 6

Images & Containers

Docker has exactly two nouns you need to get straight, and mixing them up is the #1 source of early confusion. An image is the frozen, read-only package — the recipe plus all the ingredients. A container is a running instance of that image — the actual meal. One image can feed as many containers as you like, and throwing a container away never touches the image it came from.

💡 The Bottom Line

Image = the blueprint (immutable, shareable, stored in a registry). Container = a live, disposable instance of that blueprint (started, stopped, and deleted freely). You pull and build images; you run, stop, and remove containers.

Where images come from: registries

Images live in a registry — a shared library of published images. The default one is Docker Hub, which hosts official images for practically everything: nginx, postgres, python, node, redis. Pull one down:

docker pull nginx:1.27

The part after the colon is the tag — usually a version. If you skip it, Docker assumes :latest, which sounds convenient but means "whatever was newest at the time," a moving target. Real projects always pin a tag.

Running your first real container

docker run -d --name web -p 8080:80 nginx:1.27

Reading that flag by flag:

-d — detached: run in the background instead of taking over your terminal.
--name web — a human name, so you can say web instead of a random ID.
-p 8080:80 — map port 8080 on your machine to port 80 inside the container. Open http://localhost:8080 and Nginx answers.

If the image isn't on your machine yet, docker run pulls it automatically — pull then run in one step.

The everyday management commands

docker ps              # list running containers
docker ps -a           # include stopped ones
docker logs web        # what has this container printed?
docker exec -it web sh # open a shell *inside* the running container
docker stop web        # graceful stop
docker rm web          # delete the (stopped) container
docker images          # list images on this machine
docker rmi nginx:1.27  # delete an image

🙋 There Are No Dumb Questions

Q: If I delete a container, do I lose my data?
A: Any data written inside the container's own filesystem — yes, gone. That's by design: containers are meant to be disposable. Data that must survive belongs in a volume, which is exactly what Lesson 4 covers. Until then, treat every container as something you could delete without regret.

⚠️ Watch Out

docker ps only shows running containers. A container that crashed or exited is invisible to it — which makes beginners think it vanished. It didn't: docker ps -a shows it, and docker logs <name> usually shows why it stopped. Make -a a reflex whenever a container "disappears."

🔧 Try It Yourself

Run the Nginx example above, confirm http://localhost:8080 serves the welcome page, then look around inside it:

docker exec -it web sh
ls /usr/share/nginx/html
exit

Finish by cleaning up with docker stop web && docker rm web — and notice that docker images still lists nginx:1.27, ready to launch again instantly.

✅ Quick Check

You run the same image three times with different names. What do you have?

Next up: where images actually come from — writing your own Dockerfile and building an image of your own app.

← Back to