Як зберігати налаштування / файли налаштування Node.js?

Я працював над декількома додатками Node, і шукав хороший зразок зберігання налаштувань, пов’язаних з розгортанням. У світі Джанго (звідки я родом) звичайною практикою було б мати settings.pyфайл, що містить стандартні параметри (часовий пояс тощо), а потім параметри local_settings.pyдля розгортання, тобто. з якою базою даних поговорити, з якою роздрібною пам'яткою, з адресою електронної пошти для адміністраторів тощо.

Я шукав подібні зразки для Node. Просто конфігураційний файл був би непоганим, тому його не потрібно заклинювати у всьому іншому app.js, але я вважаю важливим мати спосіб мати конфігурацію для сервера у файлі, який не знаходиться в контролі джерела. Це ж додаток цілком може бути розгорнутий на різних серверах із надзвичайно різними налаштуваннями, і мати справу з конфліктами злиття та всім, що не є моєю ідеєю розваги.

Так чи є для цього якийсь фреймворк / інструмент, або кожен просто зламає щось разом?

Я використовую package.jsonдля своїх пакетів і config.jsдля моєї конфігурації, яка виглядає так:

var config = {};

config.twitter = {};
config.redis = {};
config.web = {};

config.default_stuff =  ['red','green','blue','apple','yellow','orange','politics'];
config.twitter.user_name = process.env.TWITTER_USER || 'username';
config.twitter.password=  process.env.TWITTER_PASSWORD || 'password';
config.redis.uri = process.env.DUOSTACK_DB_REDIS;
config.redis.host = 'hostname';
config.redis.port = 6379;
config.web.port = process.env.WEB_PORT || 9980;

module.exports = config;

Я завантажую конфігурацію зі свого проекту:

var config = require('./config');

а потім я можу отримати доступ до моїх речей з config.db_host, config.db_portі т. д. ... Це дозволяє мені використовувати твердо кодовані параметри, або параметри, що зберігаються в змінних навколишнього середовища, якщо я не хочу зберігати паролі в керуванні джерелами.

Я також генерую a package.jsonі вставляю розділ залежностей:

"dependencies": {
  "cradle": "0.5.5",
  "jade": "0.10.4",
  "redis": "0.5.11",
  "socket.io": "0.6.16",
  "twitter-node": "0.0.2",
  "express": "2.2.0"
}

Коли я клоную проект на свою локальну машину, я біжу npm installвстановлювати пакети. Більше інформації про це тут .

Проект зберігається в GitHub, для мого виробничого сервера додаються пульти.

Ви можете вимагати файлів JSON від Node v0.5.x ( посилаючись на цю відповідь )

config.json:

{
    "username" : "root",
    "password" : "foot"
}

app.js:

var config = require('./config.json');
log_in(config.username, config.password);

Набагато пізніше я знайшов досить хороший модуль Node.js для управління конфігурацією: nconf .

Простий приклад:

var nconf = require('nconf');

// First consider commandline arguments and environment variables, respectively.
nconf.argv().env();

// Then load configuration from a designated file.
nconf.file({ file: 'config.json' });

// Provide default values for settings not provided above.
nconf.defaults({
    'http': {
        'port': 1337
    }
});

// Once this is in place, you can just use nconf.get to get your settings.
// So this would configure `myApp` to listen on port 1337 if the port
// has not been overridden by any of the three configuration inputs
// mentioned above.
myApp.listen(nconf.get('http:port'));

Він також підтримує збереження налаштувань у Redis , написання конфігураційних файлів та має досить надійний API, а також підтримується одним із найбільш шанованих магазинів Node.js, Nodejitsu , як частина рамкової ініціативи Flatiron , так що це повинно бути досить надійний.

Перевірте nconf в Github .

Моє рішення досить просте:

Завантажте конфігурацію середовища у ./config/index.js

var env = process.env.NODE_ENV || 'development'
  , cfg = require('./config.'+env);

module.exports = cfg;

Визначте деякі параметри за замовчуванням у ./config/config.global.js

