Environnements : dev, prod, jamais mélangés

Prérequis : cours 5.3 (secrets) ; SSO vu au cursus dev, sessions.

Pourquoi

90 % des « incidents bizarres » viennent d'un mélange : la dev qui écrit en prod, la prod qui lit la conf dev, le SSO qui reboucle (redirections en boucle vers le login). La séparation n'est pas du luxe, c'est de l'hygiène.

Concepts

• Les 4 axes : compose (compose.dev.yaml vs prod), volumes/bases (préfixe -dev vs prod, zéro partage), secrets (.env.dev vs .env.prod, mots de passe différents), URLs (app.dev… vs app…).
• Interpolation : la substitution des ${VAR} dans le compose au lancement. Préfixées DEV_ et requises (${DEV_X:?message}), elles font échouer un lancement sans --env-file .env.dev au lieu de pomper silencieusement la prod.
• Redirect URI : l'URL de retour enregistrée chez le fournisseur SSO, une par environnement. Symptôme de mélange : redirect_uri_mismatch ou login qui reboucle — vérifier caractère par caractère.

Exemple : le rituel avant prod

grep -r "dev" compose-projet/   # traque les restes de dev
# + vérifier les 4 axes : fichiers, volumes (docker volume ls), secrets, URLs

Dix secondes qui évitent la honte du « pourquoi la prod parle à la base de dev ».

Cas réel

.env.prod copié du .env.dev avec le même mot de passe base : la fuite du .env.dev (moins protégé, partagé pour débugger) compromet la prod. Depuis : mots de passe différents, .env.prod jamais copié, jamais affiché.

Pièges

• Variables « juste pour tester » laissées dans le compose prod.
• Volumes nommés pareil en dev et prod (sans préfixe projet) : Docker les partage… silencieusement.
• Tester le SSO uniquement en dev : la prod a sa propre URI, son propre test.

À retenir

4 axes séparés, DEV_ qui fait échouer au lieu de mélanger, une URI SSO par environnement, mots de passe différents.