Les vraies réservations dans la base de test
Sophie travaille pour un réseau de salles de sport à Toulouse. Les clients réservent leurs cours en ligne.
L'adresse de la base de données de test est écrite dans le code. Le jour de la mise en production, personne ne la change.
Pendant deux jours, les vraies réservations partent dans la base de test. Cette leçon montre comment l'éviter.
À la fin de cette leçon
Remarque
Je peux garder les réglages d'une application en dehors de son code.
Mots clés
| Mot | Ce que ça veut dire | Exemple |
|---|---|---|
| Configuration | l'ensemble des réglages d'une application | |
| Environnement | un endroit où tourne l'application | test, production |
| Variable d'environnement | un réglage donné au programme par le système | PORT=5000 |
| Valeur par défaut | la valeur prise quand le réglage manque | |
| Secret | un réglage à cacher | un mot de passe, une clé |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Un seul code, plusieurs réglages
La même application tourne à plusieurs endroits : le poste du développeur, le serveur de test, la production. Chacun de ces environnements a ses propres réglages.
Le code, lui, doit rester identique partout. C'est ce code qui a passé les tests.
On sort donc les réglages du code. L'application les lit au démarrage.
Les réglages changent, le code non
| Réglage | Serveur de test | Production |
|---|---|---|
| Adresse de la base | base-test.interne | base-prod.interne |
| Port | 5000 | 8080 |
| Envoi de SMS aux clients | Non | Oui |
| Code de l'application | Version 2.3 | Version 2.3 |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Les variables d'environnement portent les réglages
Le moyen le plus courant est la variable d'environnement. Le système la donne au programme quand il le lance.
Dans le bloc ci-dessous, le même script tourne deux fois avec des réglages différents. Quand PORT manque, le script prend une valeur par défaut.
Lancez-le, puis faites la modification du dernier commentaire.
Un script, deux environnements
cat > demarrer.sh <<'FIN'
echo "Base de données : $ADRESSE_BASE"
echo "Port : ${PORT:-8080}"
FIN
echo "--- Serveur de test ---"
ADRESSE_BASE=base-test.interne PORT=5000 bash demarrer.sh
echo "--- Production ---"
ADRESSE_BASE=base-prod.interne bash demarrer.sh
# En production, PORT n'est pas donné : la valeur par défaut 8080 s'applique.
# Donnez PORT=9000 à la production, puis relancez.
Un secret n'entre jamais dans le dépôt
Un mot de passe ou une clé d'accès est un secret. Il ne s'écrit ni dans le code ni dans le dépôt.
Sur le poste, on le met dans un fichier .env que Git ignore. En production, il vient d'un coffre à secrets ou de la plateforme qui héberge l'application.
Le bloc suivant cherche un mot de passe oublié dans le code, comme le font les outils de relecture.
Une erreur fréquente
Attention
Beaucoup pensent qu'il suffit d'effacer le mot de passe du code et d'enregistrer à nouveau. C'est faux : Git garde toutes les anciennes versions, et le secret y reste lisible. Dès qu'un secret est entré dans un dépôt, on le change.
Trouver un secret écrit en clair
mkdir -p reservations && cd reservations
printf 'import os\nadresse = os.environ["ADRESSE_BASE"]\n' > config.py
printf 'mot_de_passe = "Soleil2024"\nprint("connexion")\n' > appli.py
printf 'MOT_DE_PASSE_BASE=change-moi\n' > .env
printf '.env\n' > .gitignore
# Cherche un mot de passe écrit en clair dans les fichiers Python
grep -n 'mot_de_passe = "' *.py
# Le fichier .env reste sur le poste : Git l'ignore
cat .gitignore
Où ranger chaque chose
| Élément | Dans le code | Variable d'environnement | Coffre à secrets |
|---|---|---|---|
| Le calcul d'un tarif | Oui | Non | Non |
| L'adresse de la base | Non | Oui | Non |
| Le mot de passe de la base | Non | Non | Oui |
| La clé du service de paiement | Non | Non | Oui |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.