var config = module.exports = {};

config.env = 'development';
config.hostname = 'dev.example.com';

//mongo database
config.mongo = {};
config.mongo.uri = process.env.MONGO_URI || 'localhost';
config.mongo.db = 'example_dev';

Замініть значення за замовчуванням у ./config/config.test.js

var config = require('./config.global');

config.env = 'test';
config.hostname = 'test.example';
config.mongo.db = 'example_test';

module.exports = config;

Використовуючи його в ./models/user.js:

var mongoose = require('mongoose')
, cfg = require('../config')
, db = mongoose.createConnection(cfg.mongo.uri, cfg.mongo.db);

Запуск програми в тестовому середовищі:

NODE_ENV=test node ./app.js

Ви також можете поглянути на dotenv, який відповідає принципам дванадцятифакторного додатка .

Я використовував node-config, але створив dotenv з цієї причини. Це повністю надихнуло бібліотеку дотенів рубінів.

Використання досить просто:

var dotenv = require('dotenv');
dotenv.load();

Тоді ви просто створіть .env файл і помістіть свої настройки туди так:

S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE
OTHER_SECRET_STUFF=my_cats_middle_name

Це dotenv для nodejs.

Ви, хлопці, використовуєте npm для запуску сценаріїв (env тощо)?

Якщо ви використовуєте .envфайли, ви можете включити їх у свій package.json і використовувати npm для їх джерела / запуску.

Приклад:

{
  "name": "server",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node test.js",
    "start-dev": "source dev.env; node test.js",
    "start-prod": "source prod.env; node test.js"
  },
  "dependencies": {
    "mysql": "*"
  }
}

потім запустіть сценарії npm:

$ npm start-dev

Тут описано https://gist.github.com/ericelliott/4152984 Усі кредити Еріку Елліоту

Ви також можете поглянути node-config, який завантажує файл конфігурації залежно від $ HOST та $ NODE_ENV змінної (трохи схоже на RoR): документація .

Це може бути дуже корисно для різних налаштувань розгортання (development , testабо production).

Просто зробити простий settings.jsз exports:

exports.my_password = 'value'

Потім у своєму сценарії зробіть require:

var settings = require('./settings.js');

Усі ваші налаштування тепер будуть доступні за допомогою settingsзмінної:

settings.my_password // 'value'

Я збираюся кинути тут шапку на ринг, тому що жодна з цих відповідей не стосується усіх найважливіших компонентів, які потребують будь-яка система. Міркування:

• Публічна конфігурація (що може бути видно в інтерфейсі) і приватна конфігурація (хлопець мограбі отримав це право). І забезпечення цього зберігається окремо.
• Секрети, як ключі
• Значення за замовчуванням та переорієнтація на середовище
• Фронтальні пучки

Ось як я мою конфігурацію:

• config.default.private.js - У контролі версій - це параметри конфігурації за замовчуванням, які може бачити лише ваш бекенд.
• config.default.public.js- У контролі версій - це параметри конфігурації за замовчуванням, які можна побачити за допомогою бекенда та фронтенда
• config.dev.private.js - Якщо вам потрібні різні приватні настройки за замовчуванням.
• config.dev.public.js - Якщо вам потрібні різні загальнодоступні параметри для розробника.
• config.private.js - Не в контролі версій, це параметри, що змінюють особливості середовища config.default.private.js
• config.public.js - Не в контролі версій, це параметри, що змінюють особливості середовища config.default.public.js
• keys/- Папка, де кожен файл зберігає різний секрет якогось роду. Це також не перебуває під контролем версій (ключі ніколи не повинні знаходитись під контролем версій).

Я використовую звичайні старі файли javascript для конфігурації, тому я маю повну потужність язика javascript (включаючи коментарі та можливість робити такі дії, як завантаження файлу конфігурації за замовчуванням у специфічний для оточуючого середовища файл, щоб потім їх можна було замінити). Якщо ви хочете використовувати змінні середовища, ви можете завантажити їх у ці файли конфігурацій (тому я рекомендую не використовувати env vars з тієї ж причини, що я не рекомендую використовувати файли json - у вас немає сили мови програмування для побудови ваш конфігурація).

