Lorsque vous exécutez une application Express en production sur votre ordinateur local, comment gérer la configuration des variables d'environnement?
J'utilise le package config . En développement, j'utilise ce fichier de configuration - development.json:
{
"mongoURI": "db_uri"
"apiKey": "api_key"
}
En production, si je comprends bien, on n'est pas censé stocker de tels données sensibles dans un fichier. Si je comprends bien, la raison en est que si un tel fichier était archivé dans le contrôle de version, tout le monde pourrait accéder aux informations sensibles qu'il contient (s'il y a d'autres raisons, veuillez préciser). Donc en production, mon fichier de configuration ressemble à ceci - production.json:
{
"mongoURI": "",
"apiKey": ""
}
De plus, j'utilise le fichier custom-environment -variables.json pour mapper les variables d'environnement aux valeurs de configuration. Ces variables d'environnement peuvent ensuite être définies de manière pratique sur le serveur de production, en utilisant par ex. le tableau de bord Heroku, qui leur permet d'être utilisés par l'application Express.
{
"mongoURI": "myMongoConnectionStringWithUsernameAndPassword",
"apiKey": "mySuperSecretSuperSecret"
}
Cependant, sur ma machine locale, je ne connais pas de moyen pratique de configurer et de mettre à jour facilement ces variables d'environnement.
J'ai pensé à les configurer via le script de démarrage qui exécute mon application en production dans package.json , mais ensuite je les aurais à nouveau dans un fichier, qui serait le même problème que de les stocker dans production.json comme expliqué ci-dessus.
Comment cela se fait-il en pratique? Sur ma machine locale, dois-je définir manuellement toutes les variables d'environnement sur le terminal chaque fois que je souhaite exécuter mon application en production? Y a-t-il un meilleur moyen?
Mise à jour: Il y a la suggestion de gitignore le fichier de configuration de production. Mais alors, comment les autres membres de l'équipe exécutent-ils l'application sur leurs machines, s'ils ne disposent pas du fichier de configuration? C'est ce que je ne comprends pas, il semble que l'on ne soit pas censé stocker ces valeurs de configuration dans un fichier ou sur GitHub, mais elles doivent être partagées entre les développeurs pour exécuter l'application? Comment les équipes font-elles cela en pratique?
4 Réponses :
Vous pouvez utiliser dotenv pour ce faire!
Pourriez-vous expliquer comment le package dotenv peut être utilisé pour résoudre le problème spécifique abordé dans la question?
Cette question semble spécifique au package config .
Dans ce contexte, on a pensé que chiffrer les secrets est une bonne idée:
Si vous n'utilisiez pas config , l'utilisation de variables d'environnement est un modèle très courant pour stocker des données sensibles:
https://nodejs.dev/how-to-read -environment-variables-from-nodejs
Dernier doute: en cours de production sur votre machine locale? Cela ne semble pas du tout être quelque chose que vous voudriez faire. Vous pourriez apporter des modifications à un magasin de données de production.
Pour le doute: Oui, car certaines parties de l'application utilisent un code différent pour le développement et la production et je veux être en mesure de m'assurer que la version de production fonctionne avant de la déployer sur le serveur de production réel.
Node.js vous propose de configurer des variables d'environnement via CLI,
La propriété process.env renvoie un objet contenant l'environnement utilisateur
afin que vous puissiez définir votre configuration avant la commande de démarrage comme ceci "mongoURI = xxxx npm start" et c'est le moyen facile,
De cette façon, vous devrez taper manuellement toutes les variables d'environnement chaque fois que vous souhaitez lancer votre application. C'est ce que j'essaie d'éviter.
oui bien sûr que vous pouvez éviter de taper manuellement en exportant un fichier pour les variables env, vous pouvez le supprimer
J'espère que le package condamné npm résout votre problème indiqué ici. Puisqu'il permet de définir des valeurs par défaut pour les propriétés de configuration dans un fichier et que la même chose peut être remplacée par des variables d'environnement sur un environnement supérieur. La validation peut être appliquée lors de la configuration pour éviter une erreur humaine.
De plus, la définition d'une propriété comme type sensible fait que la valeur sensible n'est pas imprimée dans le terminal ou les fichiers journaux.
Vous utiliseriez un fichier .env et le package dotenv dans la pratique
Comment cela fonctionnerait-il lorsqu'il est combiné avec le package
config? De plus, ne serais-je pas encore en train de stocker les valeurs dans un fichier avec le packagedotenv(juste un fichier différent)?Oui, mais vous ignorez ce fichier. Vous écririez
{"mongoURI": "MONGO_URI"}au lieu de{"mongoURI": "actual.database.url"}dans votre custom-environment-variables.jsonDans ce cas, il est également important que dotenv soit importé dans l'application avant la configuration.
Mais si je gitignore le fichier, comment les autres membres de l'équipe peuvent-ils exécuter l'application sur leurs machines? Ils n'auront pas les vars env? C'est ce que je ne comprends pas dans tout ça. Comment les gens font-ils cela dans la pratique? Vais-je ensuite documenter les variables d'environnement ailleurs?