Niveau 6 · Dans la pratique

6.3Bonnes pratiques & pièges

Objectif : ancrer les 10 réflexes qui séparent un usage sain d'un usage fragile.

Temps estimé : 10 min · Si vous n'avez que 5 min : lisez « L'essentiel en 30s » + le schéma.

L'essentiel en 30 secondes

Vérifier : tags immuables en prod, images slim non-root scannées, zéro secret dans l'image et le git.
Fiabiliser : volume nommé + preuve, réseau par appli, restart + healthcheck, Compose validé par config.
Exploiter : CI seule usine, sauvegardes rejouées, proxy unique TLS, logs avec rotation — huit oui = prod.

Fil Idir — la règle collée au mur

Après un trimestre, Idir a collé sa règle au mur à Alger : sain et prouvé d'abord, rapide ensuite. Ce qui a le plus compté n'est pas un outil, mais trois habitudes — tags immuables, volumes prouvés, Compose validé — et son plus gros piège évité de justesse : un latest déployé un vendredi soir, bloqué avant la prod.

Choisissez une seule habitude à ancrer dans votre rituel, puis passez à la suivante.

Le contrat de confiance

Un stack Docker sain tient à peu de règles, appliquées toujours. Les voici, avec leurs inverses à bannir.

✓ À faire

Tags immuables en prod, latest seulement en dev.
USER non-root systématique, bases slim officielles.
Zéro secret dans l'image et le git (run -e, secrets, .env non commité).
Volume nommé pour les données, test rm + relance.
Un réseau par appli, base interne, seul le frontal publié.
restart + healthcheck sur tout service durable.
Compose versionné, validé par config, socle + profils.
CI seule usine (SHA+version), cache activé.
Sauvegardes automatiques + restauration testée.
Reverse proxy unique, TLS en prod, logs avec rotation.

✗ À éviter

Déployer latest en production.
Tourner en root « pour simplifier ».
Committer .env et secrets, les COPY dans l'image.
Stocker la base dans la couche éphémère.
Publier chaque service et la base.
depends_on sans condition ni retry.
Lignes docker run recopiées de mémoire.
Builder/pousser à la main depuis le portable.
Ne jamais rejouer une sauvegarde.
Un port par app, sans proxy ni supervision.

Erreur d'interprétation fréquente : « cocher toutes les cases chaque jour ». Non. Ce sont des habitudes à installer une par une : choisissez-en une (par ex. tags immuables partout), ancrez-la dans votre rituel, puis passez à la suivante.

Version texte du schéma (SEO / lecteurs d'écran / traduction) : Équilibre à tenir : 1) Côté image — tags immuables, slim non-root, scan, zéro secret, CI seule usine avec cache. 2) Côté stack — volume nommé prouvé, réseau par appli, restart + healthcheck, Compose versionné validé par config, socle + profils. 3) Côté exploitation — sauvegardes rejouées, proxy unique TLS, logs avec rotation, down/up prouvé sans perte. Leçon : un stack sain est d'abord versionné, prouvé et testé — la rapidité vient après.

Script prêt à dire — vérifier son stack avant prod (30 s)

« Tags immuables ? Non-root + scan ? Zéro secret en git ? Volume prouvé rm + relance ? Restart + healthcheck ? Compose config OK ? CI seule usine ? Sauvegarde rejouée ? Si un non, je corrige avant prod. »

Modèle copier-coller — grille prod avant déploiement

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

TPE / petit budget

Une seule habitude par trimestre suffit : tags + volumes prouvés d'abord, le reste ensuite.

PME Alger

Adapter les rituels aux mises en prod : un créneau sauvegarde rejouée et preuve down/up tenu chaque mois.

Remote / hybride

La discipline n°1 à distance : tag, config validée et preuve écrits, même pour les petits stacks.

Interculturel

Vérifier les usages locaux plutôt que supposer : un port ou un chemin inhabituel doit alerter partout.

Prudence : Rappel générique : règle d'or — un stack sain est d'abord versionné et prouvé ; ne déployez jamais latest en prod, ne commitez jamais .env ni secrets, ne stockez jamais la base en éphémère, et rejouez chaque sauvegarde avant d'y croire.

Défi 48h — appliquez demain

Passez votre stack au crible : zéro latest en prod, zéro secret en git, zéro volume non prouvé. Corrigez le premier écart trouvé.

Checklist sortie de section

Je connais les 10 réflexes à faire et les 10 pièges à éviter.
J'ai vérifié mes 3 points critiques (tags, secrets, volumes prouvés).
J'ai fait le défi 48h ou planifié sa date.

Auto-évaluation 1-5 : constance des bons réflexes ?pièges évités ?

← Précédent : Problèmes récurrents (playbook) (V3)Suite : Boîte à outils (V3) →

Vérifiez votre compréhension

Avant sa mise en prod, quel réflexe protège le mieux Idir ?

💡

Un bon exploitant Docker n'est pas celui qui déploie le plus vite, mais celui dont les stacks sont versionnés et prouvés.