Gestion de la configuration dans les conteneurs (variables d'environnement, volumes)

Le défi de la configuration dans les conteneurs

Une image Docker est conçue pour être immuable et portable. Intégrer directement la configuration spécifique à un environnement (développement, test, production) dans l'image elle-même va à l'encontre de ce principe. Les paramètres tels que les URL de bases de données, les clés d'API, les identifiants ou les niveaux de log varient d'un environnement à l'autre.

Il est donc essentiel de pouvoir fournir ou modifier la configuration d'une application Spring Boot au moment où le conteneur est lancé (runtime), sans avoir à reconstruire l'image Docker. Docker et Spring Boot offrent plusieurs mécanismes flexibles pour externaliser et injecter cette configuration de manière efficace.

Les deux approches les plus courantes et complémentaires sont l'utilisation des variables d'environnement et des volumes Docker. Comprendre comment et quand utiliser chacune est crucial pour déployer des applications Spring Boot conteneurisées de manière robuste et adaptable.

Configuration via les variables d'environnement

Les variables d'environnement sont un standard pour passer des informations de configuration à un processus, et elles sont nativement supportées par les conteneurs Docker et Spring Boot.

Spring Boot a une convention de nommage spécifique pour mapper les variables d'environnement aux propriétés définies dans application.properties ou application.yml :

• Convertissez le nom de la propriété en majuscules.
• Remplacez les points (.) par des underscores (_).
• Remplacez les tirets (-) par des underscores (_).
• Pour les indices de tableau (par exemple, logging.level[0]), utilisez des underscores : LOGGING_LEVEL_0.

Par exemple, la propriété spring.datasource.url devient la variable d'environnement SPRING_DATASOURCE_URL. De même, server.port devient SERVER_PORT.

Vous pouvez passer ces variables d'environnement à votre conteneur lors de son lancement avec l'option -e ou --env de la commande docker run :

docker run -p 8080:8080 \
  -e "SPRING_PROFILES_ACTIVE=prod" \
  -e "SPRING_DATASOURCE_URL=jdbc:postgresql://prod-db.example.com:5432/mydatabase" \
  -e "SPRING_DATASOURCE_USERNAME=prod_user" \
  -e "SPRING_DATASOURCE_PASSWORD=une_valeur_secrete" \
  -e "SERVER_PORT=8080" \
  mon-app-image:latest

Avantages :

• Standard et largement utilisé dans l'écosystème des conteneurs.
• Facile à intégrer avec les systèmes d'orchestration (Kubernetes, Docker Swarm) qui ont des mécanismes pour gérer les secrets via des variables d'environnement.
• Simple pour des valeurs de configuration atomiques (chaînes, nombres, booléens).

Inconvénients :

• Peut devenir difficile à gérer si le nombre de variables est très élevé.
• Moins adapté pour des configurations complexes ou structurées (listes longues, objets imbriqués souvent présents en YAML).
• Peut être visible dans l'historique des commandes ou les informations d'inspection du conteneur si pas géré via des systèmes de secrets dédiés.

Configuration via les volumes Docker

Les volumes Docker permettent de monter un fichier ou un répertoire de la machine hôte (ou d'un volume Docker managé) à l'intérieur du conteneur. C'est une excellente méthode pour fournir des fichiers de configuration complets (comme application.properties ou application.yml) à votre application Spring Boot sans les inclure dans l'image.

Spring Boot recherche automatiquement les fichiers de configuration dans des emplacements spécifiques, notamment à la racine du classpath, dans le répertoire courant, et dans un sous-répertoire /config. Vous pouvez exploiter cela en montant vos fichiers de configuration externes dans l'un de ces emplacements à l'intérieur du conteneur.

1. Monter un fichier de configuration spécifique :

Supposons que vous ayez un fichier application-prod.yml sur votre machine hôte dans /etc/mon-app/config/. Vous pouvez le monter directement dans le conteneur :

docker run -p 8080:8080 \
  -v "/etc/mon-app/config/application-prod.yml:/app/config/application-prod.yml" \
  -e "SPRING_PROFILES_ACTIVE=prod" \
  mon-app-image:latest

Dans cet exemple, on monte le fichier externe dans /app/config/ à l'intérieur du conteneur (en supposant que /app est le WORKDIR). L'activation du profil `prod` via une variable d'environnement indique à Spring Boot de charger ce fichier application-prod.yml.

2. Monter un répertoire de configuration complet :

Vous pouvez aussi monter tout un répertoire contenant potentiellement plusieurs fichiers (application.properties, application-prod.properties, etc.) :

docker run -p 8080:8080 \
  -v "/etc/mon-app/config:/app/config" \
  -e "SPRING_PROFILES_ACTIVE=prod" \
  mon-app-image:latest

Ici, tout le contenu de /etc/mon-app/config sur l'hôte est rendu disponible dans /app/config dans le conteneur. Spring Boot chargera les fichiers appropriés en fonction du profil actif.

Avantages :

• Idéal pour gérer des fichiers de configuration complexes (YAML, properties multilignes).
• Permet de mettre à jour la configuration sans reconstruire l'image Docker (il suffit de redémarrer le conteneur après avoir modifié le fichier sur l'hôte).
• Sépare clairement la configuration de l'artefact applicatif.

Inconvénients :

• Nécessite de gérer les fichiers de configuration sur la machine hôte ou via des volumes Docker managés.
• Peut introduire des problèmes de permissions entre le système de fichiers de l'hôte et l'utilisateur à l'intérieur du conteneur (particulièrement si le conteneur ne tourne pas en root).
• Moins direct pour injecter des secrets gérés par l'orchestrateur (bien que les orchestrateurs puissent monter des secrets sous forme de fichiers dans des volumes).

Combinaison et ordre de priorité

Il est très courant de combiner ces deux approches. Par exemple, utiliser un volume pour monter un fichier application.yml de base et utiliser des variables d'environnement pour surcharger des valeurs spécifiques ou pour injecter des secrets.

Spring Boot applique un ordre de priorité bien défini pour ses sources de configuration. Les sources avec une priorité plus élevée écrasent les valeurs des sources de priorité inférieure. Voici un extrait simplifié de l'ordre (du plus prioritaire au moins prioritaire) pertinent pour les conteneurs :

1. Arguments de ligne de commande (ex: --server.port=9000 passé à java -jar).
2. Variables d'environnement du système d'exploitation.
3. Fichiers de configuration spécifiques au profil chargés depuis l'extérieur du JAR (ex: application-prod.properties via volume).
4. Fichiers de configuration non spécifiques au profil chargés depuis l'extérieur du JAR (ex: application.properties via volume).
5. Fichiers de configuration spécifiques au profil empaquetés dans le JAR (ex: src/main/resources/application-dev.properties).
6. Fichiers de configuration non spécifiques au profil empaquetés dans le JAR (ex: src/main/resources/application.properties).

Cela signifie qu'une variable d'environnement (SERVER_PORT=9090) surchargera la valeur définie dans un fichier application.properties monté via un volume (server.port=8080), qui elle-même surchargerait la valeur définie dans le fichier application.properties inclus dans le JAR.

Cette hiérarchie vous donne une grande flexibilité pour définir des valeurs par défaut dans l'image ou dans des fichiers montés, tout en permettant des surcharges ciblées via des variables d'environnement pour des configurations spécifiques à l'instance ou des secrets.

Autres approches et bonnes pratiques

Pour des architectures microservices plus complexes, l'utilisation d'un serveur de configuration centralisé comme Spring Cloud Config Server (ou HashiCorp Consul, etc.) est souvent préférée. L'application Spring Boot, au démarrage, contacte ce serveur pour récupérer sa configuration. Cette approche n'est généralement pas gérée directement via les mécanismes Docker de base, mais via la configuration Spring de l'application elle-même (souvent via bootstrap.properties/yml).

Bonnes pratiques générales :

• Ne jamais intégrer de secrets en dur : N'incluez jamais de mots de passe, clés d'API ou autres informations sensibles directement dans votre `Dockerfile` ou vos fichiers de configuration versionnés. Utilisez les mécanismes de secrets de votre orchestrateur (Secrets Kubernetes, Docker Secrets) qui peuvent souvent les injecter sous forme de variables d'environnement ou de fichiers dans des volumes sécurisés.
• Minimiser la configuration dans l'image : L'image Docker doit contenir le moins de configuration possible. Utilisez des fichiers de configuration embarqués pour les valeurs par défaut ou la configuration de base non sensible.
• Documenter la configuration requise : Documentez clairement les variables d'environnement ou les fichiers de configuration nécessaires pour faire fonctionner votre application en conteneur.
• Utiliser les profils Spring : Tirez parti des profils Spring (prod, dev, test) pour organiser vos configurations externes (par exemple, application-prod.yml monté via volume) et activez le profil souhaité via la variable d'environnement SPRING_PROFILES_ACTIVE.

Maîtriser la gestion de la configuration dans les conteneurs est essentiel pour déployer des applications Spring Boot de manière flexible, sécurisée et adaptée aux différents environnements d'exécution.