Aller au contenu principal

La configuration par environnement

Comprendre comment Symfony organise sa configuration selon le contexte d'exécution : développement, production, tests.

Petite vérification​

Avant de commencer, vérifiez si vous savez encore...

  1. afficher le contenu du fichier src/Controller/PlayerController.php et vérifier que la classe Request est bien importée en haut du fichier
  2. vérifier que la méthode index() de PlayerController reçoit bien un paramètre Request $request
  3. visiter dans votre navigateur l'URL http://localhost:8000/player?search=alice et vérifier que la page se charge bien sans erreur
📌 Réponse attendue

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.
info

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 :

FichierRôleVersionné dans git ?
.envValeurs par défaut du projet, communes à toute l'équipeOui
.env.localSurcharge locale, propre à votre machine (mots de passe réels, etc.)Non
.env.testValeurs utilisées uniquement quand APP_ENV=testOui
.env.test.localSurcharge locale pour les tests, propre à votre machineNon

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.

attention

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.

Bonne pratique - Secret vs .env.local

.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​


Quel est l'environnement Symfony utilisé par défaut sur la machine d'un développeur ?


Quel environnement est utilisé quand l'application est mise en ligne pour de vrais utilisateurs ?


Quelle variable d'environnement détermine l'environnement actif de Symfony ?


Lequel de ces fichiers doit obligatoirement être ignoré par git ?


Quel fichier .env est chargé uniquement quand APP_ENV vaut "test" ?


Dans quel dossier se trouve la configuration des bundles comme Doctrine ou le mailer ?


À quoi sert un sous-dossier comme config/packages/prod/ ?


Quelle commande permet de définir un secret chiffré dans un projet Symfony ?


Pourquoi utiliser un secret Symfony plutôt qu'une variable dans .env pour une clé d'API ?


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_game pour 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.


Bonne pratique - Une base de données dédiée aux tests

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.


Bonne pratique - Ne jamais écrire une clé d'API en clair dans .env

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.

📌 Une solution