You know what Docker is, you have it installed and you understand its architecture. Now it is time to learn how to talk to it. The good news is that the Docker CLI is not an arbitrary collection of commands to be memorized: it is organized around exactly the four object types you saw in the previous lesson, with a regular, predictable grammar. If you understand that grammar, you can work out most commands without looking them up. In this lesson you will see the anatomy of the modern CLI and its historical aliases, the built-in help system (which is your best reference and is always up to date), the essential commands for images, containers and the system, a complete annotated session from start to finish, and how to tame the output with --format and --filter so that it gives you exactly what you need.

1. The anatomy of the modern CLI
2. Short aliases: the historical syntax
3. The help system
4. Essential image commands
5. Essential container commands
6. System commands
7. A complete annotated session
8. Formatting the output with --format
9. Filtering the output with --filter

Docker's modern CLI follows a three-part structure:

• object: what kind of thing you are acting on. They are the daemon's objects: image, container, volume, network, plus a few management ones (system, context, builder).
• action: what you do to it. The vocabulary repeats across objects: ls, rm, inspect, prune, create.
• options and arguments: modifiers and the specific object.

Examples that illustrate the regularity:

All four list; only the type changes. And the same goes for deleting:

This table of common actions applies to almost every object:

The practical takeaway: do not memorize commands, memorize the grammar. If you need to list volumes and have never done it, docker volume ls is the obvious guess and it is correct.

Before the reorganization by object, the commands were flat: docker ps, docker images, docker rmi. Docker kept them for compatibility, and in practice everyone still uses them because they are shorter to type. You will see both forms constantly, in documentation and in real work.

A couple of warnings about the table:

• docker rm and docker rmi look dangerously alike. rm deletes containers; rmi deletes images. One letter apart, with very different consequences.
• docker inspect without an object is ambiguous: it first looks for a container with that name or ID and, failing that, an image. When you want certainty, use the long form.
• docker build versus docker buildx build: in current versions, docker build already uses BuildKit underneath. The explicit docker buildx build form is the recommended one in 2026 and the one we will use from module 2 onwards.

A recommendation for this course: understand the long form, use the short one. Typing docker ps is perfectly professional; what is not professional is not knowing it is equivalent to docker container ls.

Docker's CLI documents every command and option. This help is always in sync with your installed version, something no website can guarantee.

It shows the command groups by object (Management Commands) and the standalone commands (Commands), which are the aliases from the previous section.

It lists every action available on containers: attach, commit, cp, create, diff, exec, export, inspect, kill, logs, ls, pause, port, prune, rename, restart, rm, run, start, stats, stop, top, unpause, update, wait.

Here is the detail for each option. It is an extremely long output —run has dozens of options— which is why it pays to filter it:

What this command does: it pipes the help into grep -i (case-insensitive search) so you keep only the lines mentioning "publish". It is the fastest way to recall an option whose letter you have forgotten.

Two more reference commands:

You already know them; docker system info is simply the long form of docker info, and it confirms that info also fits the object-action grammar.

Let's see them in action:

You already know how to read this from lesson 01-02: one layer downloaded, the digest that identifies the image immutably, and on the last line the full name Docker resolved (docker.io/library/alpine:3.20), confirming what you saw about default registries.

Column by column:

• REPOSITORY: the image's repository name.
• TAG: the tag, the "version". latest is just another tag name (lesson 01-05).
• IMAGE ID: short identifier (the first 12 characters of the digest). It is what you will use to refer to the image when it has no name.
• CREATED: when the image was built, not when you downloaded it. hello-world saying "9 months ago" is normal.
• SIZE: uncompressed size. Careful: these sizes do not simply add up if the images share layers, something you will see in detail in lesson 01-05.

Note the difference between the lines: Untagged means a name pointing at the image has been removed; Deleted means the layers have actually been erased from disk. If another image or a container were still using those layers, you would only see Untagged.

A very common error shows up if a container (even a stopped one) uses the image:

The reading is literal: there is a container using that image. Delete the container first.

Advanced image management (tagging, exporting, fine-grained cleanup) is covered in lesson 02-05.

The most important conceptual point of this section:

docker run creates a NEW container every time. It does not reuse the previous one. To start an existing one again you use docker start.

That confusion is the number one reason beginners end up with dozens of stopped containers.

Each column:

• CONTAINER ID: short identifier. You can use a unique prefix (3f2a would do).
• IMAGE: which image it was born from.
• COMMAND: the main process it runs, truncated.
• STATUS: the key piece of data. Up 2 minutes = running. Exited (0) = finished, and that 0 is the exit code: 0 means it ended cleanly; any other number indicates an error (Exited (137) is usually death by out-of-memory or kill).
• PORTS: active port mappings. 0.0.0.0:8080->80/tcp reads as "the host's port 8080, on any interface, goes to the container's port 80".
• NAMES: the name. If you do not set it yourself with --name, Docker invents a whimsical one (nervous_hopper).

