Your first container

One command, then everything that command quietly did on your behalf.

~

# Run the hello-world image. If it is not on your machine yet, Docker will fetch it.

Command$↵

What just happened

The CLI is a thin client. It handed your request to the Docker daemon over a local socket and did little else.

The daemon looked for the image on disk, did not find it, and pulled it from Docker Hub. From that image it built a container: a writable layer, a set of namespaces, and a cgroup to hold them. Then it started whatever process the image declares as its entrypoint, streamed that process's stdout back to your terminal, and waited.

When the process exited, the container stopped. It was not deleted, however, and that distinction costs people disk space for months.

Seeing what is running

~

# List the containers that are currently running.

Command$↵

Add -a and you will see the stopped ones too, including the hello-world you just ran. Remove that one with docker rm <id>. There is also docker container prune, which deletes every stopped container on the machine, so read the confirmation prompt before you agree to it.

The flags worth knowing on day one

Combined, the shape you will type most often:

docker run --rm -it --name scratch ubuntu:24.04 bash

Stopping things

docker stop <name> sends SIGTERM by default, waits ten seconds, then sends SIGKILL. Both parts are configurable: STOPSIGNAL in the Dockerfile or --stop-signal changes the first signal, and --time changes the wait.

Stopping the course sample project, which closes its server on SIGTERM, takes 0.25 s. The same image with the handler removed takes 10.3 s, because the timeout has to expire before SIGKILL arrives. Every deploy of an app that ignores the signal pays that, and shuts down ungracefully when it does. Handling the signal is your application's job, not Docker's, but Docker is where you notice it is missing.