DotEnv : utiliser les variables d’environnement

Qu’est-ce qu’un fichier dotenv ou .env ?

Avant de parler spécifiquement des dotenv, il est nécessaire de comprendre certaines bases en programmation.

Les différentes variables

En programmation, il existe deux concepts utilisés partout : les variables et les constantes. Elles vont être utilisées au sein du code lui-même. La valeur des variables peut changer pendant l’exécution du code, tandis que la valeur des constantes ne doit pas être réassignée. Voici un exemple :

// Une constante
ADMIN_USERNAME = root

// Des variables
i = 0
i = i + 1
# i = 1 maintenant

Cependant, il existe un autre type de variables qui ne dépendent pas du programme mais de la machine : les variables d’environnement. Un programme hérite des variables d’environnement de son parent. Ainsi, un programme peut utiliser les variables définies sur votre machine. Cependant, une autre machine ne pourra peut-être pas les utiliser ; elles doivent également être définies sur cette machine. Voici quelques exemples :

# Indique le répertoire de l’utilisateur
%HOMEPATH%

# Indique le système d’exploitation utilisé
%OS%

# Définir et afficher une variable d’environnement personnalisée (seulement pour le shell actif)
TEST_VAR="Hello World!"
echo $TEST_VAR

À quoi servent les variables d’environnement et comment les utiliser ?

Les variables d’environnement sont généralement utilisées pour définir la configuration d’une application. Elles pourront, par exemple, être utilisées pour renseigner la configuration d’une base de données ou pour définir des mots de passe. Elles permettent ainsi de séparer la configuration requise par un environnement de production de celle requise par un environnement de développement.

Suivant le langage utilisé, les variables d’environnement se déclarent et s’appellent différemment. En PHP, on pourra par exemple faire :

// Déclarer une variable d’environnement
putenv('NOM_VARIABLE=valeur');
// ou
$_ENV['NOM_VARIABLE'] = 'valeur';

// Récupérer la valeur de la variable
echo getenv('NOM_VARIABLE');
// ou
echo $_ENV['NOM_VARIABLE'];

Cette méthode fonctionne, mais elle a ces limites.

Un fichier dotenv pour faciliter la gestion et améliorer la sécurité

L’intérêt des dotenv

Pourquoi utiliser un fichier dotenv s’il est possible de les définir autrement ? Si vous utilisez un système de gestion des versions comme Git, et d’autant plus si vous laissez un accès public au dépôt, il faut éviter de stocker des informations sensibles au sein de votre application. La configuration devrait être séparée du code.

Par ailleurs, les dotenv rendent la déclaration des variables d’environnement indépendante du langage et du système d’exploitation utilisés. Il est donc plus simple de gérer ces variables.

Le fonctionnement

Pour utiliser les fichiers dotenv, il faut évidemment créer un fichier .env. Il faut également utiliser un outil pour interpréter ces variables et pour pouvoir les utiliser au sein de l’application. Là où le dotenv est indépendant du langage utilisé, l’outil ne l’est pas. Suivant le langage que vous utilisez, il vous faudra charger le bon outil.

Voici quelques exemples :

• Dotenv pour Ruby
• PHPDotenv pour PHP
• Dotenv pour Javascript
• Fonctionne nativement avec Docker Compose (YAML)

Il en existe d’autres aussi bien pour d’autres langages que pour les langages cités ci-dessus. À vous de choisir celui qui vous convient le mieux, ce ne sont que des exemples.

Maintenant, voyons comment les utiliser. Voici un exemple de fichier .env :

MYSQL_USER=nomUtilisateur
MYSQL_PASSWORD=motDePasse
MYSQL_DB=nomBaseDeDonnées

Puisque l’appel du dotenv dépend du langage utilisé, je vais ignorer cette partie. Imaginons, qu’il est chargé correctement. Voici comment les variables définies pourraient être utilisées dans un fichier YAML comme docker-compose.yml :

services:
  db:
    image: mysql:5.7
    environment:
      MYSQL_DATABASE: ${MYSQL_DB}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}

Ainsi, une fois le fichier dans un dépôt Git, personne ne peut voir les informations de la base de données. Elles sont stockées en local dans le .env.

Il est également possible d’assigner une valeur par défaut si la variable n’a pas été renseignée dans le dotenv. Pour cela, il faut utiliser la notation suivante :

services:
  db:
    image: mysql:5.7
    environment:
      MYSQL_DATABASE: ${MYSQL_DB:-default_name}
      MYSQL_USER: ${MYSQL_USER:-default_user}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD:-default_password}

Il s’agit d’un exemple ; vous pouvez remplacer default_name (et les autres valeurs) par autre chose comme maBDD.

Les différentes approches

Un seul fichier .env

Il faut créer un fichier .env.example contenant les différentes variables requises par l’application. Ce fichier pourra être versionné, ainsi chaque contributeur saura quelles variables renseigner.

Ensuite, nous copierons ce fichier et nous le renommerons .env. Ce fichier ne doit pas être versionné, il faut donc l’ajouter à .gitignore. Il contiendra les différentes valeurs pour notre machine.

Plusieurs fichiers .env

D’autres créent un fichier .env qui pourra être versionné. Il contiendra, par exemple, une configuration qui doit être partagée par différentes machines.

Ils créeront ensuite un autre fichier comme .env.local ou .env.dev contenant la configuration pour la machine qu’ils utilisent.

La méthodologie Twelve-Factor App ne recommande pas cette approche. Elle conseille plutôt la première approche :

Elles ne sont jamais groupées ensemble en “environnements”, mais sont plutôt gérées indépendamment pour chaque déploiement.

Cependant, cette méthodologie ne fait pas consensus. Donc, à vous de voir l’approche qui vous convient le mieux.