Right now you have three or four containers on your machine and you can still keep them all in your head. A month from now you will have thirty: the four Aurora Libros services, half a dozen forgotten experiments, containers from other projects and a pile of weeks-old Exited ones taking up disk and names. Without management tools, that docker ps -a turns into a wall of text you cannot read, and the mass docker rm you run at eleven at night takes down something you needed.

This is the day-to-day operations lesson. You are going to squeeze docker ps for everything it has —column by column, with its filters and its templates—, you are going to build a control panel for the four Aurora Libros services, you are going to learn to compose commands with -q to operate on dozens of containers without wrecking anything, to copy files between the host and a container with docker cp —which is how you will finally fill the books table with the eight titles—, to see with docker diff what a container has changed with respect to its image, and to understand why docker commit is a temptation you have to resist.

1. docker ps: the seven columns, one by one
2. Listing options: -a, -q, -s, -n, -l
3. Filtering with --filter
4. Formatting with --format and Go templates
5. Labels: organizing the fleet with --label
6. Composing commands with -q (and doing it sensibly)
7. Deleting containers: rm, -f, -v and container prune
8. Renaming and changing things live: rename and update
9. docker cp: moving files in both directions
10. docker diff: what has changed with respect to the image
11. docker commit and why you should not use it
12. The Aurora Libros control panel

Two observations about the output above, which double as a review:

• aurora-cache says Up 4 minutes and not Up 32 minutes because you restarted it in the previous lesson: the STATUS counter resets to zero on every start, while CREATED does not move.
• The (healthy) on aurora-cache does not appear by magic: the official Redis 7 image ships its own HEALTHCHECK. aurora-db shows nothing because the PostgreSQL image does not define one. Health is studied in depth in lesson 03-04.

To see the complete command:

This column has two numbers, and the difference between them is lesson 01-05 turned into a command:

• The first (0B, 127kB) is the writable layer: what that container has written on top of the image. It is the only thing that belongs exclusively to it and the only thing lost when you delete it.
• The virtual figure is the total size the container sees: its writable layer plus all the image's layers, which are shared and read-only.

Ten redis:7-alpine containers do not take up 412 MB, but 41.2 MB plus ten tiny writable layers. And aurora-db with its 127 kB of writes stands out: you have just created an entire database, so where is the data? In an anonymous volume that the official image declares, and which does not count as a writable layer. Hold on to that question: it is the heart of lesson 03-06.

--filter (or -f) accepts key=value pairs and can be repeated. The available filters:

Recipes ready to copy:

A real example:

Two warnings about how filters behave:

• Several different --filter flags combine with logical AND. --filter status=running --filter name=aurora demands both conditions.
• Several values of the same filter combine with logical OR. --filter status=exited --filter status=created returns those in either state.
• name is a substring, not an equality. --filter name=aurora-db also finds aurora-db-copy. If you need an exact match, use an anchored expression: --filter name=^aurora-db$.

--format uses Go language templates, the same ones you already used with docker image ls in lesson 02-05.

The word table at the beginning turns on the header and column alignment:

Without table, the output is free text, perfect for scripting:

And there are two prebuilt formats that come in very handy:

If you like a format, make it permanent in ~/.docker/config.json:

From that moment on, a plain docker ps uses your format. It is one of the tweaks that day-to-day use appreciates most.

When containers from three projects share the same machine, filtering by name stops being reliable. Labels are arbitrary metadata you assign when creating the container:

And then you filter by them with surgical precision:

--filter label=key=value demands the exact value; --filter label=key only demands that the label exists.

Let's properly label the Aurora Libros fleet. Since labels, just like ports and variables, are frozen when the container is created and cannot be added afterwards (lesson 03-01), we have to recreate them. That is fine: aurora-db has no data to lose yet.

A labeling convention that works well and that we will use throughout the course:

With these three labels, operations like "stop everything from Aurora Libros in local without touching anything else" become trivial, and it is exactly what Docker Compose will do for you automatically in module 4: its com.docker.compose.project labels are this very mechanism.