Причина, що кожна клавіша знаходиться в окремому файлі, полягає у використанні інсталятора. Це дозволяє мати інсталятор, який створює ключі на машині та зберігає їх у папці ключів. Без цього інсталятор може вийти з ладу під час завантаження конфігураційного файла, який не може отримати доступ до ваших ключів. Таким чином, ви можете перейти до каталогу та завантажити будь-які ключові файли, які знаходяться у цій папці, не турбуючись про те, що існує, а що ні в будь-якій версії коду.

Оскільки у вас, ймовірно, є ключі, завантажені в приватній конфігурації, ви точно не хочете завантажувати свою приватну конфігурацію в будь-який код фронтенда. Хоча напевно суворіше ідеально повністю відокремити вашу кодову базу даних від вашого бекенда, багато разів, що PITA є достатньо великим бар'єром, щоб люди не могли це робити, таким чином, приватний та публічний конфігурації. Але я маю дві речі, щоб запобігти завантаженню приватного конфігурації у фронтенді:

1. У мене є тестовий блок, який гарантує, що мої пакети фронтальних даних не містять жодного із секретних ключів, які я маю в приватній конфігурації.
2. Я маю код фронтенду в іншій папці, ніж мій резервний код, і у мене є два різні файли з назвою "config.js" - по одному для кожного кінця. Для бекенда config.js завантажує приватну конфігурацію, для фронтену - загальнодоступну конфігурацію. Тоді ви завжди просто вимагаєте ('config') і не турбуєтесь, звідки це походить.

І останнє: ваша конфігурація повинна завантажуватися в браузер через повністю окремий файл, ніж будь-який інший код вашого фронту. Якщо ви поєднуєте свій код фронтенду, публічна конфігурація повинна будуватися як повністю окремий пакет. В іншому випадку ваша конфігурація насправді вже не є конфігурацією - її лише частиною вашого коду. Config потрібно вміти відрізнятись на різних машинах.

Convict - це ще один варіант, який додає схему перевірки. Як і nconf, він підтримує налаштування завантаження з будь-якої комбінації змінних середовища, аргументів, файлів та об’єктів json.

Приклад з README:

var convict = require('convict');
var conf = convict({
  env: {
    doc: "The applicaton environment.",
    format: ["production", "development", "test"],
    default: "development",
    env: "NODE_ENV"
  },
  ip: {
    doc: "The IP address to bind.",
    format: "ipaddress",
    default: "127.0.0.1",
    env: "IP_ADDRESS",
  },
  port: {
    doc: "The port to bind.",
    format: "port",
    default: 0,
    env: "PORT"
  }
});

Стаття про початок роботи: Приборкання конфігурацій із засудженим у вузлі

Konfig можна використовувати для конкретних конфігураційних файлів для оточення. Він автоматично завантажує файли конфігурації json або yaml, має значення за замовчуванням та функції динамічної конфігурації.

Приклад від Konfig repo:

File: config/app.json
----------------------------
{
    "default": {
        "port": 3000,
        "cache_assets": true,
        "secret_key": "7EHDWHD9W9UW9FBFB949394BWYFG8WE78F"
    },

    "development": {
        "cache_assets": false
    },

    "test": {
        "port": 3001
    },

    "staging": {
        "port": #{process.env.PORT},
        "secret_key": "3F8RRJR30UHERGUH8UERHGIUERHG3987GH8"
    },

    "production": {
        "port": #{process.env.PORT},
        "secret_key": "3F8RRJR30UHERGUH8UERHGIUERHG3987GH8"
    }
}

У розробці:

> config.app.port
3000

При виробництві, припустимо, ми починаємо застосування з $ NODE_ENV=production PORT=4567 node app.js

> config.app.port
4567

Детальніше: https://github.com/vngrs/konfig

Я буду створювати папку як конфігурацію імен файлу як config.jsі пізніше, буду використовувати цей файл там, де потрібно, як зазначено нижче

