Node.js: как настроить разные переменные для prod и staging

Question

Я использую Express, и мне нужно использовать разные учетные данные для каждого сервера (подготовка и производство).

Я мог бы установить переменные в файле server.coffee, но тогда мне нужно было бы получить доступ к этим переменным в разных файлах.

server.coffee:

app.configure 'production', () ->
 app.use express.errorHandler()

Какое решение?Установить переменные и затем экспортировать их?

Answer 1

. / Config.js

var development = {
  appAddress : '127.0.0.1:3000',
  socketPort : 4000,
  socketHost : '127.0.0.1',
  env : global.process.env.NODE_ENV || 'development'
};

var production = {
  appAddress : 'someDomain.com',
  socketPort : 4000,
  socketHost : '8.8.8.8',
  env : global.process.env.NODE_ENV || 'production'
};

exports.Config = global.process.env.NODE_ENV === 'production' ? production : development;

. / App.js

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

if (cfg.something) { // switch on environment
  // your logic
}

Answer 2

Это может быть хорошим местом для использования npm-config .

При запуске сценариев (см. Npm-scripts (7)) ключи package.json "config"перезаписываются в среде, если есть параметр конфигурации <name>[@<version>]:<key>

Я бы не использовал их для каждого типа параметра конфигурации переменной, но я думаю, что это хорошее решение для простых случаев, таких как URL ипорты потому что:

1. Вы помещаете их непосредственно в package.json.
2. Кроме того, вы можете указать их в командной строке или в качестве переменных ENV.
3. Все, что угоднозапуск через npm может ссылаться на них (например, скрипты).
4. Вы можете установить их для каждого пользователя с помощью `npm config set foo: порт 80

Единственное предостережение в том, чтоПараметр config в вашем package.json автоматически экспортируется в среду только тогда, когда вы запускаете свой код через npm.Итак, если вы просто запустите его с узлом, например, node ./myapp.js, то вы не можете ожидать, что process.env.npm_package_config_foo будет содержать ваше значение.Тем не менее, вы всегда можете var pkg = require('./package.json'); и получить доступ к значениям в pkg.config.

Поскольку это может быть неочевидным, я бы также добавил, что переменные окружения npm_package_config не всплывают в приложениях, которыезависит от вашего пакета npm.Итак, если ваш зависимый пакет ссылается на process.env.npm_package_config_foo, то зависимый пакет должен определить это в своем собственном package.json.Я предполагаю, что, поскольку это npm_package_config, не имеет смысла толкать их все вверх по дереву.

Итак, как бы я использовал одну конфигурационную переменную npm, чтобы она работала по всему дереву?, как в базовом пакете, так и в пакетах, которые от него зависят?Это немного сбивает с толку, и мне пришлось разобраться с этим методом проб и ошибок.

Допустим, у вас есть пакет разъем и пакет клиент . клиент зависит от соединителя , и вы хотите указать параметр конфигурации для соединителя , который можно использовать или перезаписать в клиенте .Если вы используете process.env.npm_package_config.port в вашем соединителе модуле, то, когда он зависит от модуля client , эта переменная не будет экспортирована, и она будет иметь неопределенное значение.

Однако, если вы вместо этого используете process.env.npm_config_connector_port (обратите внимание, что первый начинается с npm_package_config , а другой с npm_config_packagename ), тогда вы можете по крайней мере установить это в своем.npmrc использует npm config set connector:port 80 и он будет "пространством имен" как process.env.npm__config_connector_port везде, где вы запускаете npm, включая сценарии, которые вы запускаете в клиенте , которые зависят от соединителя , и вывсегда сможете перезаписать его в командной строке, в вашем ENV или в .npmrc.Вам просто нужно помнить, что, как и для любой переменной среды, она не всегда может быть установлена.Итак, я бы использовал оператор по умолчанию с process.env.npm_config_connector_port в качестве первого (предпочтительного) значения:

var port = process.env.npm_config_connector_port || sane_default

Здесь sane_default может быть заполнено из одногоиз других рекомендуемых методов.Лично мне нравится хранить данные конфигурации, подобные этим, в файлах JSON как минимум, и package.json кажется лучшим файлом JSON для их размещения. Сохраняйте их в данных вместо кода, и тогда вы сможете легкоиспользуйте статический встроенный JSON, генерируйте их динамически или извлекайте из файловой системы, URL-адресов или баз данных.

Answer 3

Я загрузил реализацию в https://github.com/qiangyu/nodejsconfig. Я верю, что она удовлетворит ваши потребности.По сути, вам нужно предоставить только один файл конфигурации:

dev.appAddress = '127.0.0.1:3000';
prod.appAddress = 'someDomain.com';

Затем вы используете следующий код для чтения appAddress в среде prod:

var xnconfig = require('nodejsconfig');
var fs = require('fs');

var data = fs.readFileSync(__dirname+"/config.properties", "UTF8");

// assume we will be using environment "prod"
var config = xnconfig.parse("prod", data);

// the output will be someDomain.com
console.log(config.getConfig("appAddress"));

Answer 4

У меня есть приложение, которое использует три различных метода объявления переменных конфигурации (uris, API-ключи, учетные данные и т. Д.) В зависимости от среды (production = переменные среды; staging = аргументы командной строки; local = файлы конфигурации.) Я написал небольшой модуль «config» для объединения всех этих опций в один объект, который я могу использовать в своем приложении, и загрузил его в виде сущности: https://gist.github.com/1616583

Возможно, это не лучшая реализация, но пока она работает довольно хорошо:).

Answer 5

Если вам не нужна логика для определения того, какую конфигурацию использовать в каждом файле (что выглядит довольно уродливо), вам придется куда-то ее экспортировать.

Что я бы предложил:config.json файл, содержащий различные конфиги.Основной файл требует этого и делает что-то вроде config.default = config.(condition ? 'production':'development').Во всех других файлах теперь вы можете просто сделать require('./config').default.