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


640

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

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

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


я на самом деле подобається, як конфігурація виконується в mean.js . в основному вони зберігають відповідну конфігурацію додатків у окремому вигляді модуля, заснованого на різних налаштуваннях у середовищі програми (для виробництва, розробки, тестування) та передачі конкретних деталей через змінні середовища додатків, як секрети тощо.
Hinrich

Відповіді:


765

Я використовую 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, для мого виробничого сервера додаються пульти.


32
що станеться, якщо у вас різні налаштування конфігурації для dev vs. prod?
chovy

4
Я не маю, але ось один спосіб це зробити .. для кожної env встановіть env ім'я у змінній ENV. Тоді в цьому файлі його просто JavaScript .. використовуйте регістр або оператор if для вибіркового завантаження відповідних змінних. Ви навіть можете зробити окремий підфільм конфігурації для кожної env, і в операторі if перезавантажте тут підфайл у var subconfig та експортуйте цей subconfig var у основний конфігурацію. js, так що ви можете бути творчими
noli

4
який процес.env? де він знаходиться? І як це встановити?
сердитий ківі

12
Я думав "ого .. я вже кілька годин дивлюсь на node.js, і моя програма вже працює .. btw, можливо, я поділюся цим випадковим бітом коду, з яким я придумав"
noli

3
Ви все ще не можете використовувати змінні середовища для зберігання цих пропущених слів? Хіба це не те, що для цього рядка: config.twitter.password = process.env.TWITTER_PASSWORD || 'пароль';
DMart

244

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

config.json:

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

app.js:

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

40
Не настільки вражений цією особливістю. Ви можете вимагати ("./ config.js") і отримуєте можливість додавати коментарі до конфігураційних файлів, які я вважаю дуже важливими, та інших дзвіночків. Якщо ви налаштовуєте лише властивості, і немає коду, ви нічого не втрачаєте, вимагаючи (config.js) з вами JSON з префіксом
export.config

3
@teknopaul Ви маєте рацію, але раніше великі дискусії про «правильність» / зручність використання немов проти розумних систем шаблонування, які мені сказали: (1) ти, як правило, хочеш декларативну / тупу мову для шаблонування / варіантів (2) погана ідея реконструювати "майже-PL", щоб просто зробити шаблонування (або конфігурацію) - краще повторно використовувати наявний реальний PL з відомими способами поведінки. поки що +1 для переробки JS для налаштування користувачів; -1 за неприйняття декларативного підходу. ми бачили деякі досить складні конфігураційні речі, зроблені декларативно; моя кишка говорить мені, що це шлях.
потік

1
Немає інтелігенції щодо об’єктів з файлів json у VScode (кінець 2017 року). Повністю працює інтелісенс для об'єктів з module.exports.
Ромен Вінсент

199

Набагато пізніше я знайшов досить хороший модуль 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 .


2
Можливо, тупе запитання, але я не бачив чіткого пояснення: Де я встановлюю змінні середовища вузла? Я вже використовую nconf, але незрозуміло, де я б встановив змінні середовища. Це в nginx / apache? Це ще один конфігураційний файл?
Цивільний

91
Я не думаю, що використовувати .json файл як конфігурацію - це гарна ідея, оскільки коментарі заборонені.
Франк Сю

11
Це виглядає чудово. Я думаю, ви здивуєте багато Unixheads, якщо файл конфігурації замінить параметри командного рядка та змінні середовища. Ми звикли до наступного порядку зростання пріоритетності: конфігураційні файли, змінні середовища, параметри командного рядка.
sheldonh

2
@sheldonh Зачекайте, поки ви дізнаєтесь, що булеві параметри завжди встановлені на argv, тому порушуючи пріоритет ...: /
Daniel C. Sobral

@ DanielC.Sobral Це справжній сором. О, і LTNS! :-)
sheldonh

94

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

Завантажте конфігурацію середовища у ./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

2
Я віддаю перевагу цьому. Як зазначають інші, JSON не є бажаною структурою зберігання, і цей шари з глобальними елементами прості та ефективні
Себастьян Дж.

Єдина причина, що я вважаю за краще це над nconf, це те, що він дозволяє формату .js для файлів config (dev, test та prod). що дозволяє нам документувати кожен варіант конфігурації, що в іншому випадку неможливо у форматі JSON.
Kunal Kapadia

BTW, NODE_ENVза замовчуванням "розвиток". Слід перевірити "виробництво".
Кевін Саттл