Приклад config.js

module.exports = {
    proxyURL: 'http://url:port',
    TWITTER: {
        consumerkey: 'yourconsumerkey',
        consumerSecrete: 'yourconsumersecrete'
    },
    GOOGLE: {
        consumerkey: 'yourconsumerkey',
        consumerSecrete: 'yourconsumersecrete'
    },
    FACEBOOK: {
        consumerkey: 'yourconsumerkey',
        consumerSecrete: 'yourconsumersecrete'
    }
}

Тоді, якщо я хочу десь використовувати цей конфігураційний файл

Я спочатку імпортую як нижче

var config = require('./config');

і я можу отримати доступ до значень, наведених нижче

const oauth = OAuth({
    consumer: {
        key: config.TWITTER.consumerkey,
        secret: config.TWITTER.consumerSecrete
    },
    signature_method: 'HMAC-SHA1',
    hash_function(base_string, key) {
        return crypto.createHmac('sha1', key).update(base_string).digest('base64');
    }
});

Просто використовуйте npmмодуль config(понад 300000 завантажень)

https://www.npmjs.com/package/config

Node-config організовує ієрархічні конфігурації для ваших розгортань додатків.

Це дозволяє визначити набір параметрів за замовчуванням та розширити їх для різних середовищ розгортання (розробка, qa, постановка, виробництво тощо).

$ npm install config
$ mkdir config
$ vi config/default.json


{
      // Customer module configs
      "Customer": {
        "dbConfig": {
          "host": "localhost",
          "port": 5984,
          "dbName": "customers"
        },
        "credit": {
          "initialLimit": 100,
          // Set low for development
          "initialDays": 1
        }
      }
}



$ vi config/production.json

{
  "Customer": {
    "dbConfig": {
      "host": "prod-db-server"
    },
    "credit": {
      "initialDays": 30
    }
  }
}



$ vi index.js

var config = require('config');
//...
var dbConfig = config.get('Customer.dbConfig');
db.connect(dbConfig, ...);

if (config.has('optionalFeature.detail')) {
  var detail = config.get('optionalFeature.detail');
  //...
}


$ export NODE_ENV=production
$ node index.js

Краще відокремити конфігурації 'development' та 'production' .

Я використовую наступний спосіб: ось мій файл config / index.js :

const config = {
    dev : {
        ip_address : '0.0.0.0',
        port : 8080,
        mongo :{
            url : "mongodb://localhost:27017/story_box_dev",
            options : ""
        }
    },
    prod : {
        ip_address : '0.0.0.0',
        port : 3000,
        mongo :{
            url : "mongodb://localhost:27017/story_box_prod",
            options : ""
        }
    }
} 

Для конфігурації потрібно використовувати наступне:

const config = require('../config')[process.env.NODE_ENV];

Чим ви можете скористатись своїм об’єктом config:

const ip_address = config.ip_address;
const port = config.port;

Я трохи запізнююсь у грі, але я не міг знайти те, що мені потрібно - або деінде - тому щось написав сам.

Мої вимоги до механізму налаштування такі:

1. Підтримка фронтального. Який сенс, якщо передній кінець не може використовувати конфігурацію?
2. Підтримка settings-overrides.js- виглядає так само, але дозволяє змінити конфігурацію на settings.js. Ідея тут полягає в тому, щоб легко змінити конфігурацію, не змінюючи код. Я вважаю це корисним для saas.

Незважаючи на те, що я менше дбаю про підтримку середовища, - це пояснить, як легко додати його до свого рішення

var publicConfiguration = {
    "title" : "Hello World"
    "demoAuthToken" : undefined, 
    "demoUserId" : undefined, 
    "errorEmail" : null // if null we will not send emails on errors. 

};

var privateConfiguration = {
    "port":9040,
    "adminAuthToken":undefined,
    "adminUserId":undefined
}

var meConf = null;
try{
    meConf = require("../conf/dev/meConf");
}catch( e ) { console.log("meConf does not exist. ignoring.. ")}




