La configuration par environnement
Comprendre comment Symfony organise sa configuration selon le contexte d'exécution : développement, production, tests.
Notions théoriques
Les 3 environnements Symfony
Depuis la séance sur Doctrine, vous utilisez un fichier .env.local pour configurer DATABASE_URL. Mais Symfony ne s'exécute pas toujours dans le même contexte. Il prévoit 3 environnements différents :
dev(développement) : utilisé quand vous travaillez sur votre machine. Les erreurs sont affichées en détail, avec la barre de débogage (profiler) en bas de page, et le cache est régénéré automatiquement à chaque modification.prod(production) : utilisé une fois l'application mise en ligne pour de vrais utilisateurs. Les erreurs détaillées sont masquées (remplacées par une page d'erreur générique), et les performances sont optimisées (cache figé, pas de profiler).test(tests automatisés) : utilisé quand vous exécutez des tests automatiques (voir la séance sur les tests unitaires et fonctionnels). Il permet d'utiliser une configuration isolée, par exemple une base de données de test différente de celle de développement.
L'environnement actif est défini par la variable d'environnement APP_ENV, présente dans le fichier .env. Par défaut, un nouveau projet Symfony démarre en environnement dev.
La hiérarchie des fichiers .env
Vous connaissez déjà .env et .env.local. En réalité, Symfony charge plusieurs fichiers .env dans un ordre précis, chacun avec un rôle différent :
| Fichier | Rôle | Versionné dans git ? |
|---|---|---|
.env | Valeurs par défaut du projet, communes à toute l'équipe | Oui |
.env.local | Surcharge locale, propre à votre machine (mots de passe réels, etc.) | Non |
.env.test | Valeurs utilisées uniquement quand APP_ENV=test | Oui |
.env.test.local | Surcharge locale pour les tests, propre à votre machine | Non |
Les fichiers suivants surchargent les précédents. Ainsi, si DATABASE_URL est définie à la fois dans .env et .env.local, c'est la valeur de .env.local qui est utilisée.
Le fichier .env.local doit toujours figurer dans le fichier .gitignore du projet. Il contient
des informations propres à votre machine (souvent des mots de passe réels), qui ne doivent
jamais être partagées via git. Le fichier .env, lui, ne doit contenir que des valeurs
d'exemple ou par défaut, sans secret réel.
Le dossier config/packages/
La configuration des bundles (Doctrine, sécurité, mailer, etc.) se trouve dans config/packages/. Certains fichiers de ce dossier s'appliquent à tous les environnements, tandis que d'autres ne s'appliquent qu'à un seul :
config/packages/
├── doctrine.yaml ← s'applique à tous les environnements
├── framework.yaml ← s'applique à tous les environnements
├── dev/
│ └── monolog.yaml ← s'applique uniquement en environnement dev
└── prod/
└── monolog.yaml ← s'applique uniquement en environnement prod
Par exemple, il est courant de vouloir des journaux d'erreurs (logs) très détaillés en dev, mais uniquement les erreurs critiques en prod. Cela se configure avec un fichier monolog.yaml différent dans chaque sous-dossier dev/ et prod/.
Les secrets Symfony
Certaines informations sensibles (clé d'API, mot de passe d'un service tiers) ne doivent jamais apparaître en clair dans un fichier .env versionné, même dans .env. Symfony propose un système de secrets chiffrés pour cela.
Définir un secret :
php bin/console secret:set MA_CLE_API
Cette commande demande de saisir la valeur du secret au clavier, puis la stocke de façon chiffrée dans le projet (dans config/secrets/).
Lister les secrets définis :
php bin/console secret:list
Un secret défini avec secret:set devient accessible dans le code exactement comme une variable d'environnement classique, par exemple $_ENV['MA_CLE_API'] ou via l'injection de paramètres.
.env.local est adapté pour la configuration propre à votre machine de développement
(ex. mot de passe de votre base de données locale). Les secrets Symfony sont adaptés
pour les informations sensibles qui doivent être déployées avec l'application en production
(ex. clé d'API d'un service de paiement), car ils sont chiffrés et peuvent être commités
sans risque.
Exemple de mise en application
Configurons le projet my_game pour qu'il utilise une base de données différente en environnement de test, et ajoutons un secret pour une clé d'API fictive.
D'abord, le fichier .env (versionné, valeurs par défaut) :
APP_ENV=dev
DATABASE_URL="mysql://user:password@localhost:3306/my_game"
Ensuite, le fichier .env.local (non versionné, valeurs réelles de développement) :
DATABASE_URL="mysql://my_game:1MotDePasseTresSecurise@localhost:3306/my_game"
Pour les tests automatisés, on crée .env.test (versionné, car il ne contient pas de secret réel, seulement une base de données dédiée aux tests) :
DATABASE_URL="mysql://my_game:1MotDePasseTresSecurise@localhost:3306/my_game_test"
Enfin, on ajoute un secret pour une clé d'API externe :
php bin/console secret:set API_KEY_METEO
# > Value: ********************
Ce secret peut ensuite être utilisé dans le code du contrôleur, sans jamais apparaître en clair dans un fichier versionné.
Test de mémorisation/compréhension
TP pour réfléchir et résoudre des problèmes
Votre défi pour aujourd'hui consiste à préparer la configuration du projet
my_gamepour l'environnement de test, et à sécuriser une information sensible avec les secrets Symfony.
Étape 1 — Créer le fichier .env.test avec une base de données dédiée aux tests
Créez le fichier .env.test à la racine du projet, avec une variable DATABASE_URL pointant vers une base nommée my_game_test.
Utiliser une base my_game_test séparée de my_game évite que l'exécution des tests
automatisés ne modifie ou n'efface accidentellement les données de développement.
Étape 2 — Vérifier que .env.local est bien ignoré par git
Ouvrez le fichier .gitignore à la racine du projet. Complétez la ligne qui doit y figurer pour que .env.local ne soit jamais commité.
Étape 3 — Définir un secret pour une clé d'API météo
L'application my_game doit un jour afficher la météo à côté des parties en extérieur. Définissez un secret nommé API_KEY_METEO avec la commande appropriée.
Même dans .env (versionné), une clé d'API réelle ne doit jamais apparaître en clair.
Utiliser secret:set garantit que la valeur est chiffrée dans le dépôt git, et ne peut
être déchiffrée que par les personnes ou serveurs disposant de la clé de déchiffrement du projet.