GUIDINEE.COM › Docker › Level 6 › 6.3

6.3 · Best practices & pitfalls

Level 6 · In practice

6.3Best practices & pitfalls

Goal: lock in the 10 reflexes that separate healthy use from fragile use.
Estimated time: 10 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

  • Verify: immutable tags in prod, slim non-root scanned images, zero secrets in the image and in git.
  • Make reliable: named volume + proof, one network per app, restart + healthcheck, Compose validated by config.
  • Operate: CI as the only factory, replayed backups, single TLS proxy, logs with rotation — eight yeses = prod.

Idir's thread — the rule stuck on the wall

After one quarter, Idir stuck his rule on the wall in Algiers: healthy and proven first, fast second. What counted most was not a tool but three habits — immutable tags, proven volumes, validated Compose — and his biggest pitfall narrowly avoided: a latest deployed on a Friday evening, blocked before prod.

Pick a single habit to anchor in your routine, then move to the next one.

The contract of trust

A healthy Docker stack rests on few rules, always applied. Here they are, with their opposites to ban.

✓ To do

  • Immutable tags in prod, latest only in dev.
  • Systematic non-root USER, official slim bases.
  • Zero secrets in the image and in git (run -e, secrets, .env not committed).
  • Named volume for data, rm + restart test.
  • One network per app, internal database, only the front end published.
  • restart + healthcheck on every long-lived service.
  • Versioned Compose, validated by config, base + profiles.
  • CI as the only factory (SHA+version), cache enabled.
  • Automatic backups + tested restore.
  • Single reverse proxy, TLS in prod, logs with rotation.

✗ To avoid

  • Deploying latest to production.
  • Running as root "to simplify".
  • Committing .env and secrets, COPYing them into the image.
  • Storing the database in the ephemeral layer.
  • Publishing every service and the database.
  • depends_on with no condition or retry.
  • docker run lines copied from memory.
  • Building/pushing by hand from the laptop.
  • Never replaying a backup.
  • One port per app, with no proxy or monitoring.
Common misinterpretation: "ticking every box every day". No. These are habits to install one by one: pick one (e.g. immutable tags everywhere), anchor it in your routine, then move to the next.
Text version of the diagram (SEO / screen readers / translation): Balance to hold: 1) Image side — immutable tags, slim non-root, scan, zero secrets, CI as the only factory with cache. 2) Stack side — proven named volume, one network per app, restart + healthcheck, versioned Compose validated by config, base + profiles. 3) Operations side — replayed backups, single TLS proxy, logs with rotation, down/up proven with no loss. Lesson: a healthy stack is first versioned, proven and tested — speed comes after.

Ready-to-say script — checking your stack before prod (30 s)

"Immutable tags? Non-root + scan? Zero secrets in git? Volume proven by rm + restart? Restart + healthcheck? Compose config OK? CI as the only factory? Backup replayed? If any no, I fix before prod."

Copy-paste template — pre-deployment prod checklist

docker compose config
docker scout quickview mon-app:1.0
docker compose up -d --build
docker compose ps
docker compose logs -f api

Small business / tight budget

One habit per quarter is enough: tags + proven volumes first, the rest after.

SME in Algiers

Adapt routines to release days: a replayed-backup slot and a down/up proof kept every month.

Remote / hybrid

The #1 discipline remotely: tag, validated config and written proof, even for small stacks.

Intercultural

Check local usages instead of assuming: an unusual port or path must raise an alert everywhere.

Caution: Generic reminder: golden rule — a healthy stack is first versioned and proven; never deploy latest to prod, never commit .env or secrets, never store the database in ephemeral storage, and replay every backup before believing it.

48h challenge — apply tomorrow

Screen your stack: zero latest in prod, zero secrets in git, zero unproven volumes. Fix the first gap found.

Section exit checklist
  • I know the 10 reflexes to adopt and the 10 pitfalls to avoid.
  • I checked my 3 critical points (tags, secrets, proven volumes).
  • I did the 48h challenge or scheduled its date.
Self-rating 1-5: consistency of good reflexes?pitfalls avoided?
← Previous : Recurring problems (playbook) (V3)Next : Toolbox (V3) →
Check your understanding

Before going live, which reflex protects Idir best?

💡

A good Docker operator is not the one who deploys fastest, but the one whose stacks are versioned and proven.