When it comes to stopping containers, it is worth knowing the difference:

• stop sends SIGTERM to the main process and waits 10 seconds for it to shut down cleanly; if it does not, only then does it kill it with SIGKILL. This is the correct way.
• kill sends SIGKILL straight away: immediate death, with no chance to close connections or save anything.

Always use stop unless the container is hung. The complete lifecycle with all its states is studied in lesson 03-02, and the docker run options in depth in 03-01.

prune deserves care, because it is destructive:

Always read the list before typing y. Important notes:

• The version without -a is reasonably safe: it deletes stopped containers (which you may have wanted to keep, but rarely matter) and dangling images, that is, untagged ones, which are usually leftovers from earlier builds.
• The version with -a is aggressive: it deletes every unused image. Afterwards you will have to download everything again. On a laptop it is a good last resort when disk is tight; on a production server, think twice.
• --volumes is the most dangerous: volumes contain data. Deleting Aurora Libros' database volume by mistake means losing the catalog.

You can skip the question with -f, but in this command in particular the confirmation is your safety net.

Let's walk through a session from start to finish, beginning and ending with a clean system. Run it yourself as well.

Step 1. Starting point.

If you have just installed Docker, you will see only the table headers, with no rows. If you ran the hello-world from lesson 01-02, you will have that image and one or two stopped containers.

Step 2. A container that does one thing and dies.

You already know the output. What is interesting comes now:

Empty. The container printed its message and its process ended, so it is no longer running. But:

There it still is, stopped, taking up space. This is the most important lesson of the session: a container that finishes does not disappear.

Step 3. Pulling an image and running a specific command.

What happened: Docker created a container from alpine:3.20, replaced the image's default command with echo "Hello from Aurora Libros", ran it, and when the process finished the container moved to Exited (0). Everything after the image name is the command to run inside.

Step 4. Several containers from the same image.

Two extremely valuable observations:

• uname -a shows the host's kernel (6.8.0-52-generic, an Ubuntu kernel). It confirms with your own eyes what lesson 01-01 said: the container shares the host's kernel.
• cat /etc/os-release says "Alpine Linux". In other words: Ubuntu kernel, Alpine user space. That is a container.

And now:

Four stopped containers from three Alpine docker run commands plus the hello-world. Each run created a new one. That --format you just used is explained in section 8.

Step 5. Viewing the logs of an already finished container.

Even though the container is stopped, its output is preserved. This is a fundamental diagnostic tool: if a container dies on startup, docker logs tells you why.

Step 6. Cleaning up.

rm accepts several names or IDs and returns the ones it deleted. To delete them all at once:

container prune removes all stopped containers; -f skips the confirmation (it is safe here because you already know what is there). Check:

An empty table. The images, on the other hand, are still there:

Deleting containers does not delete images. Once again: image and container are different objects.

The default tables are wide and bring columns you often do not care about. --format accepts Go language templates so you can choose for yourself.

Table mode, keeping headers:

The word table at the beginning turns on tabular formatting with headers; {{.Field}} inserts a field; \t separates columns.

Free-line mode, without headers, ideal for scripts:

JSON mode, for processing with other tools:

The most useful available fields:

A practical example you will use a lot: getting just the IDs so you can pass them to another command.

-a (all) combined with -q (quiet, IDs only). And its typical use:

How it works: $(...) runs the inner command first and substitutes its output as arguments to the outer one. The result is "delete every stopped container". Careful: if any container is running, rm will complain about that particular one and delete the rest. And if the list is empty, docker rm will protest about missing arguments, which is harmless.

While --format decides which columns you see, --filter (or -f) decides which rows.

The most useful container filters:

What each one does:

• status=exited: only the finished ones. Other values: running, paused, created, restarting, dead.
• name=aurora: those with "aurora" in the name (it is a substring match, not an exact one). Very handy with the Aurora Libros naming convention.
• ancestor=alpine:3.20: those created from that image.
• exited=1: those that finished with exit code 1, that is, the ones that failed. Pure gold for diagnostics.

Image filters:

• dangling=true: untagged images, leftovers from builds. They are the ones docker image prune deletes.
• reference=alpine:*: those matching that name pattern.
• before=nginx:alpine: those created before that image.

And now everything combined, which is where the CLI shines:

Translation: "show me, in a table with name, image and status, every container that finished with an error". Two filters combine with a logical AND.

Another example aimed at our project:

"Delete every stopped container whose name contains aurora", without touching the rest of your system. When in the coming modules you have aurora-api, aurora-db, aurora-cache and aurora-web living alongside other experiments, this pattern will save you grief.

• Using docker run to resume a container. run always creates a new one. To resume, docker start <name>. If you find yourself with 30 identical stopped containers, this is the cause.
• Confusing docker rm with docker rmi. The first deletes containers, the second images. If in doubt, use the long forms docker container rm and docker image rm.
• Running docker system prune -a --volumes without reading the warning. You can wipe a development database's data in a second. Always read the list of what it is about to remove.
• Believing stopped containers take up no space. They do: their writable layer, their logs and their metadata. Check it with docker system df.
• Forgetting -a in docker ps. "I have no containers" usually means "I have no running containers". When in doubt, docker ps -a.
• Tip: always name your containers with --name. Random names are impossible to remember. With the aurora-api, aurora-db and so on convention, name filters work by themselves.
• Tip: use ID prefixes. You do not need the full ID: the first few characters are enough if they are unique. docker stop 3f2a works.
• Tip: --help before Google. The built-in help matches your version exactly; blog posts often do not.

Rewrite these commands in the modern docker <object> <action> form and explain what each one does:

Then answer: what exactly does the -f option do in the last two commands? Does it mean the same thing?

Set up the scenario by running:

Now, using --filter and --format:

1. List in a table (name, image, status) only the containers whose name contains aurora.
2. Find out which of them finished with an error, without reading status by status.
3. Delete in a single command only the stopped containers whose name contains aurora, leaving something-else untouched.
4. Verify that something-else is still there and that the images have not been touched.

Answer with commands, not from memory:

1. How much total space do your images take up, and how much could you reclaim?
2. Which specific image is the largest one you have?
3. If you ran docker system prune (without -a), what exactly would be deleted on your system right now? Find out before running it.

Solution to exercise 1

About -f: it does not mean the same thing in both cases, and it is a classic source of confusion.

• In docker logs -f, -f is --follow: it does not close the output, it stays listening and shows new lines as they appear (like tail -f). You exit with Ctrl+C, which does not affect the container.
• In docker rm -f, -f is --force: it kills the container if it is running and then removes it. Without -f, docker rm on an active container returns an error asking you to stop it first.

The moral: option letters get reused with different meanings depending on the command. When in doubt, --help.

Solution to exercise 2

(The name=aurora filter matches substrings, so only aurora-test-1 and aurora-test-2 show up.)

The exited=1 filter selects by exit code. aurora-test-2 ran sh -c "exit 1", which finishes with code 1, hence it is the only one that appears. This is far quicker than reading the STATUS column of a long list.

Breakdown: the inner command docker ps -aq --filter ... --filter ... returns only the IDs (-q) of the stopped containers whose name contains "aurora". The $(...) substitution passes them as arguments to docker rm. Since something-else does not match the name filter, it never enters the list and survives.

You will see only something-else in the container list, and alpine:3.20 untouched among the images. Deleting containers never deletes images.

Solution to exercise 3

Read the Images row: the SIZE column is the total occupied and RECLAIMABLE is what you would free by removing the images no container uses. The percentage in parentheses gives you the proportion at a glance.

--format produces one line per image with size and name; sort -h -r sorts by human-readable size (-h understands "MB", "GB") from largest to smallest (-r); head -5 keeps the first five. The first line is your largest image.

The reasoning: docker system prune without -a removes four things, so you inspect them separately first: the stopped containers (first command), the untagged dangling images (second), the networks not used by any container (third; the default bridge, host and none networks are never deleted) and the build cache (fourth, which shows how much it takes up). With that picture in hand you know exactly what you are about to lose before confirming with y.

Docker's CLI is not memorized, it is deduced: docker <object> <action> [options], where the objects are the ones the daemon manages (image, container, volume, network, system) and the actions repeat across them (ls, rm, inspect, prune). The historical aliases —docker ps, docker images, docker rmi— are still the usual way to write them, and now you know what they correspond to.

You take away the essential commands for images (pull, images, rmi), for containers (run, ps, ps -a, stop, start, rm, logs) and for the system (info, system df, system prune), plus two ideas that will prevent half your future stumbles: docker run always creates a new container, and a container that finishes does not disappear. On top of that, with --format and --filter you can ask Docker for exactly the rows and columns you need, which becomes indispensable the moment you have more than three or four objects on your hands.

In the hands-on session you saw something revealing: an Alpine container showing the host's Ubuntu kernel. That Alpine filesystem, packaged and downloaded in seconds, is an image, and you still do not really know what is inside it. In the next lesson, Understanding Docker Images, you will open that box: layers, copy-on-write, digests, tags, base images, and why latest does not mean what you think.