This exam closes the "Understand what the engine does" module of the Docker course. The mission: a batch-processing container runs away at night, slows down the whole machine, ends up being killed and leaves incomplete files behind. You must contain it, that is, set limits that the kernel really enforces, prove that they hold when it runs away, and lose none of the results it has already produced. It teaches you nothing new, it checks what you learned. Allow about 45 minutes on a virtual machine running Docker Engine 29.9.2.
What you will learn
- Say what the exam expects and on which state of the system it grades you.
- Spot the lessons to review before you start.
- Work out, depending on the hints requested, the checks you must pass to reach the threshold.
- Read your result to decide whether to move on to the next module or to consolidate.
Prerequisites
The lessons of the "Understand what the engine does" module must be finished, up to the last one, Cap memory and the number of tasks of a container. The exam assumes that you know how to read what a container is for the kernel, bound its resources, and link a container to its process on the host. It also assumes an older skill, taught in Docker volumes: keep your data and mount files: attaching a named volume to a container, because a recreated container finds its data again only if you mount its volume back.
Use the lab environment you used for the previous lessons. The exam asks you to build nothing: the image of the batch job is provided, and a volume already holds results.
What does the exam ask of you?
The statement describes a container named traitement. It writes its results to a volume that already holds results, and these results cannot be reproduced. At the end, the state of the machine must show five things:
- the container carries three limits, on memory, processor and number of processes;
- when it runs away, it stays within its limit and the host loses no process;
- it still answers afterwards;
- the earlier results are intact and no file is truncated;
- a report records two facts that only the engine knows, one about the container, the other about the daemon.
No limit value is imposed. The full statement, with the name of the volume, the report file and the format of its two lines, is read in the lab, and only there.
How is it graded?
The lab does not read the commands you typed. It reads back the state of the system at the moment you hand in your work. It triggers the runaway itself, then measures what the kernel recorded. Five checks of equal weight share the grade.
| Check | What is read |
|---|---|
| The three limits are set and enforced | Each limit exists in the configuration kept by the engine and in what the kernel enforces on the container |
| The runaway is contained | The memory limit was actually reached, the peak stays within the limit and the host lost no process |
| The batch job still answers | After the runaway, the service answers: containing is not killing |
| The earlier results are intact | The fingerprints of the original files are unchanged and every file is complete |
| The report is right | The two facts recorded are those that the lab recomputes on the machine |
The first check reads each limit in two places, because what the engine displays and what the kernel enforces do not always coincide.
The second does not just read a limit: it checks that it really bit during the runaway.
The third succeeds only if a limit exists. A service with no limit at all answers perfectly well, and that would prove nothing.
The fourth compares fingerprints, not file names. Files recreated under plausible names therefore do not satisfy it.
The threshold is 75 points, and one requirement is offset by no total: the check on the earlier results must pass. Losing one of these results, or leaving a results file incomplete, fails the exam even with the four other checks passed. A failure repaired late costs time, a lost piece of data cannot be recovered.
Which rules apply?
This exam measures, it does not guide you. Three rules follow from that.
- The lab offers four hints, from the vaguest to the most explicit, which cost 10, 15, 20 and 25 points, and whose costs add up. The score is the share of checks passed, multiplied by a scale of 100 points minus the cost of the hints requested.
- You may consult the lessons of the course and the official Docker documentation, as you would at work.
- The statement explains nothing again: the lessons of the module have already taught what you need to know.
With five checks, each is worth a fifth of the scale. The table shows the margin left by each level of hints.
| Hints requested | Scale | Checks to pass |
|---|---|---|
| None | 100 | 4 out of 5 (80 points) or 5 out of 5; 3 out of 5 give 60 |
| The first | 90 | 5 out of 5 (90 points; 4 out of 5 give 72) |
| The first two | 75 | 5 out of 5 (75 points, right at the threshold) |
| Three or more | 55 at most | Threshold not reachable |
In every case, the check on the earlier results must be among the checks passed. With no hint, the scale is not reduced: it is the only case where four checks out of five are enough.
Which lessons should you review before starting?
The statement does not say which actions it asks for, and this list does not try to point them out either. It gathers, in the order of the course, the lessons of the module that teach an action useful here. Start by rereading those where your last labs were difficult.
- Namespaces and cgroups: measure a container's isolation
- Who launches a container: Docker's execution chain
- Cap a container: CPU, ulimits and shared memory
- Cap memory and the number of tasks of a container
Take the exam
The lab prepares the machine, gives you the statement, then grades the state in which you leave it. Start it when you have about 45 minutes ahead of you, so that you can work in one go.
From your lab environment, the command is launched like this:
dsoxlab run epreuve-contenir-un-conteneur-gourmandThe statement is displayed, you work on the machine, then the lab plays its five checks. Read the result check by check: a message describes what is missing from the final state, never the command to type.
After the exam
If you clear the threshold with the check on the earlier results passed, you know how to contain a runaway container, on the points measured. You can move on to the next module. A result under the threshold does not mean that you failed to learn: it shows where the gap is.
Link each failed check to a lesson in the list above, reread it, then redo the action yourself. Do not try to memorize an answer.
Key points
- The exam is a measurement: nothing is explained again, hints cost points, and the grade covers the final state of the machine, not your commands.
- You need 75 points. With no hint, four checks out of five are enough; with one or two hints, all five must pass; beyond that, the threshold is no longer reachable.
- The earlier results block the exam: losing one, or leaving a results file incomplete, fails it whatever the total.
- A limit is proved by what the kernel enforces and by what it really contains, not only by what the configuration displays.
- Containing is not killing: a limit that makes the service itself die does not pass the exam.