6.5Retours du terrain
L'essentiel en 30 secondes
- Prévenir : .dockerignore dès le premier Dockerfile, healthcheck + retry, tags immuables — le moins cher est d'éviter.
- Prouver : sauvegarde rejouée, down/up sans perte, proxy posé tôt — ce qui n'est pas prouvé n'existe pas.
- Douter : latest en prod, dump jamais rejoué et ports en pagaille mordent toujours — sans mythes.
Fil Idir — ce que le trimestre lui a appris
Après un trimestre, Idir résume sa pratique à Alger en cinq phrases : écrire le .dockerignore d'abord, exiger le healthcheck, bannir latest en prod, ne croire que les sauvegardes rejouées, poser le proxy tôt. Et la règle d'or affichée au mur : ce qui n'est pas versionné, prouvé et testé n'existe pas.
Retenez un principe et écartez un mythe : c'est ainsi que l'expérience s'installe.
Ce que recommandent les praticiens
Synthèse anonyme de bonnes pratiques largement partagées dans la documentation officielle, les retours de la communauté et les guides d'exploitation (sans citation fabriquée : ce qui suit agrège des recommandations publiques et vérifiables).
✓ À faire
- « Le .dockerignore d'abord » : ce qui n'entre pas dans le contexte ne casse ni le cache ni la sécurité.
- « Le healthcheck change tout » : passer à condition healthy + retry fait disparaître les crashs de démarrage.
- « Tags immuables en prod » : l'assurance la moins chère contre le rebuild qui casse tout un vendredi soir.
- « La sauvegarde testée, pas la sauvegarde » : volume-test + vérification, sinon c'est une illusion.
- « Un proxy tôt » : dès la deuxième app, pour éviter la dette des ports et préparer TLS et logs.
✗ À éviter
- « latest en prod, on verra bien » — non : un rebuild anodin tire une majeure et casse tout.
- « Mon dump tourne, donc je suis sauvé » — non : sans restauration rejouée, c'est une illusion.
- « depends_on suffit, pas besoin de healthcheck » — non : sans condition healthy ni retry, les crashs reviennent.
- « Un port par app, on gérera plus tard » — non : sans proxy tôt, la dette des ports explose.
Script prêt à dire — parler en praticien (30 s)
« Mon contexte : [.dockerignore dès le départ]. Ma fiabilité : [healthcheck + retry, tags 1.0]. Ma preuve : [sauvegarde rejouée, down/up sans perte]. Mon exposition : [proxy tôt, TLS, logs]. »
Modèle copier-coller — rituel praticien (5 lignes)
docker compose config
docker compose up -d --build
docker compose ps
docker compose logs -f api
docker system dfTPE / petit budget
Un principe par trimestre suffit : .dockerignore + healthcheck d'abord, le reste ensuite.
PME Alger
Adapter aux mises en prod locales : sauvegarde rejouée et preuve down/up à chaque jalon.
Remote / hybride
Prioriser les traces écrites à distance (config validée, preuve rejouée, tag datés).
Interculturel
Prioriser la transposition locale dès que les codes diffèrent : questionner les pairs, comparer les pratiques.
Défi 48h — appliquez demain
Appliquez 1 principe de praticien (.dockerignore, healthcheck, tags 1.0, sauvegarde rejouée, proxy tôt) à votre stack du moment et écartez 1 mythe.
- Je connais les 5 principes des praticiens et les 4 mythes à écarter.
- Mon rituel praticien (prévenir, prouver, préparer) est amorcé.
- J'ai fait le défi 48h ou planifié sa date.
Idir veut progresser comme les praticiens. Que dit le terrain ?
L'expérience ne s'achète pas : elle se construit en versionnant, prouvant et testant, stack après stack.