Docker · Lesson 0001

Image vs container — and your first real run

One mental model and four CLI commands. After this, you can start, inspect, and stop a process that is isolated from your Mac — the same unit you will later ship.

Mission link: Local dev and reliable shipping both depend on one idea — the container is the running unit; the image is the package you build and move. Master the CLI for this now; production debugging lives here.

The problem Docker is solving for you

Imagine a TypeScript app, a Node runtime, and a database. Without containers, every machine must install the right versions — your Mac, CI, production. Versions drift. “Works on my machine” becomes the default failure mode.

Docker’s answer: package each piece as an isolated process with everything it needs, so the same package runs the same way on your laptop and on the server. (What is a container? — Docker Docs)

Two words you must never mix up

Image

A read-only template (package) with files, runtime, libraries, and config needed to run something. Immutable once built — change means a new image or new layers on top.

Container

A runnable instance of an image — an isolated process you can start, stop, and delete. Many containers can come from one image.

Class : object ≈ image : container.
Recipe : meal ≈ image : container.
You ship the recipe (image). You eat the meal (container). Production runs meals; registries store recipes.

Definitions paraphrased from Docker overview and What is an image?.

your Mac (host) │ ├─ Docker Engine (daemon) │ │ │ ├─ image: docker/welcome-to-docker ← package on disk / registry │ │ │ └─ container (running process) ← instance of that image │ └─ maps host :8080 → container :80 │ └─ browser → http://localhost:8080

Check: do you have the idea?

You pull nginx from Docker Hub. What did you download?

You run docker run … nginx twice. What is true?

Skill: run, list, open, stop

Do this in your terminal. Docker must be running (open Docker Desktop so the engine is up — you will still use the CLI).

Confirm the engine answers
```
docker version
```
If Client works but Server errors, the daemon isn’t running.
Start a welcome container in the background, publish a port
```
docker run -d -p 8080:80 --name lesson1 docker/welcome-to-docker
```
-d = detach (background). -p 8080:80 = host port 8080 maps to container port 80. --name = stable name for later commands. If the image isn’t local, Docker pulls it first. (official walkthrough)
List running containers
```
docker ps
```
You should see lesson1 and a port mapping like 0.0.0.0:8080->80/tcp.
Open it in the browser
```
open http://localhost:8080
```
Your Mac talks to the container only because you published the port.
Stop and remove (clean ship-minded habit)
```
docker stop lesson1
docker rm lesson1
```
Stopped containers still exist until removed. Later you’ll use --rm for throwaway runs. List everything with docker ps -a.

If port 8080 is busy

Use another host port: docker run -d -p 18080:80 --name lesson1 docker/welcome-to-docker then open http://localhost:18080. The left side of -p is always the host; the right is inside the container.

Check: flags under pressure

In -p 8080:80, what is 8080?

Which command lists running containers only?

Why this matters for shipping

Local: you just ran software without installing nginx on macOS.
Reliable: everyone (and CI) can run the same image the same way.
Maintain: docker ps / docker stop is the production debugging language.
Secure (preview): isolation is the floor, not the ceiling — later lessons cover non-root, minimal images, and less attack surface.

Primary source (read this next)

What is a container? — Docker Docs (official)

Skim the CLI section. Ignore the GUI path for now if you want — your mission is CLI-first. When you’re ready for the package side, continue to What is an image?.

Quick reference (commands from this lesson)

docker version
docker run -d -p 8080:80 --name lesson1 docker/welcome-to-docker
docker ps
docker ps -a
docker stop lesson1
docker rm lesson1