var publicConfigurationInitialized = false;
var privateConfigurationInitialized = false;

function getPublicConfiguration(){
    if (!publicConfigurationInitialized) {
        publicConfigurationInitialized = true;
        if (meConf != null) {
            for (var i in publicConfiguration) {
                if (meConf.hasOwnProperty(i)) {
                    publicConfiguration[i] = meConf[i];
                }
            }
        }
    }
    return publicConfiguration;
}


function getPrivateConfiguration(){
    if ( !privateConfigurationInitialized ) {
        privateConfigurationInitialized = true;

        var pubConf = getPublicConfiguration();

        if ( pubConf != null ){
            for ( var j in pubConf ){
                privateConfiguration[j] = pubConf[j];
            }
        }
        if ( meConf != null ){
              for ( var i in meConf ){
                  privateConfiguration[i] = meConf[i];
              }
        }
    }
    return privateConfiguration;

}


exports.sendPublicConfiguration = function( req, res ){
    var name = req.param("name") || "conf";

    res.send( "window." + name + " = " + JSON.stringify(getPublicConfiguration()) + ";");
};


var prConf = getPrivateConfiguration();
if ( prConf != null ){
    for ( var i in prConf ){
        if ( prConf[i] === undefined ){

            throw new Error("undefined configuration [" + i + "]");
        }
        exports[i] = prConf[i];
    }
}


return exports;

Пояснення

• undefined означає, що ця властивість потрібна
• null означає, що це необов’язково
• meConf- наразі код націлений на файл під app. meConf- це файли переопределення, на які орієнтовано conf/dev- яке ігнорується моїми документами.
• publicConfiguration - буде видно спереду та ззаду.
• privateConfiguration - буде видно лише з бек-енду.

• sendPublicConfiguration- маршрут, який відкриє загальнодоступну конфігурацію та призначить її глобальній змінній. Наприклад, наведений нижче код відкриє загальнодоступну конфігурацію як глобальну змінну myConf в передній частині. За замовчуванням він використовуватиме глобальну назву змінної conf.

  app.get ("/ backend / conf", вимагаю ("conf"). sendPublicConfiguration);

Логіка зміни

• privateConfiguration об'єднується з publicConfiguration, а потім meConf.
• publicConfiguration перевіряє кожен ключ, якщо він має переопределення, і використовує цей перезапис. Таким чином ми нічого не піддаємо приватному.

Додавання підтримки навколишнього середовища

Хоча я не вважаю корисною "підтримку навколишнього середовища", можливо, хтось зробить це.

Щоб додати підтримку навколишнього середовища, вам потрібно змінити оператор meConf потрібно на щось подібне (псевдокод)

if (середовище == "виробництво") {meConf = вимагати ("../ conf / dev / meConf"). виробництво; }

if (середовище == "розвиток") {meConf = вимагати ("../ conf / dev / meConf"). razvoj; }

Так само ви можете мати файл у середовищі

 meConf.development.js
 meConf.production.js

і імпортувати правильний. Решта логіки залишається такою ж.

альт-приклад, який я щойно використав, тому що я хотів більшої гнучкості, ніж типовий .json-файл, але не хотів, щоб він був абстрагований у бібліотеку, яка вимагала б залежності, щось подібне. В основному, експортується функція негайно, яка повертає об'єкт із значеннями, які я хотів встановити. Дає велику гнучкість.

     module.exports = function(){
       switch(node_env){
         case 'dev':
           return
           { var1 = 'development'};
         }
    }();

Тут є набагато краще пояснення з повним прикладом. Використання налаштування файлів у Node.js

Я знаю, що це дійсно старий пост. Але я хочу поділитися своїм модулем для налаштування змінних середовища, я думаю, що це дуже гнучко рішення. Ось модуль json-конфігуратор