docker ps -q prints only IDs, and that turns it into the input for any other command:

Recipes used daily:

And now the three precautions, because these commands are sharp:

First: if the filter finds nothing, the command fails.

Annoying but harmless. You avoid it by checking first:

Second: docker rm -f $(docker ps -aq) is the most dangerous command in this lesson. It deletes absolutely every container on the machine, including those from other projects, and without asking. If you need to clean up, do it scoped:

Third: look before you shoot. The golden rule is to run the listing-only version first:

That extra half-second has saved a lot of development databases.

docker rm only works on stopped containers. With a running one:

About -f, an important nuance that connects with the previous lesson: docker rm -f is not docker stop + docker rm. It sends SIGKILL directly, with none of the ten seconds of grace. On a database, that is unplugging the server. The correct sequence when data is involved is:

What exactly happens when you delete a container:

It deletes all stopped containers. It is worth repeating the warning from lesson 02-05: a stopped container may be something you were debugging or a development database you switched off yesterday. Scope it whenever you can:

You already saw docker rename in the previous lesson. Its companion is docker update, which can change things on a running container, though a very specific list of them:

The detail of all those resource options and of the restart policies is the content of lesson 03-07; what matters here is remembering the boundary: update touches what lives in the cgroups; everything that lives in the namespaces (network, mounts, environment) is frozen when the container is created.

One of the two sides carries the container: prefix and the other is a host path. It works in both directions and also with stopped containers.

The time has come to fill the database. You have had ~/aurora-libros/db/init.sql since lesson 01-07, with the books table and the eight titles:

And now run it inside the container:

Check the result:

The eight Aurora Libros books are in a real database, in a real container. It is the first time in the whole course that they exist outside a .sql file. Nobody can read them from the API yet —that comes in lesson 03-05— but they are there.

A note on method: loading the schema by hand with docker cp works but is not the right way, because you have to repeat it every time you recreate the container and nobody ever remembers to. In lesson 03-06 you will solve it properly, mounting init.sql into /docker-entrypoint-initdb.d/ so that PostgreSQL runs it by itself when it initializes.

The reverse direction is just as easy and turns out to be essential when investigating an incident:

And a very common case: rescuing the log of an application that —against all good practice— writes to a file instead of to standard output.

Details of how docker cp behaves that save you surprises:

That last point bites often: if you copy a file into a container running with USER node, the file will belong to root and the application may not be able to read it. And one clear limitation: docker cp cannot copy from one container to another directly; you have to go through the host.

docker diff compares the container's current file system with that of the image it came from:

Three letters and their meaning:

It is the visible manifestation of the copy-on-write from lesson 01-05: what you see here is exactly the contents of the writable layer, which is why docker diff and the SIZE column of docker ps -s are talking about the same thing.

And now the important observation:

Not one line. You have just created a table and eight records, and PostgreSQL's data directory does not appear in the diff. The reason is that /var/lib/postgresql/data is not in the writable layer: the official image declares a VOLUME there, so Docker created an anonymous volume and mounted it at that path. And docker diff never looks inside mounts.

This is exactly what lesson 02-04 was anticipating when it talked about why VOLUME in a Dockerfile has side effects, and it is the doorway into lesson 03-06: there is data that lives neither in the image nor in the writable layer, but in a third place. A place that right now, for aurora-db, is anonymous and fragile.

A very practical use case for docker diff: finding out what an application you do not trust writes.

In ten lines you know that Nginx modifies its configuration at startup (its docker-entrypoint.sh does it), creates a PID file and several cache directories. That is invaluable information when you are about to make the file system read-only for security, something you will see in lesson 05-03.

docker commit turns a container's current state into a new image:

It works. And that is precisely why it is dangerous. These are the reasons images are not built this way, picking up the whole of module 2:

In the trade's vocabulary, an image like that is called a hand-crafted image or a snowflake, and it is the containerized equivalent of that server nobody dared reboot. It does have one legitimate use:

Preserving the crime scene before cleaning it up. For that, yes, and for nothing else.

We close by putting everything from the lesson into a command you will use daily:

