Spring Boot : variables d'environnement
Posted on mar. 20 novembre 2018 in Spring
Dans le cadre d'une architecture micro-services, l'application doit pouvoir s'exécuter au sein de plusieurs environnements. Spring Boot réunit sous le nom d'« Externalized Configuration » un ensemble d'interfaces et de pratiques répondant à cette problématique.
Durant l'étape de développement, on est appelé à modifier des variables existantes ou à en déclarer de nouvelles.
Prenons l'exemple du numéro de port du serveur.
Le plus souvent, ce port, s'il est différent de celui par défaut, est déclaré dans le fichier application.properties, comme suit :
server.port=8888
Mais on peut également le spécifier lors de l'exécution d'un goal Maven:
mvn -DSERVER_PORT=9000 run
.
Les IDE proposent en général un moyen simple de déclarer ces variables. Sous Netbeans, par exemple, on pourra définir la propriété suivante dans la section Actions des propriétés du projet, en relation avec le Goal sélectionné :
Env.SERVER_PORT=9000
(notons ici l'usage du préfixe Env). Ce qui se traduit par <Env.SERVER_PORT>9000</Env.SERVER_PORT>
dans le fichier nbactions.xml.
La déclaration de cette variable prendra le pas sur la précédente. La chaîne SERVER_PORT, automatiquement interpolée en server.port — ce qu'on appelle le « relaxed binding » dans le jargon de Spring —, est lue au démarrage et remplace l'existante, s'il y a lieu.
Bien entendu, on peut accéder à toutes les variables d'environnement système définies sur l'hôte : PATH, HOME, etc.
Dans un programme Java traditionnel, l'accès à ces variables se fait par l'appel de la méthode System.getenv(String name)
(notons au passage l'absence troublante de camelCase dans le nom de la méthode, en rupture avec les conventions de nommage).
Comme le précise Baeldung (Eugen Paraschiv) sur sa page https://www.baeldung.com/java-system-get-property-vs-system-getenv, les valeurs auxquelles on accède par ce biais sont des copies immuables des variables d'environnement définies au niveau du système d'exploitation.
Sous Spring, on fera plutôt appel à l'interface Environment
(héritant de l'interface PropertyResolver
) :
@Autowired
private Environment environment;
On peut ensuite lire les différentes valeurs exportées en utilisant par exemple la méthode getProperty(String key)
:
environment.getProperty("SERVER_PORT")