GUIDINEE.COM › Docker › Level 6 › 6.1

6.1 · Real-world cases

Level 6 · In practice

6.1Real-world cases

Goal: see how the skills from levels 0 to 5 chain together on real cases.
Estimated time: 14 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

  • Assemble: clean Dockerfile (slim, dependencies first, non-root), image tagged 1.0, declarative Compose stack, proven persistence, CI as the only factory.
  • Prove: test locally, have a third party pull and run it, prove down/up with no loss — what is not proven does not exist.
  • Share: a versioned image and a cloned repo + up = a complete app, with no "install Node 20".

Idir's thread — two deliveries in Algiers

Idir, junior DevOps in Algiers, looks back at his two landmark projects of the quarter: containerising the Node API that only ran on its author's laptop (Dockerfile, 1.0 build, hardening, push to the registry, handover to a colleague), then equipping his small team with an api + database + console Compose stack (settings, restart and healthcheck, validation, no-loss proof). Both cases below follow his sequence: write clean, build, harden, share, declare, prove.

Each case follows the Context → Steps → Result flow: replay it on your app.

Putting the building blocks end to end

The previous levels laid the building blocks (images, containers, volumes, networks, Dockerfile, Compose, registries, CI); here we assemble them under real conditions: it is the chaining of the right reflexes — hardened image, declarative stack, proven persistence, single CI — that separates a reliable deployment from a fragile pile. Two cases covered from A to Z.

Case 1 — Containerising an API from A to Z

Context: You receive a Node API that only runs on its author's laptop and you must deliver it as a shared image. Risk: a non-reproducible environment and endless "works on my machine".

Déroulé :

  1. Write the Dockerfile (node:20-slim, WORKDIR, dependencies first, USER node, CMD) with .dockerignore (N2.1, N2.5).
  2. Build as mon-app:1.0 and test locally with -p 3000:3000 (N1.2, N2.1).
  3. Harden: .dockerignore, non-root, scan, immutable 1.0 tag (N2.5, N4.1).
  4. Push to the registry and have a colleague pull + run it (N2.3, N4.1).
  5. Validate: a third party runs the image with one command, without installing Node 20.

Result: A shared 1.0 image, runnable anywhere with one command, with no "install Node 20".

Case 2 — Compose stack for a small team

Context: A team wants to run api + database + console with one command, with persisted data and simple updates. Challenge: a stack that breaks on the first restart.

Déroulé :

  1. Write compose.yml: api (build), bdd (pgdata volume), adminer in dev profile (N3.1, N3.4).
  2. Parameterise via ${PORT:-3000} and a versioned .env.example, .env not committed (N3.4, N2.4).
  3. Add restart + bdd healthcheck + depends_on healthy (N4.2, N3.2).
  4. Validate with config, up -d --build, then prove down/up with no loss (N3.2, N4.4).
  5. Document: the "how to run it" doc fits on one line (clone + up).

Result: A cloned repo + up = a complete app; the "how to run it" doc fits on one line.

Common misinterpretation: "copying the cases as-is". No. The cases show a production order (write clean, build, harden, share, declare, prove), not a recipe to copy: reuse the order, adapt image, services and settings to your app.
Text version of the diagram (SEO / screen readers / translation): Full chain: 1) Write (slim Dockerfile, dependencies first, USER node, .dockerignore, N2.1/N2.5). 2) Build and test (immutable 1.0 tag, local -p run, N1.2). 3) Harden (non-root, scan, 1.0 tag never latest in prod, N2.5/N4.1). 4) Share (push to the registry, pull + run by a third party, N2.3/N4.1). 5) Declare (compose.yml api + bdd + dev profile, ${PORT:-3000}, .env.example, N3.1/N3.4). 6) Make reliable and prove (restart, healthcheck, depends_on healthy, config, up -d --build, down/up with no loss, N4.2/N4.4). Lesson: a reliable deployment comes from the chaining, not from a single command.

Ready-to-say script — framing a Docker delivery (30 s)

"Our need: [API to share / api + database stack]. Our image: [slim, non-root, 1.0 tag, scanned]. Our stack: [versioned compose, ${PORT:-3000}, pgdata volume]. Our proof: [pull by a third party / down-up with no loss]."

Copy-paste template — real-case sequence

docker build -t mon-app:1.0 .
docker run -d --name api -p 3000:3000 mon-app:1.0
docker compose config
docker compose up -d --build
docker compose ps
docker compose down
docker compose up -d

Small business / tight budget

One small replayed case is enough: one 1.0 image, a two-service compose, a noted down/up proof.

SME in Algiers

Adapt to local realities: test on the team's real machine, plan for a backed-up pgdata volume.

Remote / hybrid

Double remote traceability: tag, registry and down/up proof noted and shared.

Intercultural

Spell out the docs before transposing a case: a "clone + up" line must speak to every newcomer.

Caution: Generic reminder: a shared image commits your team — immutable tags, non-root, scan, zero secrets in the image and in git, .env not committed, down/up proof before the delivery counts as done.

48h challenge — apply tomorrow

Take 1 real app and replay the sequence: clean Dockerfile, 1.0 build, local run, compose validated by config, down/up with no loss proof.

Section exit checklist
  • I can chain Dockerfile, build, sharing and a Compose stack on a real case.
  • I have a replayable sequence (1.0 image, versioned compose, no-loss proof).
  • I did the 48h challenge or scheduled its date.
Self-rating 1-5: can a third party pick up my image with one command?is my persistence proven by down/up?
Next : Recurring problems (playbook) (V3) →
Check your understanding

Idir is delivering his API. Which sequence follows the guide?