Turn it into a permanent alias in your ~/.bashrc or ~/.zshrc:

And a version with health and size, for when something goes wrong:

Notice that aurora-db's writable layer has grown from 127 kB to 3.14 kB… hold on, it has gone down. What is happening is that the container is new: you recreated it when you added the labels, and those 3.14 kB are almost entirely the init.sql you copied with docker cp. The data of the eight books is not there, but in the anonymous volume we were talking about. One more reminder that there is a piece of the puzzle you have not placed yet.

• Running docker rm -f $(docker ps -aq) "to clean up". It takes everything on the machine with it, including containers from other projects and development databases with weeks of data. Always filter by label or by name.
• Trusting --filter name= as if it were an equality. It is a substring: name=aurora-db also finds aurora-db-backup. Anchor it with ^...$ when it matters.
• Reading the CREATED column as "started ago". It is the creation date. For uptime, look at STATUS or {{.RunningFor}}.
• Reading the virtual size as space used. Ten containers from the same image share its layers: the real disk usage is the sum of the writable layers plus one copy of the image.
• Using docker rm -f on a database. It is a SIGKILL with no grace. First docker stop --time 30, then docker rm.
• Forgetting -v when deleting and accumulating orphaned anonymous volumes. Every PostgreSQL container deleted without -v leaves its volume behind. You find them with docker volume ls -f dangling=true (lesson 03-06).
• Copying files with docker cp into an unprivileged container and not understanding the permission denied. The file arrives as root. Use -a, or fix it afterwards with docker exec -u root ... chown.
• Building images with docker commit. It works today and leaves you with no explanation tomorrow. The Dockerfile is the source of truth.
• Tip: save your favorite formats in ~/.docker/config.json with psFormat. A readable docker ps by default is a daily gift.
• Tip: before any mass operation, run the listing-only version. Look at the list, and only then swap ps for rm.

Create five test containers with alpine:3.20 and sleep 300, labeled like this: two with project=aurora-libros and environment=local, two with project=aurora-libros and environment=tests, and one with project=other-client. Then write a single docker ps command that shows only the Aurora Libros ones in the tests environment, in a table with the columns name, environment and uptime. Finally, stop and delete in a single command exclusively the other-client ones, leaving the rest untouched, and prove with another command that the four Aurora Libros ones are still alive.

Start a redis:7-alpine container called diff-redis. Before touching anything, run docker diff and note the result. Then write 100 keys with redis-cli, force a save to disk with redis-cli SAVE, and run docker diff again. Answer:

1. Does the Redis data file appear in the docker diff? And in the SIZE column of docker ps -s?
2. Find out with docker inspect --format '{{json .Mounts}}' where that file really is.
3. Copy it to the host with docker cp and check its size with ls -lh.
4. Delete the container with docker rm -f (without -v) and explain exactly what has happened to those 100 keys. Are they lost? Where are they?

Simulate the end of a chaotic working day:

1. Create six containers that end immediately: three with code 0 (alpine:3.20 true) and three with code 1 (alpine:3.20 sh -c 'exit 1'), all with the label project=cleanup-tests.
2. Write a command that lists only the ones that failed, with their name and their state.
3. From one of the failed ones, extract the file /etc/os-release to the host with docker cp before deleting it.
4. Delete in a single command only the ones that failed, leaving the three successful ones.
5. Finally, clean up the rest with docker container prune scoped to the label, and verify that neither aurora-db nor aurora-cache has been affected.

Solution to exercise 1

The panel command, with two filters combined with logical AND:

The environment=local ones do not appear: they meet the first filter but not the second, and both must be met.

Surgical deletion of other-client:

The four Aurora Libros ones are still standing. The sequence look → act → check is what turns a dangerous command into a routine operation.

Solution to exercise 2

Practically nothing: a freshly started Redis only writes its PID file. Now, load and save:

1. Here is the exercise's surprise: dump.rdb exists (you have just listed it with ls -lh, 3.4 kB) but it does not appear in the docker diff, and the writable layer still measures 0 B. The two tools agree with each other and both are telling the truth: that file is not in the container's writable layer.

