Level 6 · In practice

6.4Toolbox

Goal: have operational checklists and the essential Docker commands.

Estimated time: 10 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

Going live: scanned non-root immutable tags, restart + healthcheck, backed-up and replayed volumes, secrets out of git.
Drawing fast: up -d --build, ps, logs -f, exec, config before any up, scout, system df.
Rule: a checklist ticked every time beats a method known by heart — in prod, you execute.

Idir's thread — the cards near the desk

After one quarter, both cards below stay near Idir's desk: the going-live one displayed next to the screen, the daily-commands one in his notebook. "What saved me, he says in substance, is not knowing the points, it is ticking them every time — especially on release days."

Adapt the wording to your context, keep the structure: it is what avoids omissions and incidents.

Ready-to-use reference points

A good checklist makes a deployment fast and omission-free; the right commands avoid fumbling. Adapt to your context.

Going live (8 yeses)

Immutable tags, scanned non-root images
restart + healthcheck on every long-lived service
Volumes backed up, restore tested
Secrets out of git, versioned .env.example
Only the proxy publishes 80/443
Logs with rotation, disk alerted
CI as the only factory, versioned compose
down/up proven with no loss

Daily commands

docker compose up -d --build / ps / logs -f svc / exec svc sh / down
docker images / ps -a / volume ls / network ls
docker compose config (validate) before any up
docker scout quickview image:tag (scan)
docker system df (what is filling the disk?)

Common misinterpretation: "collecting checklists". No. A checklist is only useful ticked and used: take the one for your next release, the others can wait.

Text version of the diagram (SEO / screen readers / translation): Two moments, two cards: 1) Going live — immutable non-root scanned tags, restart + healthcheck, backed-up and replayed volumes, secrets out of git, only the proxy on 80/443, logs with rotation, CI as the only factory, down/up proven. 2) Daily — config before up, up -d --build, ps, logs -f, exec sh, scout, system df, images/ps/volume/network ls. Lesson: no more thinking under pressure, you run the card near the desk.

Ready-to-say script — validating a release (30 s)

"Scanned non-root immutable tags? Restart + healthcheck? Volumes replayed? Secrets out of git? Proxy alone on 80/443? Logs + disk OK? CI as the only factory? Down/up proven? If any no, we do not release."

Copy-paste template — daily Docker routine

docker compose config
docker compose up -d --build
docker compose ps
docker compose logs -f api
docker compose exec api sh
docker system df

Small business / tight budget

Cards on one page posted on the wall: the essentials (tags, replayed volumes, config) are enough.

SME in Algiers

Plan local realities into the card: known contacts, release days, tested real volume.

Remote / hybrid

Add a written-validation line to tracking: remotely, a dated and proven release avoids misunderstandings.

Intercultural

Spell out labels in writing: what seems obvious (who backs up, which tag) is not obvious to everyone.

Caution: Generic reminder: releases and secrets commit your organisation — the "immutable tags, secrets out of git, tested restore" point ticked every time, .env never committed, down/up proof kept; this guide gives no legal advice.

48h challenge — apply tomorrow

Take 1 real stack, run the "Going live (8 yeses)" checklist and tick where it stands. Run one debug command.

Section exit checklist

I ticked a checklist on a real stack.
I can pull out the prod card and the commands at the right moment.
I did the 48h challenge or scheduled its date.

Self-rating 1-5: tooling of my stacks?dated use of checklists?

← Previous : Best practices & pitfalls (V3)Next : Lessons from the field (V3) →

Check your understanding

Idir is about to go live. What must he tick first?

💡

These checklists prevent 90% of incidents: a latest in prod, a secret in git, an unreplayed volume.