Skip to content
Docker
Lab 1 of 11·20mBeginner

Run your first container and inspect it

Start a container, get a shell inside it, and prove from the host that it is an ordinary process.

You need

  • Docker Engine 24+ or Docker Desktop
  • A terminal

The single idea worth taking from this lab: a container is a normal process on your machine that has been given a different view of the filesystem, the network, and the process table. Everything else about Docker follows from that.

1. Run a container and get a shell

docker run --rm -it --name lab-alpine alpine:3.20 sh

--rm deletes the container when it exits, -it attaches your terminal, and sh replaces the image's default command. You are now at a prompt inside the container.

Look at the process table from in there:

ps aux

You will see two or three processes, and your shell is PID 1. A fresh Linux install has hundreds.

Verify

ps aux | wc -l # 3 or 4 lines, not hundreds: # the container has its own process namespace

2. Prove it is a process on the host

Leave that shell running and open a second terminal on your host. Ask the host what it thinks is running:

docker inspect --format '{{.State.Pid}}' lab-alpine

That is a real host PID. Point ps at it:

HOST_PID=$(docker inspect --format '{{.State.Pid}}' lab-alpine)
ps -o pid,comm -p "$HOST_PID"

The host sees sh as an ordinary process. Inside the container it was PID 1; on the host it has some large number. Same process, two views.

Verify

ps -o pid,comm -p "$HOST_PID" # one row, command `sh`, with a host PID that is not 1

On Docker Desktop for macOS and Windows the engine runs inside a Linux VM, so this ps finds nothing — the host PID is real, but it belongs to the VM rather than your laptop. The point still holds; to see it directly, run this lab on a Linux host.

3. Show the filesystem is separate

Back in the container shell, write a file:

echo "written inside the container" > /tmp/lab-note
cat /tmp/lab-note

On the host, look for it:

cat /tmp/lab-note

The host has no such file. The container's root filesystem is a separate layer stack that disappears when the container is removed.

Verify

cat /tmp/lab-note # on the host: "No such file or directory" # that failure is the expected result

4. Watch the writable layer disappear

Exit the container shell:

exit

Because you passed --rm, the container is gone, and so is the file you wrote. Run a fresh one:

docker run --rm alpine:3.20 cat /tmp/lab-note

It fails. The image is immutable; anything a container writes lives in a thin writable layer on top, and that layer is per-container and disposable. This is the single most common surprise for people new to containers, and the reason volumes exist.

Verify

docker ps -a --filter name=lab-alpine # only the header row — no container survived

Clean up

docker image rm alpine:3.20

Where this goes next

You now know that an image is a read-only stack of layers and a container is a process with a disposable layer on top. The next lab uses that directly: a multi-stage build exists precisely because you get to choose which layers end up in the final image.