2. The explanation is in the mounts:

The official Redis image declares VOLUME /data, so Docker created an anonymous volume —that name that looks like a hash is exactly that: a volume with no name— and mounted it at /data. Everything Redis writes there goes to the volume, not to the writable layer, and that is why docker diff does not see it.

3.

docker cp does read through mounts: as far as it is concerned, /data/dump.rdb is simply a path in the container's file system. The 3.4 kB match the ls from inside; the 5.63 kB Docker reports is the size of the tar stream used to make the copy, with its headers and its block padding.

4.

The correct answer is more interesting than a plain "they are lost":

• The keys that were in memory died with the process, as in the previous lesson's exercise.
• But the dump.rdb with the 100 keys still exists, in a volume that is now orphaned: with no container using it, with a name nobody remembers and taking up disk indefinitely. Since you used docker rm -f without -v, the volume was not deleted.
• If tomorrow you start another redis:7-alpine, Docker will create a new, empty anonymous volume: it will not reuse the previous one. From a practical point of view, the data is lost even though the bytes are still on your disk.

That is exactly what is happening today to aurora-db with the eight books you just loaded, and it is the problem lesson 03-06 solves by giving the volume a name.

Solution to exercise 3

2. Listing only the ones that failed, combining status and exited:

The exited=1 filter is what does the fine work: it distinguishes "it ended" from "it ended badly", something status=exited alone cannot do.

3. Rescuing a file from a stopped container:

An important detail: docker cp works with the container stopped. There is no need to start it, and that makes it the ideal tool for performing autopsies on containers that no longer come up.

4. Selective deletion of the failed ones:

The three successful ones are still there. No -f was needed because they were already stopped.

5. Final scoped cleanup and verification:

aurora-db and aurora-cache untouched, because the --filter label= scoped the prune to the right label. Compare mentally with what would have happened with a plain docker container prune -f: the three ok-* would have gone the same way, but so would any stopped container from any other project on your machine. Labels are not bureaucracy: they are the mechanism that makes cleanup selective instead of indiscriminate.

You no longer look at docker ps: you read it. You know what each of its seven columns says and, above all, what it does not say —that CREATED is not the start time, that IMAGE may have gone stale if the tag moved, and that the virtual number from -s is not space used but space seen—. You know how to filter by state, name, image, label, exit code and health, combining filters with AND and with OR, and you know how to shape the output with Go templates until it becomes an Aurora Libros control panel that fits in an alias.

You have learned to compose commands with -q and, more importantly, to do it with a safety net: look → act → check, always filtering by label so that a mass deletion never takes something that was not its business. You know the difference between docker rm and docker rm -f —which is not stop + rm, but a SIGKILL with no grace—, you know what is destroyed and what survives when a container is deleted, and you use docker container prune scoped with until and label instead of bare. You have labeled the fleet with project, component and environment, which is exactly the mechanism Docker Compose will automate for you in module 4.

With docker cp you move files in both directions, even with the container stopped, and that has got you something memorable: the eight Aurora Libros books are loaded into PostgreSQL, with their table, their index and their INSERT 0 8. With docker diff you know how to see the writable layer turned into a list of files —A, C and D— and you have discovered the missing piece: PostgreSQL's data directory does not appear in the diff, because it is not in the writable layer but in an anonymous volume that the image declares and nobody controls. And you know why docker commit is no good for building images, even though it is perfect for freezing a crime scene before cleaning it up.

You know how to watch the fleet when everything is fine. The other half is missing. In the next lesson, Inspecting and Debugging Containers, you will face the containers that do not work and do not say why: you will read docker logs in depth with its time filters and its golden rule about stdout, you will get in with docker exec even into minimal images that do not have so much as ping —using ephemeral containers that share their namespaces—, you will squeeze the JSON out of docker inspect with templates and jq, and you will watch live with docker top, docker stats and docker events. And you will apply all of it to three real Aurora Libros breakdowns, among them the one that has been waiting for two lessons: why aurora-api cannot find aurora-db even though both are running on the same machine.