5
Я не перевіряю на розвиток. Я до цього дефолт. Не впевнений, чому я коли-небудь замовчував би виробництво.
chovy

39

Ви також можете поглянути на 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.


2
Або просто використовувати foreman run node xx.jsце автоматично буде прочитано і у вашому файлі .env.
Саймон

1
Чи використовував би я такий підхід і для виробництва?
Ламур

1
@lamar ні, ви встановлюєте їх у змінних env на фактичному сервері. Це було щоразу, коли ви розгортаєте їх там, але не у вихідному коді.
sidonaldson

@Lamar Так, ви можете насправді, як більш портативна альтернатива встановленню змінних env на сервері. Важливий момент - не включати .envфайл у процес управління версіями чи розгортання.
Josh Noe

31

Ви, хлопці, використовуєте 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 Усі кредити Еріку Елліоту


2
Чи можете ви пояснити, що таке "джерело"? Я отримуюsource : not found
JohnnyBizzle

@JohnnyBizzle source(або просто .) - це вбудована команда в оболонках Unix (Bash тощо) для читання та виконання команд із заданого файлу у поточній оболонці . Тобто команди не виконуються в підколонці. Ефект цього в цьому прикладі полягає в тому, що змінні середовища, визначені в prod.env, додаються до поточної оболонки і, отже, передаються будь-якому дочірньому процесу, породженому цією оболонкою. Здається, ви використовуєте Windows CMD. Дивіться це питання для більш детальної інформації.
Утку

Варто відзначити - 12 фактор додаток рекомендує НЕ створювати dev.envі prod.env, але мають один .envфайл на розгортанні.
Ірідайн

24

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

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


22

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

exports.my_password = 'value'

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

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

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

settings.my_password // 'value'

@backdesk, звичайно, ви можете створити секретну систему зберігання, яка зашифрувала б секрети та обмежила доступ за допомогою ip, деяких жетонів тощо. Але зрештою все приходить до простого читання деяких файлів з диска, будь то зашифровані чи ні.
Вануан

@backdesk З прикладом проблем немає. Це тільки те: приклад для пояснення чогось конкретного.
Еміліо Грисолія

14

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

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

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

  • 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 потрібно вміти відрізнятись на різних машинах.


13

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"
  }
});

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


12

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


9

Я буду створювати папку як конфігурацію імен файлу як 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');
    }
});

6

Просто використовуйте 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

4

Краще відокремити конфігурації '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;

також ви можете користувач module.exports = config;в кінці config/index.jsфайлу
mapmalith

3

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

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

  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

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


не дуже очевидно, що undefinedнасправді означає "необхідне" і nullозначає "необов'язкове". значить, жовтий контейнер для пластику, а синій - для брухту паперу? добре, але довелося прочитати посібник перед тим, як кинути цю підстилку.
потік

Вам не доведеться використовувати цю умову. Я вважаю це корисним і доручаю своїй команді використовувати його, але ви, очевидно, можете видалити цю функцію.
guy mograbi

3

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

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

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


3

Я знаю, що це дійсно старий пост. Але я хочу поділитися своїм модулем для налаштування змінних середовища, я думаю, що це дуже гнучко рішення. Ось модуль 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для отримання всіх змінних для вашого оточення.


2

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


ніякого способу повернутися до файлів win-ini ..., що з iniparserгордістю підкреслює той факт, що вони знають, як проаналізувати розділи в конфігурації ... в 2013 році ... якщо вам потрібно глибше вкладати, скажете ви [foo/bar]? [foo\bar]? bar.baz=42? bar/baz=42? bar\baz=42? bar:baz=42? як ти скажеш 42, це число? це може бути багатоцифровий текст! —витрата XML, метання YAML, метання WIN.INI, обняття JSON, турботи пішли.
течія



1

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

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

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гарантує, що ви навіть можете мати вкладені за замовчуванням.



0

Тут я спробував деякі запропоновані рішення, але не був задоволений ними, тому створив власний модуль. Це називається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


0

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

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


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

Якщо ви зможете прочитати його з якогось іншого стороннього місця та декодувати їх, а ваша служба використовувати ці найпотаємніші дані, хакер зможе зробити саме те, якщо вони отримають доступ до вашого комп'ютера. Це більше роботи (займає більше часу), але врешті-решт це не захистить вас. Якщо ваш сервер пронизаний, уявіть, що все, що ви маєте на ньому, зараз є загальнодоступним.
Alexis Wilke
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.