Si vous avez travaillé sur une forme quelconque de développement d’applications, vous avez sûrement déjà entendu parler du terme « variables d’environnement ». Les variables d’environnement sont utilisées pour stocker les secrets de l’application et les données de configuration, qui sont récupérées par votre application en cours d’exécution lorsque cela est nécessaire.
Les variables d’environnement ajoutent de la dynamique à votre base de code statique ; vous pouvez basculer entre les ressources internes/externes en fonction de la valeur de la variable d’environnement transmise à votre application.
Cet article va vous présenter les variables d’environnement. Vous apprendrez quelques méthodes courantes de création et de gestion des variables d’environnement et comprendrez quand les utiliser. À la fin de cet article, vous serez en mesure d’utiliser efficacement et en toute confiance les variables d’environnement dans vos applications.
Sans plus attendre, commençons !
Qu’est-ce qu’une variable d’environnement ?
Pour reprendre l’explication ci-dessus, les variables d’environnement sont des variables disponibles pour votre programme/application de manière dynamique pendant l’exécution. La valeur de ces variables peut provenir de toute une série de sources – fichiers texte, gestionnaires de secrets tiers, scripts d’appel, etc.
Ce qui est important ici, c’est le fait que la valeur de ces variables d’environnement n’est pas codée en dur dans votre programme. Elles sont véritablement dynamiques et peuvent être modifiées en fonction de l’environnement dans lequel votre programme s’exécute.
Types de variables d’environnement
Il existe trois types principaux de variables d’environnement dans un système informatique basé sur Windows, et chacun d’entre eux a ses cas d’utilisation. Abordons-les un par un.
1. Variables d’environnement système
Les variables d’environnement système résident à la racine supérieure du système et sont les mêmes pour tous les processus exécutés dans un système sous tous les profils d’utilisateur du système. Votre système d’exploitation/administrateur système les définit généralement, et il est rare que vous ayez à les manipuler.
L’une des utilisations les plus courantes d’une variable d’environnement système consiste à configurer une variable PATH vers un paquetage/bibliothèque global à utiliser par tous les utilisateurs du système.
2. Variables d’environnement utilisateur
Les variables d’environnement utilisateur sont celles qui sont locales à un profil utilisateur dans les systèmes Windows. Ces variables sont utilisées pour stocker des informations spécifiques à l’utilisateur, telles que le chemin d’accès à une installation locale de bibliothèques qui ne doivent pas être utilisées par tous les utilisateurs, des valeurs spécifiques aux programmes installés uniquement pour certains utilisateurs, etc.
Vous n’avez pas besoin de l’administrateur système pour apporter des modifications à ces variables ; vous pouvez le faire vous-même en tant qu’utilisateur. Ces variables sont utiles pour mettre en œuvre des changements locaux dans votre système sans affecter les autres utilisateurs.
3. Variables d’environnement d’exécution/de processus
Les variables d’environnement du temps d’exécution se limitent au temps d’exécution ou au processus auquel elles sont associées. Elles sont généralement définies par le processus parent qui crée le nouveau processus et sont accompagnées des variables d’environnement système et utilisateur.
Vous pouvez utiliser le scriptage de terminal pour créer et stocker ces variables à la volée. Les variables d’exécution ne sont généralement pas permanentes à moins d’être scriptées, et vous devez les définir chaque fois que vous démarrez un nouveau processus.
Variables d’environnement dans les systèmes basés sur Unix
Contrairement aux systèmes Windows, les systèmes basés sur Unix ne disposent pas de trois couches de types de variables d’environnement. Dans ces systèmes, tout est stocké sous un objet var et peut être accédé/modifié par le programme en cours d’exécution.
Si vous devez définir certaines variables d’environnement comme devant être chargées par défaut à chaque fois qu’un programme s’exécute sur votre système, vous devez les définir dans des fichiers tels que .~/bashrc ou ~.profile qui sont chargés au démarrage du système.
Variables d’environnement vs pseudos variables d’environnement
Une ligne distincte de variables d’environnement dynamiques est disponible dans les systèmes Windows et DOS, connue sous le nom de pseudos variables d’environnement. Il ne s’agit pas de paires de clés et de valeurs affectées statiquement, mais plutôt de références dynamiques qui renvoient diverses valeurs lorsqu’elles sont interrogées.
Alors que vous pouvez attribuer manuellement une valeur à une variable d’environnement en utilisant la commande SET ou son équivalent, vous ne pouvez pas attribuer de valeurs aux pseudo variables d’environnement. Il existe une liste fixe de telles variables, et vous pouvez les utiliser dans votre code pour vous faciliter la tâche. Parmi les cas d’utilisation populaires, citons %CD% pour le répertoire actuel et %TIME% pour l’heure actuelle.
Pourquoi utiliser les variables d’environnement ?
Maintenant que vous comprenez ce qu’est une variable d’environnement et ses différents types, il est temps de savoir pourquoi vous devriez en faire un usage intensif dans vos applications.
Séparation des préoccupations
L’une des raisons les plus importantes pour lesquelles vous devriez utiliser des variables d’environnement dans vos applications est d’adhérer à un principe de conception populaire et utile – la séparation des préoccupations. Ce principe de conception stipule que les programmes informatiques doivent être divisés en sections distinctes afin de les gérer efficacement. Chaque section doit être basée sur l’une des préoccupations principales du programme, et il doit y avoir un couplage minimal entre ces sections.
Vous pouvez considérer la configuration de l’application comme l’une de ces préoccupations ; elle doit donc être séparée du programme principal. L’une des meilleures façons de le faire est de la stocker dans un fichier externe et de l’injecter en cas de besoin. Les variables d’environnement vous aident à isoler les données de configuration critiques de l’application à l’aide de fichiers env ou de stockages de variables distants. Ainsi, vos développeurs ne reçoivent que les informations dont ils ont besoin.
Maintien de jeux de configuration indépendants dans tous les environnements
Outre l’isolation des configurations d’applications de votre code source, vous devez également pouvoir passer facilement d’un ensemble de données de configuration à un autre. Si vous choisissez de coder en dur les valeurs de configuration de votre application dans votre code source, il peut devenir presque impossible de remplacer ces valeurs en fonction de conditions externes telles que les environnements de déploiement.
L’utilisation de variables d’environnement vous aide à découpler vos données de configuration de votre code et à standardiser la manière dont ces informations sont fournies à votre application, ce qui vous permet de modifier/changer les informations fournies à la volée.
Sécurisation des secrets
Les secrets de votre application relèvent des informations sensibles. Si de mauvaises personnes mettent la main dessus, elles peuvent accéder à l’architecture interne de votre appli et aux ressources de tiers. Les exemples courants sont les clés AWS et les détails des comptes système. L’accès non autorisé à ces clés peut entraîner une perte d’argent et de données d’application. Les pirates peuvent même aller jusqu’à empêcher votre application de fonctionner normalement.
Il est donc vital que vous protégiez ces secrets. Si vous les laissez traîner dans votre base de code, tous vos développeurs peuvent y avoir accès. Si vous ne suivez pas les méthodes de dissimulation de code appropriées, vos applications peuvent faire l’objet d’une ingénierie inverse pour récupérer les clés qui se trouvent dans votre code. Isoler ces secrets via des variables d’environnement peut empêcher de tels scénarios de se produire.
Exemples de cas d’utilisation des variables d’environnement
Maintenant que vous avez une idée claire du fonctionnement des variables d’environnement et de la manière dont vous devez les utiliser efficacement, voici quelques scénarios courants dans lesquels vous pouvez utiliser les variables d’environnement :
- Type d’environnement : Les variables d’environnement sont souvent utilisées pour stocker le nom de l’environnement dans lequel l’application est en cours d’exécution. La logique de l’application peut utiliser cette valeur pour accéder au bon ensemble de ressources ou activer/désactiver certaines fonctionnalités ou sections de l’application.
- Nom de domaine : Le nom de domaine d’une application peut varier en fonction de son environnement. L’isoler vous permet également de modifier facilement le nom de domaine de votre application sans avoir à rechercher ses occurrences dans l’ensemble de la base de code.
- URL d’API : Chaque environnement de votre application peut avoir des API déployées dans différents environnements également.
- Clés privées : Les clés des services et ressources payants doivent être isolées du code source de l’application afin qu’elles ne tombent pas accidentellement dans de mauvaises mains.
- Numéros de compte de service, etc : Vous pouvez varier d’autres informations spécifiques au système, telles que les numéros de compte de service, les keytabs, etc., en fonction de l’environnement de l’application pour la gestion et la surveillance des ressources.
Comment stocker les variables d’environnement
Maintenant que vous comprenez pourquoi les variables d’environnement sont importantes, il est temps d’examiner comment vous pouvez les stocker et y accéder dans votre application. Nous vous présentons ci-dessous trois méthodes différentes mais populaires de gestion des variables d’environnement dans une application.
Utilisation des fichiers .env
Les fichiers.env sont sans aucun doute la façon la plus simple et la plus populaire de gérer les variables d’environnement. L’idée est simple : vous stockez vos variables d’environnement dans un fichier nommé .env à la racine de votre projet. L’application recherche les variables dans ce fichier et les charge pour les utiliser pendant l’exécution. Voici à quoi ressemble un fichier .env typique :
VAR_UNO=UNE_CLÉ_ICI
VAR_DOS=AUTRE_CLÉ_ICI
.env les fichiers vous permettent également de définir des ensembles de variables d’environnement et d’y accéder en fonction de l’environnement d’exécution de votre application ou d’autres facteurs. Au lieu d’enregistrer le fichier sous le nom de .env, vous pouvez créer plusieurs fichiers et les conserver sous les noms .env.dev et .env.prod. Dans ces fichiers, vous pouvez définir les mêmes ensembles de variables, mais avec des valeurs différentes, en fonction de l’environnement.
Exemple de modèle
Lorsque vous travaillez avec les fichiers .env, il n’est pas recommandé de les ajouter à votre système de contrôle de version (nous y reviendrons plus tard). Par conséquent, vous devriez définir un « .env.template » dans votre projet afin que les développeurs puissent suivre le modèle et créer un fichier .env pour eux-mêmes localement.
Voici à quoi ressemblerait un fichier .env.template:
VAR_UNO= # Votre valeur ici
VAR_DOS= # Votre valeur ici
Il n’est pas nécessaire qu’il suive une quelconque convention, tant qu’il est explicite pour votre équipe de développement. Pour simplifier ce processus, vous pouvez également utiliser des paquets tels que env-template.
Avantages
Voici quelques raisons pour lesquelles vous devriez envisager d’utiliser les fichiers .env pour gérer les variables d’environnement dans votre application.
Simple à utiliser
Cette méthode est la plus simple dans la lignée des techniques de gestion des variables d’environnement. Tout ce que vous avez à faire est de créer un fichier texte brut qui contient vos secrets et de le stocker à la racine de votre projet.
Le changement d’environnement est aussi simple que de modifier le fichier env lui-même. Vous pouvez stocker plusieurs fichiers sous les noms .env.dev, .env.prod, .env.uat, etc., et configurer votre code source pour qu’il accède à ces fichiers en fonction de l’environnement dans lequel il est exécuté.
Accès local
Vous pouvez facilement configurer les fichiers .env dans un environnement de développement local. Contrairement aux gestionnaires de variables natifs de la plateforme, vous n’avez pas besoin de déployer votre application pour exploiter la fonctionnalité des variables d’environnement. Par rapport aux gestionnaires de secrets, les fichiers .env sont plus faciles à configurer localement, et il n’y a pas de dépendance au réseau pour accéder aux secrets de votre application.
Support open source
Il existe de nombreux paquets open source pour vous aider à charger et à gérer les secrets d’applications à partir des fichiers env. Vous n’avez pas besoin de dépendre de services payants, et vos options ne sont pas limitées en matière de gestion des secrets d’applications. Il existe un large éventail de bibliothèques tierces à code source ouvert pour vous aider à gérer vos fichiers env. Quelques exemples populaires/utiles sont dotenv, env-template, et cross-env.
Inconvénients
Voici quelques inconvénients des fichiers env que vous devriez connaître avant de les utiliser dans vos projets.
Formatage
Les fichiers .env stockent les secrets de votre application sous la forme de paires clé-valeur. Le format habituel pour stocker les variables d’environnement dans un fichier .env est le suivant :
Clé1=Valeur1
Vous devez respecter strictement ce format pour que votre application puisse lire vos secrets d’application avec succès. Si vous faites une petite erreur quelque part entre des dizaines ou des centaines de lignes de variables d’environnement, l’ensemble du fichier risque de ne pas être analysé, et votre programme lancera des erreurs sans rapport les unes avec les autres. Le fait qu’il y ait une erreur d’analyse dans votre fichier .env ne sera peut-être même pas mis en évidence. C’est pourquoi vous devez être prudent lorsque vous utilisez les fichiers .env.
Risque de fuite accidentelle de secrets lors du partage/stockage
Les fichiers .env étant des fichiers texte en clair, ils sont vulnérables à une exposition accidentelle lorsqu’ils sont stockés sur un disque dur partagé ou envoyés via un réseau non sécurisé. Vous devez donc faire particulièrement attention à ne pas divulguer les secrets de votre application lorsque vous les avez stockés à l’aide des fichiers .env.
Utilisation du stockage des variables natives de la plateforme
Une autre option populaire pour stocker les variables d’environnement consiste à s’appuyer sur le stockage des variables de votre plateforme de déploiement. La plupart des environnements de déploiement, tels que Heroku, AWS, Netlify, etc., fournissent un espace permettant aux utilisateurs de téléverser des secrets qui sont ensuite injectés dans le runtime de votre application. Vous pouvez consulter la documentation de votre plateforme de déploiement pour savoir si elle le prend en charge et comment l’utiliser.
Voici un aperçu rapide du gestionnaire de variables d’environnement de Netlify :
Avantages
Voici pourquoi vous devriez envisager d’utiliser des solutions de stockage de variables natives de la plateforme.
Hautement sécurisé
Puisque cette option est entièrement gérée par votre plateforme de déploiement, elle est forcément plus sûre que le stockage de vos secrets dans un fichier texte brut. Vous pouvez contrôler qui a accès au gestionnaire de variables, et vous pouvez être sûr que les secrets ne seront jamais poussés accidentellement vers votre VCS.
Facile à mettre à jour
La mise à jour des variables d’environnement lorsqu’elles sont stockées indépendamment est plus simple : vous n’avez pas besoin de modifier votre code source et de créer une nouvelle version pour celui-ci. Vous pouvez simplement modifier les valeurs dans la plateforme et reconstruire votre projet. Il recevra les nouvelles valeurs lors de son prochain démarrage.
Les problèmes de formatage ont également disparu, puisque la plupart des gestionnaires de déploiement spécifiques à une plateforme lintent les clés au fur et à mesure que vous les saisissez. Dans des cas comme celui de Netlify, vous entrez les secrets sous une forme préformatée, ce qui élimine les risques de faire une erreur de formatage.
Permet la collaboration
Les plateformes de déploiement étant accessibles à toute votre équipe, vous pouvez facilement partager les secrets avec les bonnes personnes sans avoir à envoyer des fichiers texte via Internet. Vous pouvez contrôler qui a accès au gestionnaire de variables (dans la plupart des cas) et l’utiliser comme un dépôt central pour les secrets de votre application.
Inconvénients
Bien que les gestionnaires de variables natifs de la plateforme semblent être la solution dont vous avez besoin, il y a quelques problèmes que vous devriez garder à l’esprit avant d’opter pour eux.
Dépendance à la plateforme
Comme leur nom l’indique, ils sont hautement spécifiques à la plateforme que vous utilisez. Dans certains cas, il se peut que votre plateforme de déploiement ne propose même pas un tel service. Changer de plateforme de déploiement pour avoir accès à un tel service pourrait ne pas sembler être la meilleure décision.
Non uniforme
Puisqu’ils sont offerts et gérés entièrement par la plateforme de déploiement, de tels services peuvent être hautement non-uniformes. Le déplacement des variables d’une plateforme à l’autre peut être problématique. Vous ne pouvez même pas supposer que chaque plateforme de déploiement offre les options d’importation/exportation des variables d’environnement. Bien que la plupart le fassent, c’est entièrement entre les mains de la plateforme. Si vous avez une longue liste de variables d’environnement, il y a de fortes chances que vous vous retrouviez dans une situation de verrouillage du fournisseur à petite échelle.
Pas de support local
Si ces services sont parfaits pour accéder aux variables d’environnement dans les déploiements de votre application, il est rare que vous puissiez les utiliser en développant votre application localement. Dans la plupart des cas, vous devrez recourir à la gestion des fichiers locaux .env. Bien que cela remplisse l’objectif, cela complique inutilement l’ensemble de la configuration.
Utilisation de gestionnaires de secrets
La troisième option, qui en est encore à ses débuts, consiste à utiliser des gestionnaires de secrets dédiés. Les gestionnaires de secrets sont des services tiers qui vous permettent d’isoler complètement les secrets de votre application de votre code source/déploiement et de les récupérer en cas de besoin via des connexions réseau sécurisées.
Avantages
Voici quelques-uns des avantages que les gestionnaires de secrets offrent par rapport aux autres méthodes de gestion des secrets.
Hautement sécurisé
Étant donné que vos secrets sont stockés dans un service complètement isolé, vous pouvez être sûr que vous ne les divulguerez probablement jamais accidentellement en les partageant avec vos collègues ou via des commits de contrôle de version. La plateforme tierce se charge de garder vos secrets en sécurité, et elle a généralement des accords de niveau de service assez stricts en matière de sécurité des données.
Même lorsque vous accédez aux secrets depuis l’intérieur de votre application, la plupart des gestionnaires de secrets fournissent leur propre code client qui peut récupérer et autoriser l’accès aux secrets en toute sécurité lorsque cela est nécessaire.
Uniformité dans tous les environnements
Les secrets étant désormais indépendants de votre base de code et de vos environnements de déploiement, vous pouvez désormais bénéficier d’une uniformité entre les environnements. Vous n’avez pas besoin de prendre des dispositions particulières pour accueillir de nouveaux développeurs ou de prendre des mesures spéciales avant de mettre votre application en production – la plupart de ces aspects sont simplifiés ou pris en charge par votre gestionnaire de secrets.
Inconvénients
Bien que les gestionnaires de secrets semblent être la meilleure solution possible pour la gestion des variables d’environnement, ils ont leur propre lot d’inconvénients.
Coût
La gestion des variables d’environnement est une activité interne aux projets depuis longtemps. Même la plupart des plateformes de déploiement fournissent cette fonctionnalité gratuitement puisqu’elles n’encourent aucun coût supplémentaire pour cela.
Cependant, les gestionnaires de secrets étant des services totalement indépendants, ils ont leur propre coût d’exploitation. Les utilisateurs doivent donc supporter ce coût lorsqu’ils utilisent ces services.
Les premiers stades de la technologie
Comme la technologie est relativement nouvelle, on ne peut jamais être sûr de la façon dont elle sera adoptée par l’industrie dans les jours à venir. Bien que les gestionnaires secrets soient très prometteurs en termes de sécurité et de facilité de gestion, le facteur coût et les problèmes de traitement des données pourraient entraîner une adoption plutôt lente de la technologie.
Comment travailler avec les variables d’environnement
Maintenant que vous comprenez le concept des variables d’environnement et les moyens disponibles pour les implémenter dans une application, voyons comment vous pouvez travailler avec elles via le terminal et dans les applications basées sur Node.js.
Variables d’environnement dans le terminal
Puisque les variables d’environnement sont spécifiques aux processus, vous pouvez les définir et les supprimer via le terminal afin qu’elles soient transmises aux processus que votre terminal génère.
Recherche des valeurs des variables
Pour afficher la liste des variables d’environnement dans votre terminal, vous pouvez exécuter les commandes suivantes spécifiques à votre système d’exploitation.
Sous Windows :
set
Sous Linux ou MacOS :
env
Ceci affichera une liste de toutes les variables d’environnement disponibles dans votre terminal en cours d’exécution.
Définition de nouvelles variables
Pour définir de nouvelles variables via le terminal, vous pouvez exécuter les commandes suivantes.
Sous Windows :
set "VAR_NAME=var_value"
Sous Linux ou MacOS :
VAR_NAME=var_value
Suppression des variables
Pour supprimer une variable d’environnement, vous devez exécuter les commandes suivantes.
Sous Windows :
set "VAR_NAME="
Sous Linux ou MacOS :
unset VAR_NAME
Veuillez noter que les méthodes présentées ci-dessus ne servent qu’à créer/supprimer des variables d’environnement pour la session actuelle du terminal.
Variables d’environnement dans Node.js
JavaScript est l’un des langages de programmation les plus populaires à l’heure actuelle. Il est largement utilisé dans la création d’applications backend et frontend, ce qui en fait l’un des langages de programmation les plus polyvalents.
Node.js est l’un des frameworks JS les plus utilisés pour créer des applications backend. Voyons comment vous pouvez gérer facilement les variables d’environnement dans les applications basées sur Node.js.
Accéder directement aux variables d’environnement
Node.js vous fournit une référence aux variables d’environnement de votre processus actuel via process.env. Vous pouvez visualiser les variables d’environnement disponibles en affichant cet objet sur la console.
Cet objet contiendra des variables disponibles pour le processus Node en cours d’exécution. Vous pouvez y ajouter de nouvelles variables en les déclarant avant de lancer votre application, comme ceci :
VAR_UNO=SOMETHING node index.js
Comme vous pouvez le voir, la nouvelle variable est ajoutée à votre objet process.env. Cependant, vous ne pouvez pas accéder aux variables définies sous un fichier .env via cette méthode. Pour cela, vous devez utiliser un paquet comme dotenv pour charger le fichier .env au moment de l’exécution.
Utilisation du paquet dotenv pour accéder aux fichiers .env
Le paquet dotenv vous aide à charger les variables d’environnement stockées dans les fichiers .env à la racine de votre projet. Son utilisation est simple, vous devez l’installer en exécutant la commande suivante :
npm i [email protected]
Ensuite, vous devez ajouter la ligne de code suivante au début du code de votre application pour initialiser le paquet :
require('dotenv').config()
C’est tout ! Maintenant, les secrets que vous stockez dans un fichier .env à la racine de votre projet seront chargés dans votre objet process.env dès que l’application démarrera. Nous verrons cette méthode en action plus tard dans le tutoriel suivant.
Tutoriel sur les variables d’environnement
La meilleure façon de comprendre un concept technique est de le regarder en action. Voici un tutoriel rapide qui vous aidera à vous familiariser avec les variables d’environnement et à apprendre leur utilisation en détail.
Dans le guide suivant, nous allons vous montrer comment utiliser les variables d’environnement par les trois moyens que nous avons mentionnés plus haut : les fichiers.env, les gestionnaires de variables natifs de la plateforme et les gestionnaires de secrets. Toutes ces méthodes nécessitent une étape commune, qui consiste à configurer un projet Node.js de base.
Premièrement : Créer un projet Node.js
Pour commencer, assurez-vous que Node.js est installé sur votre système. Une fois que vous l’avez installé sur votre système, vous aurez accès à npm (abréviation de Node Package Manager). npm vous aide à installer des paquets node à partir du registre global npm via la ligne de commande. Il sera utile pour installer les paquets liés à notre projet de test.
Ensuite, ouvrez un terminal et créez un nouveau répertoire. Initialisez un nouveau projet Node dans celui-ci :
mkdir my-app
cd my-app
npm init
Continuez d’appuyer sur la touche Entrée pendant les questions entrantes pour accepter les options par défaut. Une fois fait, votre terminal devrait ressembler à ceci :
Vous pouvez maintenant ouvrir ce projet à l’aide d’un IDE tel que Visual Studio Code ou IntelliJ IDEA.
Créez un nouveau fichier à la racine de votre dossier de projet et enregistrez-le sous le nom index.js. Ce sera le point de départ de votre application. Ensuite, installez Express pour créer et tester rapidement des serveurs REST :
npm i express
Une fois Express installé, collez le morceau de code suivant dans votre fichier index.js:
const express = require("express")
const app = express()
app.get("/", (req, res) => {
res.send("Hello world!")
})
app.listen(8080);
Ceci est un extrait de démarrage pour un point « Hello World » basique utilisant Node.js et Express. Exécutez ce qui suit sur votre ligne de commande :
node index.js
Ceci démarrera votre application node + express. Si vous allez sur http://localhost:8080 dans votre navigateur web, vous obtiendrez un résultat similaire :
Cela indique que vous avez configuré votre application correctement ! L’étape suivante consiste à mettre à jour votre application pour utiliser les variables d’environnement. Mettez à jour le code dans index.js pour qu’il corresponde à l’extrait suivant :
const express = require("express")
const app = express()
app.get("/", (req, res) => {
// the responseMessage object extracts its values from environment variables
// If a value is not found, it instead stores the string "not found"
const responseMessage = {
environment: process.env.environment || "Not found",
apiBaseUrl: process.env.apiBaseUrl || "Not found"
}
res.send(responseMessage)
})
app.listen(8080);
Au lieu d’envoyer un message « Hello world ! » dans la réponse, nous allons maintenant envoyer un objet JSON qui transporte deux informations :
environment: Indique l’environnement actuel dans lequel l’app est déployéeapiBaseUrl: Porte l’URL de base pour une API hypothétique. Nous modifierons la valeur de cette URL en fonction de l’environnement dans lequel l’application est déployée.
En cas d’impossibilité d’accéder aux variables d’environnement, l’objet contiendra « Not found » comme valeurs pour les deux clés décrites ci-dessus. Avant de poursuivre, exécutez à nouveau la commande node index.js et vous obtiendrez la sortie suivante :
env.Cela indique que votre application est actuellement incapable d’accéder aux variables d’environnement. En plus de cela, nous n’avons même pas défini les valeurs de ces variables. Voyons les différentes façons de le faire dans les sections suivantes.
Type 1 : Ajouter des variables d’environnement via les fichiers env
Commençons par la manière la plus basique d’ajouter des variables d’environnement – les fichiers env. Dans la racine de votre projet, créez un nouveau fichier appelé .env et stockez-y le code suivant :
environment=DEV
apiBaseUrl=http://dev.myApi.com:8080/v1
Ensuite, redémarrez votre application en exécutant à nouveau la commande node index.js et vérifiez le résultat :
env.Vous constaterez que la sortie reste la même. En effet, même si vous avez défini la valeur des variables d’environnement, vous n’avez pas vraiment indiqué à votre application où les trouver. C’est là que des paquets tels que dotenv entrent en jeu.
Exécutez la commande suivante pour installer dotenv:
npm i [email protected]
Pour commencer à utiliser dotenv dans votre code, ajoutez le code suivant à la ligne numéro 2 de votre index.js :
require('dotenv').config()
Ensuite, redémarrez l’application et vérifiez la sortie :
env.Comme vous pouvez le voir, les valeurs des variables d’environnement ont été chargées depuis votre fichier .env!
Maintenant, pour pimenter les choses, renommons notre fichier .env en .env.dev et créons un autre fichier du nom de .env.staging. Collez le morceau de code suivant dans le nouveau fichier :
environment=STAGING
apiBaseUrl=http://staging.myApi.com:3000/v1
Une fois que vous avez terminé, remplacez la ligne numéro 2 de votre fichier index.js par le morceau de code suivant :
require('dotenv').config({
path: "STAGING" === process.env.NODE_ENV?.toUpperCase() ? './.env.staging' : './.env.dev'
})
console.log(process.env.NODE_ENV)
Ce qui a changé ici, c’est que nous demandons maintenant au paquet dotenv d’aller chercher le contenu des variables d’environnement dans l’un des deux fichiers disponibles en fonction d’une autre variable d’environnement appelée NODE_ENV. D’où vient la valeur de cette variable d’environnement ? De votre terminal.
Pour tester cette configuration, exécutez votre application à l’aide de la commande suivante :
NODE_ENV=DEV node index.js
Si vous vous rendez maintenant sur localhost:8080, vous remarquerez la réponse suivante :
Maintenant, fermez l’application en cours d’exécution et exécutez-la à nouveau en utilisant la commande suivante :
NODE_ENV=STAGING node index.js
En allant sur localhost:8080, vous obtiendrez maintenant la réponse suivante :
Voici comment vous pouvez utiliser les fichiers .env pour accéder à différents ensembles de variables en fonction de conditions externes. La condition externe ici est la variable d’environnement externe NODE_ENV qui est essentiellement une variable d’environnement utilisateur alors que environment et apiBaseUrl étaient des variables d’environnement d’exécution. Le profil utilisateur appelant fournit la valeur de la variable NODE_ENV et l’application l’utilise pour prendre des décisions internes.
Si vous êtes sous Windows, vous pourriez rencontrer des difficultés lors de l’exécution des deux commandes précédentes. Le terminal Windows pourrait ne pas vous permettre d’assigner des variables d’environnement utilisateur à la volée en utilisant la syntaxe KEY=VALUE (sauf s’il s’agit de Bash sous Windows).
Une solution rapide dans ce cas est de faire usage des scripts et de cross-env.
Installez cross-env en exécutant la commande suivante :
npm i --save-dev cross-env
Ensuite, allez dans votre fichier package.json et mettez à jour la clé scripts pour qu’elle corresponde à ceci :
// …
"scripts": {
"test": "echo "Error: no test specified" && exit 1",
"start-dev": "cross-env NODE_ENV=DEV node index.js",
"start-staging": "cross-env NODE_ENV=STAGING node index.js"
},
// …
Vous pouvez maintenant exécuter les commandes suivantes pour lancer votre application avec deux ensembles différents de variables d’environnement :
npm run start-dev # to start with dev variables
npm run start-staging # to start with staging variables
Il s’agit d’une correction universelle et vous pouvez utiliser ces scripts sur bash/zsh également.
Ensuite, voyons comment utiliser un gestionnaire de variables tiers.
Type 2 : Utiliser le gestionnaire de variables d’environnement natif de Heroku
Pour pouvoir suivre cette partie du tutoriel, vous aurez besoin d’un compte Heroku. Allez-y et créez-le avant de continuer.
Avant de déployer l’application sur Heroku, il y a quelques changements que vous devrez apporter à votre code. Tout d’abord, ajoutez un nouveau script dans votre package.json appelé start :
"scripts": {
"test": "echo "Error: no test specified" && exit 1",
"start": "node index.js",
"start-dev": "cross-env NODE_ENV=DEV node index.js",
"start-staging": "cross-env NODE_ENV=STAGING node index.js"
},
Ce script sera utilisé par Heroku pour exécuter votre application une fois déployée. Aussi, allez à la dernière ligne de votre fichier index.js et mettez-la à jour comme suit :
app.listen(process.env.PORT || 3000);
Cela garantira que l’application est déployée sur le port spécifié par Heroku.
Ensuite, vous devez installer le CLI Heroku localement pour pouvoir accéder à vos applications Heroku depuis votre ligne de commande. Pour ce tutoriel, vous pouvez utiliser la commande suivante pour installer le CLI :
npm i -g heroku
Cependant, les docs de Heroku recommandent de l’installer via l’une des autres méthodes listées dans le lien mentionné ci-dessus pour un meilleur support. Une fois installé, exécutez la commande suivante pour vous connecter à votre compte Heroku :
heroku login
Une fois cela fait, allez sur dashboard.heroku.com et connectez-vous à votre compte. Ensuite, créez une nouvelle application en cliquant sur Nouveau > Créer une nouvelle application.
Sur la page suivante, cliquez sur le bouton Créer une appli sans entrer de détails. Cela créera une nouvelle application Heroku pour vous avec un nom aléatoire.
Voici à quoi ressemblerait le tableau de bord de votre application :
Cette page contient également des instructions sur la façon de déployer votre application sur Heroku via le CLI. Voici la liste des commandes que vous devez exécuter pour déployer votre application sur Heroku :
git init
heroku git:remote -a whispering-shelf-49396 # change whispering-shelf-49396 with the name of your app. You can get it in your dashboard
git add index.js package-lock.json package.json # do not push the .env files since we'll provide that via the in-app secrets manager git commit -am "Initial commit" git push heroku main Une fois le déploiement terminé avec succès, vous pouvez visualiser l’application déployée via le tableau de bord en cliquant sur le bouton Ouvrir l’application
Si vous avez tout fait correctement, vous verrez la réponse suivante :
Pourquoi cela se produit-il, pensez-vous peut-être ? C’est parce que nous n’avons pas encore fourni les variables d’environnement à notre application sous une forme quelconque. Si vous vérifiez les commandes que vous avez utilisées pour déployer l’application, vous remarquerez que nous n’avons pas poussé les fichiers .env vers notre contrôle de version. Nous n’avons pas non plus défini la valeur NODE_ENV dans le script de démarrage.
Pour injecter des variables d’environnement dans votre application maintenant, vous devez naviguer vers Settings > Config Vars sur votre tableau de bord Heroku. En cliquant sur Reveal Config Vars, vous verrez un écran similaire :
Vous pouvez maintenant saisir le contenu de votre fichier .env ici :
Si vous revenez en arrière et rafraîchissez l’URL de votre application, vous remarquerez que les valeurs ont été mises à jour :
C’est ainsi que vous pouvez utiliser le gestionnaire de secrets d’une plateforme de déploiement pour gérer vos variables d’environnement. Cependant, cela vous oblige à gérer manuellement les variables d’environnement via le tableau de bord de la plateforme. Comme vous pouvez le voir pour Heroku, il n’y a pas d’option pour importer un grand dump de variables d’environnement à partir d’un fichier, vous obligeant à saisir chacune d’entre elles une par une. Cela peut parfois devenir assez gênant.
La section suivante présente une méthode plus efficace de gestion des secrets d’applications – les gestionnaires de secrets.
Type 3 : Utiliser Doppler pour gérer les variables d’environnement
Les méthodes présentées ci-dessus n’offrent pas d’uniformité entre les plateformes. En général, vous ne vous fiez pas aux fichiers env lors du déploiement en production, et il n’est pas possible d’utiliser les gestionnaires de variables natifs de la plateforme lorsque vous travaillez localement. Les gestionnaires secrets comme Doppler comblent cette lacune.
Pour l’essayer par vous-même, vous devez d’abord créer un compte gratuit sur Doppler.
Une fois que c’est fait, vous pouvez suivre le processus. Il est fort probable qu’il vous créera automatiquement un projet type sous le nom de example-project. Pour plus de simplicité, laissons-le de côté et créons un nouveau projet pour notre cas d’utilisation.
Allez dans le tableau de bord et cliquez sur l’icône plus à côté de Projets.
Saisissez son nom comme « my-app » et procédez. Voici à quoi devrait ressembler le projet une fois qu’il sera prêt :
Cliquez sur l’élément de liste dev config. Cliquez sur Add New Secret et ajoutez deux secrets comme suit :
Cliquez sur le bouton Enregistrer pour sauvegarder vos modifications. Notez que Doppler ne prend pas en charge la casse camel lorsque vous nommez vos secrets. Bien qu’il soit généralement préférable de garder les noms de secrets en majuscules, l’utilisation de Doppler ne vous laisse pas d’autres options. Pour identifier les secrets récupérés par Doppler, nous les avons préfixés avec le mot « secret » DP_
Maintenant que les variables sont créées et stockées dans Doppler, intégrons-les dans notre base de code. Pour cela, vous devez configurer le CLI de Doppler. Voici un bref aperçu de ce que vous devez faire.
Tout d’abord, installez le CLI localement en suivant les instructions spécifiques à votre système d’exploitation. Ensuite, connectez-vous au CLI de Doppler avec votre compte nouvellement créé en utilisant la commande suivante :
doppler login
Une fois connecté, exécutez la commande suivante pour vous connecter à votre projet Doppler distant depuis votre CLI :
doppler setup
Une fois que vous vous êtes connecté au bon projet, vous pourrez accéder à vos secrets via la commande suivante :
doppler run
Cependant, nous n’allons pas exécuter cette commande directement. Nous allons plutôt l’ajouter à l’un de nos scripts d’exécution afin qu’elle soit exécutée automatiquement à chaque fois que l’application démarre. Mettons à jour le fichier package.json avec le nouveau script d’exécution pour l’environnement dev:
// …
"scripts": {
"test": "echo "Error: no test specified" && exit 1",
"start": "node index.js",
"start-dev": "doppler run -- node index.js", // This has to be updated
"start-staging": "cross-env NODE_ENV=STAGING node index.js"
},
// …
Rappelez-vous également que nous avons créé de nouveaux noms de variables dans Doppler qui commencent par DP_. Nous devrons donc mettre à jour notre fichier index.js pour afficher également cette variable :
const express = require("express")
require('dotenv').config({
path: "STAGING" === process.env.NODE_ENV?.toUpperCase() ? './.env.staging' : './.env.dev'
})
console.log(process.env.NODE_ENV)
const app = express()
app.get("/", (req, res) => {
// the responseMessage object extracts its values from environment variables
// If a value is not found, it instead stores the string "not found"
const responseMessage = {
environment: process.env.environment || "Not found",
apiBaseUrl: process.env.apiBaseUrl || "Not found",
DP_ENVIRONMENT: process.env.DP_ENVIRONMENT || "Not found" // Add the new variable here
}
res.send(responseMessage)
})
app.listen(process.env.PORT || 3000);
Pour voir les choses en action, exécutez la commande suivante :
npm run start-dev
Voici à quoi devrait ressembler http://localhost:3000 maintenant :
La troisième variable de la liste (DP_ENVIRONMENT) est récupérée directement de Doppler.
Ensuite, vous pouvez connecter Doppler à votre plateforme de déploiement pour accéder à ces secrets via votre application déployée. Pour ce faire, commençons par créer un nouvel environnement dans Doppler pour un nouvel ensemble de secrets de déploiement.
Retournez à la page d’accueil de votre projet my-app. Cliquez sur l’unique élément de la liste Staging:
Vous remarquerez que les deux variables secrètes que vous avez définies dans l’environnement dev sont déjà disponibles ici mais qu’il leur manque des valeurs :
Ajoutez les valeurs suivantes et cliquez sur Enregistrer:
Une fois que vous avez terminé ici, cliquez sur l’onglet Integrations et sur Add Sync sur cette page pour commencer à vous connecter à votre plateforme de déploiement. Vous recevrez une liste des plateformes avec lesquelles Doppler peut s’intégrer :
Puisque notre application est déployée sur Heroku, cliquons sur Heroku. Suivez les étapes à l’écran pour connecter votre compte Heroku à Doppler et fournir les rôles d’accès nécessaires. Une fois qu’il est connecté, vous atteindrez un écran similaire :
Sélectionnez le Project Type comme App, choisissez votre application Heroku dans la liste des applis disponibles, choisissez stg comme Config à synchroniser, et Do Not Import dans Import Options, puisque nous ne voulons pas importer de secrets de Heroku à Doppler.
Cliquez sur Set Up Integration lorsque vous avez terminé. Vous atteindrez un écran similaire lorsque l’intégration est bien réalisée :
Maintenant, si vous vérifiez la section Config Vars dans le tableau de bord de votre application Heroku, vous remarquerez que les variables de Doppler ont été ajoutées automatiquement aux config vars de votre déploiement Heroku :
Vous remarquerez également que les deux variables d’environnement originales (environment et apiBaseUrl) ont été supprimées. Cela s’est produit parce que nous avons choisi Do Not Import sous Import Options. Vous pouvez aller de l’avant et les ajouter à nouveau dans Heroku si nécessaire.
Bien que la présence des nouvelles variables d’environnement dans la section Config Vars de Heroku démontre que vous avez réussi à configurer Doppler pour gérer les secrets à la fois localement dans votre environnement de développement et dans votre environnement de déploiement, vous pouvez continuer et déployer le code mis à jour sur Heroku pour voir les changements dans l’application déployée. Voici à quoi cela ressemblera une fois terminé :
Ceci termine le tutoriel pour configurer les variables d’environnement dans un projet Node.js en utilisant trois méthodes populaires. Ensuite, voyons comment vous pouvez vous assurer que vos variables d’environnement et leurs fichiers sont sécurisés lorsqu’ils sont utilisés.
Comment assurer la sécurité des fichiers de variables d’environnement
Bien que les variables d’environnement soient une ressource utile dans les pratiques DevOps modernes, vous devez être conscient des implications qu’elles peuvent avoir en matière de sécurité. Voici quelques conseils que vous pouvez utiliser pour garder vos fichiers de variables d’environnement sécurisés et à l’abri des regards indiscrets.
Gardez les fichiers env hors du contrôle de version
L’une des choses les plus importantes que vous devez garder à l’esprit lorsque vous manipulez des secrets est de les garder hors du contrôle de version. Le contrôle de version est destiné uniquement au suivi des modifications du code source de votre application. Tout ce qui entre dans un système de contrôle de version y reste jusqu’à ce qu’il soit supprimé explicitement, et la plupart des membres de votre équipe ont accès à ces données historiques à des fins de référence.
Si vous avez stocké les clés de votre seau de stockage AWS ou d’un service API payant dans un fichier env pour l’utiliser dans votre application, vous ne souhaitez pas le partager avec l’ensemble de votre équipe de développement, sauf si elle doit y avoir accès. Si votre projet est en open source sur une plateforme comme GitHub, ajouter des fichiers env à votre VCS pourrait signifier le partager avec le monde entier ! Les fichiers env sont destinés à être stockés localement. Vous pouvez fournir à chaque environnement de déploiement les fichiers env pertinents via des méthodes dédiées.
Ajoutez toujours le fichier env à votre fichier .gitignore (en supposant que vous utilisez git pour le contrôle de version) ou utilisez tout autre moyen pour que votre VCS ignore les fichiers env lors de la validation des modifications. Vous pouvez envisager d’ajouter un fichier env modèle à votre VCS afin que tout autre membre de l’équipe puisse l’utiliser comme référence pour créer ses fichiers env localement.
Vérifiez le nom du paquet avant l’installation
Puisque vous installez généralement la plupart des paquets à partir de NPM lorsque vous travaillez avec une application Node.js, vous devez faire très attention en le faisant. Il est bien connu que n’importe qui peut créer et déployer un paquet NPM. Et il n’est pas non plus surprenant que les gens fassent souvent des erreurs en tapant le nom d’un paquet qu’ils veulent installer.
De multiples cas ont été constatés où des paquets malveillants portant des noms similaires à certains paquets populaires ont été accidentellement installés par des utilisateurs en raison d’erreurs de frappe. De tels paquets sont conçus pour accéder aux variables d’environnement de votre application et les envoyer via Internet à leurs créateurs.
La seule façon de vous sauver est d’être vigilant lorsque vous installez de nouveaux paquets depuis l’Internet.
Préférez les gestionnaires secrets aux fichiers env
Avec des problèmes tels que les fuites accidentelles lors du partage et les erreurs de formatage, les fichiers env ne sont certainement pas la meilleure option disponible pour la gestion des secrets. Entrez dans les gestionnaires de secrets. Les gestionnaires de secrets tels que Doppler vous permettent d’isoler complètement les secrets de votre application de votre code source et de les gérer dans une plateforme dédiée.
Vous pouvez autoriser votre équipe à accéder à ces secrets directement sur la plateforme, et votre application peut y accéder via des connexions cryptées sur Internet. Il résout tous les problèmes associés aux fichiers env tout en vous offrant la flexibilité de maintenir des ensembles de secrets basés sur les environnements de votre application.
Cependant, il y a aussi des mises en garde. Les gestionnaires de secrets sont à un stade très précoce de leur développement technologique. De plus, les gestionnaires de secrets sont des plateformes tierces qui sont soumises à leur propre série de problèmes de sécurité. Il est donc important d’évaluer et de sélectionner soigneusement le bon gestionnaire de secrets. En outre, si votre application, son équipe de développement ou le nombre de secrets de l’application n’est pas assez important, les gestionnaires de secrets peuvent être superflus pour vous.
Tableau de référence des variables d’environnement
Voici un aide-mémoire rapide qui vous permettra de vous familiariser rapidement avec les variables d’environnement et leur utilisation :
| Définition des variables d’environnement | Variables fournies aux processus par leurs processus appelants |
| Objectif |
|
| Types | Pour Windows uniquement :
|
| Exemples de cas d’utilisation populaires |
|
| Comment les implémenter dans votre application ? |
|
Résumé
Les variables d’environnement sont importantes pour isoler les données sensibles de votre application. Elles aident à sécuriser les secrets de votre application et vous permettent de passer facilement d’un ensemble de secrets à un autre en fonction de l’environnement de l’application. Cependant, leur gestion ajoute une tâche supplémentaire.
Il existe de multiples façons de sécuriser les variables d’environnement, comme nous l’avons vu plus haut. Explorez-les toutes et trouvez celles qui conviennent le mieux à votre projet et l’accélèrent.
