7.3 : Gestion multi-fichiers : Utiliser env_file pour séparer les configs

Lorsque vos projets deviennent plus complexes, un seul fichier .env peut vite devenir encombrant. Docker Compose propose une solution pratique : env_file, qui permet de charger des fichiers supplémentaires de variables d’environnement pour un service spécifique.

Comment ça fonctionne ?

• .env est toujours chargé automatiquement par Docker Compose, même si vous ne le mentionnez pas.
• env_file permet d’ajouter un ou plusieurs fichiers spécifiques à un service.
• Ces fichiers ne peuvent contenir que des variables d’environnement (pas de restart, image ou autres instructions YAML).

Exemple de structure de projet :

project/
├─ docker-compose.yml
├─ .env
├─ db.env
├─ app.env

Fichier db.env :

DB_PASSWORD=supersecret
DB_NAME=monprojet

Fichier app.env :

APP_ENV=production
APP_DEBUG=false

Dans le docker-compose.yml :

services:
  db:
    image: mariadb:10.11
    env_file:
      - db.env
    environment:
      MYSQL_USER: ${DB_USER}  # interpolation depuis .env
  php:
    image: php:8.2-apache
    env_file:
      - app.env

Points clés à retenir

1. .env vs env_file

Élément	Chargé automatiquement ?	Peut contenir quoi ?	Scope
.env	Oui	Tout type de variable (env, image, tag, restart, ports via interpolation)	Global à tout le docker-compose
env_file	Non, à déclarer	Seulement variables d’environnement	Par service

2. Ordre de priorité des variables
   • Variables dans le docker-compose.yml (via environment:) → priorité la plus haute. Variables dans env_file → priorité intermédiaire. Variables dans .env → priorité la plus basse 🔹 Exemple : si DB_PASSWORD est défini dans .env et dans db.env, Docker Compose utilisera la valeur de db.env.
3. Possibilité de mélange
   • .env peut toujours être utilisé pour interpoler des paramètres comme restart: ${RESTART_POLICY} ou image: myimage:${TAG}.
   • env_file est surtout pratique pour séparer les secrets ou configs spécifiques par service.

---