Why is the worker not in docker ps?

It stops as soon as it starts, because its setting is missing, and docker ps lists only what is running. docker ps -a lists stopped containers too, and docker logs worker still prints what it said.

Which docker commands work in the lab’s terminal?

docker ps, docker logs, docker exec, docker restart and a few more that only look at the three containers, such as docker inspect. Nothing can be created, pulled, built or removed, and docker volume and docker network are refused.

What is still there after I stop and start the lab?

The named volume that holds /settings, so a fixed worker comes up healthy at once. The files a student wrote anywhere else inside a container are gone.

Docker basics lab: learn containers, logs and restarts by fixing a broken service

This lab teaches what a container is by giving each student three of them, one broken on purpose: a web page, a queue and a worker that stops as soon as it starts. The student finds out why with docker ps and docker logs, looks around inside a healthy neighbour with docker exec, fixes the setting that was missing and starts the worker again with docker restart.

It is not an attack lab. Every copy has no route to the internet and none to any other student, and the terminal’s docker works only on the three containers of the student’s own copy.

What students learn

What a container is and what the columns of docker ps say, including that a stopped container is still there until it is removed and shows only with docker ps -a. How to read a service’s log to find out what is wrong, how to run a command inside a running container, and how to restart one. And the idea the lab is built around: a container’s own files survive a restart but are gone when the lab stops, while a named volume is kept. It suits an introduction to containers in a computing, networking or DevOps unit.

Run it in your browser

The lab starts the web page and the queue and waits until both are healthy. The worker is then started and stops at once, which is the exercise: it is expected to be the one that is not running.

Open the Container page. Open Build on the bar and choose Run a container. Anybody may open it, and the Git lab and the SQL lab start with no account. Every other lab needs a free account: create one, sign in, then press Start.
Find the lab. The Sample labs card lists every sample. Find Docker basics.
Press Start. Start runs it as it is, in one press. Edit the file first opens the compose file so you can change it before you start.
Open it. On the lab’s page, press Open terminal and type docker ps -a. The worker says Exited (1). docker logs worker says why: its settings file, /settings/worker.conf, has no QUEUE_HOST line. Add QUEUE_HOST=cache to it from a shell inside web (docker exec -it web sh), run docker restart worker, and docker ps shows it Up and healthy. The link called Docker basics page under In your browser shows the page web serves.

What to ask students to hand in

The output of docker ps -a before the fix and after it, the line of the log that told them what was wrong, and a sentence saying which of the files they wrote would survive the lab stopping and why. The last one shows whether they understood a container’s own filesystem against a volume.

A basic lesson on this lab

Docker Basics is a small lesson worked in this lab. In it a student lists the containers with docker ps -a, reads the worker’s log, prints the settings file from inside web, adds the missing line, restarts the worker, and sees it healthy. They then stop and start the lab to see that the fix was kept in the named volume.

Free personal accounts have it in the Basics module, which is on Home, every college can copy it from the Library’s Basics folder, and a new college opens with it in a module called Lab Basics (Sample). It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

The code on GitHub

The compose file has no Dockerfile: it runs two stock public images, nginx and Valkey, both pinned to a version, and writes what each service does in its own entrypoint, so all of it can be read in one file. The nginx image is licensed BSD-2-Clause and Valkey BSD-3-Clause; neither is distributed by us. A student can never create, pull, build or remove a container in a lab, so the lab does not ask for it; those commands work on your own machine.

Set it as work

Say in the task what to hand in.

Make the lab. In your module add a task and choose the Container lab card, then In a GitHub repository. Give https://github.com/mitsurutech/lab-docker-basics with the branch main. The compose file is the default, compose.yaml. Fork the repository first if you want to change it.
Publish and try it. Publish pins the commit you were shown, so a later change in the repository does not alter a lab you have already set. Start your own copy first.
Hand it out. Assign it like any task, with a due date if you want one, and say in the task what to do and what to hand in.
Mark what is handed in. Open a student’s copy and the work they handed in, mark it, and send it back with a reason if it needs more.

Questions people ask

Why is the worker not in docker ps?: It stops as soon as it starts, because its setting is missing, and docker ps lists only what is running. docker ps -a lists stopped containers too, and docker logs worker still prints what it said.
Which docker commands work in the lab’s terminal?: docker ps, docker logs, docker exec, docker restart and a few more that only look at the three containers, such as docker inspect. Nothing can be created, pulled, built or removed, and docker volume and docker network are refused.
What is still there after I stop and start the lab?: The named volume that holds /settings, so a fixed worker comes up healthy at once. The files a student wrote anywhere else inside a container are gone.

Create a free account to run every lab.