var configJson = {
  'baseUrl': 'http://test.com',
  '$prod_baseUrl': 'https://prod.com',
  'endpoints': {
    'users': '<%= baseUrl %>/users',
    'accounts': '<%= baseUrl %>/accounts'
    },
  foo: 'bar',
  foobar: 'foobar',
  $prod_foo: 'foo in prod',
  $test_foo: 'foo in test',
  deep:{
    veryDeep: {
      publicKey: 'abc',
      secret: 'secret',
      $prod_secret: 'super secret'
    }
  }
};

var config = require('json-configurator')(configJson, 'prod');

console.log(config.deep.veryDeep.secret) 
// super secret 

console.log(config.endpoints.users)
// https://prod.com/users 

Потім ви можете використовувати process.env.NODE_ENVдля отримання всіх змінних для вашого оточення.

Крім модуля nconf, згаданого у цій відповіді , та node-config, згаданого у цій відповіді , є також node-iniparser та IniReader , які, здається, є більш простими.

Нещодавно я випустив невеликий модуль для завантаження будь-якого типу конфігураційних файлів. Це досить прямо, ви можете перевірити це на https://github.com/flesler/config-node

Ви можете використовувати pconf: https://www.npmjs.com/package/pconf

Приклад:

var Config = require("pconf");
var testConfig = new Config("testConfig");
testConfig.onload = function(){

  testConfig.setValue("test", 1);
  testConfig.getValue("test");
  //testConfig.saveConfig(); Not needed

}

Ось акуратний підхід, натхненний цією статтею . Для цього не потрібні додаткові пакети, крім повсюдного пакету лодашів . Крім того, вона дозволяє керувати вкладеними типовими настройками за допомогою перезаписів, що стосуються середовища.

Спочатку створіть конфігураційну папку в кореневому шляху пакета, який виглядає приблизно так

package
  |_config
      |_ index.js
      |_ defaults.json
      |_ development.json
      |_ test.json
      |_ production.json

ось файл index.js

const _ = require("lodash");
const defaults = require("./defaults.json");
const envConf = require("./" + (process.env.NODE_ENV || "development") + ".json" );
module.exports = _.defaultsDeep(envConf, defaults);

Тепер давайте припустимо, що у нас є такий тип defaults.json

{
  "confKey1": "value1",
  "confKey2": {
    "confKey3": "value3",
    "confKey4": "value4"
  }
}

і development.json так

{
  "confKey2": {
    "confKey3": "value10",
  }
}

якщо ви зробите config = require('./config')тут, то отримаєте

{
  "confKey1": "value1",
  "confKey2": {
    "confKey3": "value10",
    "confKey4": "value4"
  }
}

Зауважте, що ви отримуєте всі значення за замовчуванням, крім тих, що визначені у файлах, що стосуються оточення. Таким чином, ви можете керувати ієрархією конфігурацій. Використання defaultsDeepгарантує, що ви навіть можете мати вкладені за замовчуванням.

Для тих, хто відвідує цю стару нитку, ось пакет, який я вважаю гарним.

https://www.npmjs.org/package/config

Тут я спробував деякі запропоновані рішення, але не був задоволений ними, тому створив власний модуль. Це називаєтьсяmikro-config і головна відмінність полягає в тому, що він шанує умову щодо конфігурації, тому ви можете просто вимагати модуль і почати його використовувати.

Ви зберігаєте конфігурацію в звичайних js або файлах json з /configпапки. Спочатку він завантажує default.jsфайл, потім всі інші файли з /configкаталогу, потім завантажує конфігурацію середовища, залежно від $NODE_ENVзмінної.

Це також дозволяє змінити цю конфігурацію для місцевого розвитку з local.jsабо специфічним для оточення /config/env/$NODE_ENV.local.js.

Ви можете подивитися тут:

https://www.npmjs.com/package/mikro-config

https://github.com/B4nan/mikro-config

Довгий час я використовував тут підхід, згаданий у рішенні. Однак існує стурбованість щодо безпеки таємниць у чіткому тексті. Ви можете використовувати інший пакет зверхуconfig щоб забезпечити догляд за бітами безпеки.

Перевірте це: https://www.attosol.com/secure-application-secrets-using-masterkey-in-azure-key-vault/