Vérifiez si mon instance node.js est en développement ou en production

Question

En ce moment, chaque fois que je veux déployer un serveur node.js sur mon serveur de production, je dois changer toutes les adresses IP/DNS/nom d'utilisateur/mot de passe pour mes diverses connexions à mes bases de données et API externes.

Ce processus est ennuyeux, y a-t-il un moyen de vérifier si l'instance node.js en cours d'exécution se trouve dans cloud9ide ou en réalité sur mon smartmachine de production joyent ?

Si je suis capable de déterminer (dans mon code en cours d'exécution) sur quel serveur mon instance node.js est en cours d'exécution, j'ajouterai une condition qui définira les valeurs sur prod ou dev.

Merci

Answer 1

Normalement, vous devriez exécuter une application node en production de cette manière:

NODE_ENV=production node app.js

Les applications avec Express, Socket.IO et autres utilisent process.env.NODE_ENV pour déterminer l'environnement.

En développement, vous pouvez omettre cela et simplement exécuter l'application normalement avec node app.js.

Vous pouvez détecter l'environnement dans votre code de cette manière:

var env = process.env.NODE_ENV || 'development';
loadConfigFile(env + '.json', doStuff);

Ressources:

Comment détecter l'environnement dans une application express.js?

Answer 2

Je pense que le moyen le plus simple de définir l'environnement est de passer des arguments en ligne de commande à votre application.

node ./server.js dev

Dans votre script, vous devez gérer cet argument et définir la configuration dont vous avez besoin pour cela.

var env = process.argv[2] || 'dev';
switch (env) {
    case 'dev':
        // Configurer la configuration de développement
        break;
    case 'prod':
        // Configurer la configuration de production
        break;
}

Aussi, j'ai créé un module qui rend le processus de configuration un peu plus facile. Peut-être que cela vous aidera.

Answer 3

Pour cela, vous pouvez simplement le vérifier à l'aide de variables d'environnement et vous pouvez effectuer des actions.

if (process.env.NODE_ENV === "production") {
  //faire quelque chose en production
}

if (process.env.NODE_ENV == "development") {
   //faire quelque chose en développement
}

Answer 4

En fait, je ne recommanderais pas de stocker des valeurs de configuration comme les informations de connexion à la base de données, les mots de passe, les jetons d'accès, etc. à l'intérieur du code de l'application pour les raisons suivantes :

1. Le fait de coder en dur ces valeurs rend difficile leur modification ultérieure. Vous devrez publier une nouvelle version de l'application pour modifier ces valeurs.

2. Il s'agit d'une violation sérieuse de la sécurité, car les données de configuration de qualité de production et les mots de passe ne devraient pas être stockés dans le code. Il est très facile de divulguer ces données sensibles.

La meilleure approche serait d'externaliser ces données et de les passer à votre application pendant l'exécution. Cela se fait généralement au moyen de variables d'environnement. Vous devez simplement définir une variable d'environnement unique pour chaque donnée qui doit être modifiable entre différents environnements.

Par exemple : DB_HOST, DB_USER, DB_PASSWORD. Ensuite, vous pourriez passer ces valeurs à votre application en production de cette manière :

$ NODE_ENV=production DB_HOST=1.2.3.4 DB_USER=someusername DB_PASSWORD=somerandompassword /bin/node app.js

En réalité, ces valeurs pourraient être chiffrées et ajoutées au code, puis décryptées lors du déploiement. Cependant, assurez-vous que la clé de décryptage est stockée de manière sécurisée dans le système de déploiement ou fournie de manière interactive par l'ingénieur de déploiement. Shippable permet de le faire directement.

Environnement de développement, c'est plus simple, car vous pouvez utiliser le très pratique dotenv module. Il vous suffit de créer un fichier .env dans le répertoire racine de votre projet et d'y ajouter toutes les variables :

DB_HOST=1.2.3.4
DB_USER=someusername
DB_PASSWORD=somerandompassword

Mais, veillez à l'exclure de votre VCS, car chaque développeur voudra probablement avoir sa propre configuration. Vous pouvez créer un fichier .env.dist pour contenir la configuration par défaut, qui pourrait ensuite être utilisée comme modèle : cp .env.dist .env.