Я работал над несколькими приложениями Node и искал хороший шаблон хранения настроек, связанных с развертыванием. В мире Django (откуда я родом) обычной практикой было бы иметь settings.py
файл, содержащий стандартные настройки (часовой пояс и т. Д.), А затем файл local_settings.py
для конкретных настроек развертывания, т.е. с какой базой данных общаться, с каким сокетом memcache, адресом электронной почты для администраторов и так далее.
Я искал похожие шаблоны для Node. Было бы неплохо просто файл конфигурации, так что его не нужно смешивать со всем остальным app.js
, но я считаю важным иметь способ иметь специфическую для сервера конфигурацию в файле, который не находится под контролем исходного кода. Одно и то же приложение вполне может быть развернуто на разных серверах с совершенно разными настройками, с необходимостью иметь дело с конфликтами слияния и всем, что не является моей идеей забавы.
Так есть ли какой-то фреймворк / инструмент для этого или все просто взломали что-то вместе?
Ответы:
Я использую
package.json
для своих пакетов иconfig.js
для моей конфигурации, которая выглядит следующим образом:Я загружаю конфиг из моего проекта:
и затем я могу получить доступ к своим вещам из
config.db_host
,config.db_port
и т.д ... Это позволяет мне использовать жестко закодированные параметры или параметры, хранящиеся в переменных среды, если я не хочу хранить пароли в управлении исходным кодом.Я также генерирую
package.json
и вставляю раздел зависимостей:Когда я клонирую проект на свою локальную машину, я запускаю
npm install
установку пакетов. Больше информации об этом здесь .Проект хранится в GitHub, с добавленными пультами для моего производственного сервера.
источник
Вы можете требовать файлы JSON с Node v0.5.x ( ссылаясь на этот ответ )
config.json:
app.js:
источник
Намного позже я нашел довольно хороший модуль Node.js для управления конфигурацией: nconf .
Простой пример:
Он также поддерживает хранение настроек в Redis , написание файлов конфигурации и имеет довольно солидный API, а также поддерживается одним из наиболее уважаемых магазинов Node.js, Nodejitsu , как часть инициативы платформы Flatiron , так что это должно быть довольно перспективный.
Проверьте nconf в Github .
источник
Мое решение довольно простое:
Загрузите конфигурацию среды в ./config/index.js
Определите некоторые значения по умолчанию в ./config/config.global.js
Переопределите значения по умолчанию в ./config/config.test.js
Используя его в ./models/user.js:
Запуск вашего приложения в тестовой среде:
источник
NODE_ENV
умолчанию «развитие». Вы должны проверить «производство» вместо этого.Вы также можете посмотреть на dotenv, который следует принципам приложения из двенадцати факторов .
Раньше я использовал node-config, но по этой причине создал dotenv. Он был полностью вдохновлен библиотекой рубинов.
Использование довольно просто:
Затем вы просто создаете файл .env и помещаете туда свои настройки следующим образом:
Это дотенв для nodejs.
источник
foreman run node xx.js
это автоматически прочитает в вашем файле .env..env
файл в процесс управления версиями или в процесс развертывания.Ребята, вы используете npm для запуска ваших скриптов (env и т. Д.)?
Если вы используете
.env
файлы, вы можете включить их в свойpackage.json
и использовать npm для их создания / запуска.Пример:
затем запустите сценарии npm:
Это описано здесь https://gist.github.com/ericelliott/4152984 Вся заслуга Эрика Эллиота
источник
source : not found
source
(или просто.
) - это встроенная команда в оболочках Unix (Bash и т. Д.) Для чтения и выполнения команд из данного файла в текущей оболочке . То есть команды не выполняются в под-оболочке. Эффект этого в этом примере состоит в том, что переменные среды, определенные вprod.env
, добавляются в текущую оболочку и, следовательно, передаются любому дочернему процессу, порожденному этой оболочкой. Вы, кажется, используете Windows CMD. Смотрите этот вопрос для более подробной информации.dev.env
иprod.env
, но иметь один.env
файл на развертывание.Вы также можете посмотреть на node-config, которая загружает файл конфигурации в зависимости от переменной $ HOST и $ NODE_ENV (немного похоже на RoR): документация .
Это может быть весьма полезным для различных параметров развертывания (
development
,test
илиproduction
).источник
Просто сделайте простое
settings.js
сexports
:Затем в вашем скрипте выполните
require
:Все ваши настройки теперь будут доступны через
settings
переменную:источник
Я собираюсь бросить свою шляпу в кольцо здесь, потому что ни один из этих ответов не обращается ко всем критическим компонентам, которые в значительной степени нужны любой системе. Соображения:
Вот как я делаю свою конфигурацию:
config.default.private.js
- В управлении версиями это параметры конфигурации по умолчанию, которые видны только вашему бэкэнду.config.default.public.js
- В управлении версиями это параметры конфигурации по умолчанию, которые видны бэкэндом и внешним интерфейсом.config.dev.private.js
- Если вам нужны разные частные настройки по умолчанию для dev.config.dev.public.js
- Если вам нужны разные публичные значения по умолчанию для dev.config.private.js
- Не в управлении версиями, это специфические параметры среды, которые переопределяютconfig.default.private.js
config.public.js
- Не в управлении версиями, это специфические параметры среды, которые переопределяютconfig.default.public.js
keys/
- Папка, в которой каждый файл хранит какой-то секрет. Это также не под контролем версий (ключи никогда не должны быть под контролем версий).Я использую простые старые файлы javascript для конфигурации, поэтому у меня есть все возможности языка javascript (включая комментарии и возможность делать такие вещи, как загрузка файла конфигурации по умолчанию в файле, специфичном для среды, чтобы затем их можно было переопределить). Если вы хотите использовать переменные окружения, вы можете загрузить их в эти файлы конфигурации (хотя я рекомендую не использовать env vars по той же причине, по которой я не рекомендую использовать файлы json - у вас нет возможностей языка программирования для создания ваш конфиг).
Причина, по которой каждый ключ находится в отдельном файле, предназначена для использования установщиком. Это позволяет вам иметь установщик, который создает ключи на компьютере и сохраняет их в папке ключей. Без этого ваш установщик может потерпеть неудачу при загрузке файла конфигурации, который не может получить доступ к вашим ключам. Таким образом, вы можете перемещаться по каталогу и загружать любые ключевые файлы, которые находятся в этой папке, не беспокоясь о том, что существует, а что нет в любой конкретной версии вашего кода.
Поскольку у вас, вероятно, есть ключи, загруженные в вашу личную конфигурацию, вы определенно не хотите загружать вашу личную конфигурацию в любой код внешнего интерфейса. В то время как, вероятно, было бы гораздо более идеальным полностью отделить вашу кодовую базу веб-интерфейса от вашей серверной части, во многих случаях PITA является достаточно большим барьером, препятствующим тому, чтобы люди делали это, таким образом, частная и общедоступная конфигурация. Но есть две вещи, которые я делаю, чтобы предотвратить загрузку приватного конфига в интерфейсе:
И последнее: ваша конфигурация должна быть загружена в браузер с помощью совершенно отдельного файла, чем любой другой код вашего внешнего интерфейса. Если вы связываете свой код внешнего интерфейса, общедоступная конфигурация должна создаваться как отдельный пакет. В противном случае ваш конфиг уже не является конфигом - это просто часть вашего кода. Конфиг должен быть разным на разных машинах.
источник
Convict - это еще одна опция, которая добавляет схему для проверки. Как и nconf, он поддерживает загрузку настроек из любой комбинации переменных среды, аргументов, файлов и объектов json.
Пример из README:
Начальная статья: Укрощение конфигураций с помощью node-convict
источник
Вы можете использовать Konfig для конкретных конфигурационных файлов. Он загружает файлы конфигурации json или yaml автоматически, имеет значения по умолчанию и функции динамической конфигурации.
Пример из репозитория Konfig:
В развитие:
В производстве предположим, что мы запускаем приложение с
$ NODE_ENV=production PORT=4567 node app.js
Более подробная информация: https://github.com/vngrs/konfig
источник
Я создам папку как config имя файла, а
config.js
позже я буду использовать этот файл везде, где требуется, как показано нижеПример config.js
Тогда, если я хочу использовать этот файл конфигурации где-нибудь
Я сначала импортирую, как показано ниже
var config = require('./config');
и я могу получить доступ к значениям, как показано ниже
источник
Просто используйте
npm
модульconfig
(более 300000 загрузок)https://www.npmjs.com/package/config
Node-config организует иерархические конфигурации для ваших приложений.
Он позволяет вам определять набор параметров по умолчанию и расширять их для различных сред развертывания (разработки, качества, подготовки, производства и т. Д.).
источник
Лучше разделять конфиги «разработка» и «производство» .
Я использую следующий способ: Вот мой файл config / index.js :
Для настройки требуется использовать следующее:
Чем вы можете использовать свой объект конфигурации:
источник
module.exports = config;
в концеconfig/index.js
файлаЯ немного опоздал в игре, но я не мог найти то, что мне было нужно здесь или где-то еще, поэтому я написал что-то сам.
Мои требования к механизму конфигурации следующие:
settings-overrides.js
- которая выглядит так же, но допускает переопределения конфигурацииsettings.js
. Идея заключается в том, чтобы легко изменить конфигурацию без изменения кода. Я считаю это полезным для СААС.Несмотря на то, что меня меньше заботят вспомогательные среды, я объясню, как легко добавить его в мое решение.
объяснение
undefined
означает, что это свойство обязательноnull
означает, что это необязательноmeConf
- в настоящее время код является целевым для файла вapp
.meConf
это файлы переопределений, на которые нацеленыconf/dev
- которые игнорируются моими vcs.publicConfiguration
- будет виден с передней и задней части.privateConfiguration
- будет виден только с конца.sendPublicConfiguration
- маршрут, который представит общедоступную конфигурацию и назначит ее глобальной переменной. Например, приведенный ниже код предоставит общедоступную конфигурацию как глобальную переменную myConf во внешнем интерфейсе. По умолчанию он будет использовать имя глобальной переменнойconf
.app.get ("/ backend / conf", require ("conf"). sendPublicConfiguration);
Логика переопределений
Добавление поддержки среды
Даже если я не нахожу полезной «поддержку среды», возможно, кто-то это сделает.
Чтобы добавить поддержку среды, вам нужно изменить выражение meConf require на что-то вроде этого (псевдокод)
if (environment == "production") {meConf = require ("../ conf / dev / meConf"). production; }
if (environment == "development") {meConf = require ("../ conf / dev / meConf"). development; }
Точно так же вы можете иметь файл для каждой среды
и импортировать правильный. Остальная логика остается прежней.
источник
undefined
самом деле означает «требуется» иnull
означает «необязательно». так желтая корзина для пластмассы, а синяя для макулатуры? хорошо, но пришлось прочитать руководство, прежде чем бросать этот мусор.Пример alt, который я только что использовал, потому что я хотел большей гибкости, чем типичный файл .json, но не хотел, чтобы его абстрагировали в библиотеку, для которой потребовалась бы зависимость, что-то вроде этого. По сути, экспорт вызываемой функции немедленно возвращает объект со значениями, которые я хотел установить. Дает большую гибкость.
Здесь есть намного лучшее объяснение с полным примером. Использование файлов конфигурации в Node.js
источник
Я знаю, что это действительно старый пост. Но я хочу поделиться своим модулем для настройки переменных среды, я думаю, что это очень гибкое решение. Вот модуль json-конфигуратор
Затем вы можете использовать,
process.env.NODE_ENV
чтобы получить все переменные для вашей среды.источник
Помимо модуля nconf, упомянутого в этом ответе , и узла-конфигурации, упомянутого в этом ответе , существуют также node-iniparser и IniReader , которые представляются более простыми анализаторами файла конфигурации .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, переживания исчезли.Я только недавно выпустил небольшой модуль для загрузки любых типов файлов конфигурации. Это довольно просто, вы можете проверить это на https://github.com/flesler/config-node
источник
Вы можете использовать pconf: https://www.npmjs.com/package/pconf
Пример:
источник
Вот аккуратный подход, вдохновленный этой статьей . Он не требует никаких дополнительных пакетов, кроме вездесущего пакета lodash . Более того, он позволяет вам управлять вложенными значениями по умолчанию с перезаписью, зависящей от среды.
Сначала создайте папку config в корневом каталоге пакета, которая выглядит следующим образом
вот файл index.js
Теперь давайте предположим, что у нас есть defaults.json как
и development.json вроде так
если вы сделаете
config = require('./config')
вот то, что вы получитеОбратите внимание, что вы получаете все значения по умолчанию, за исключением тех, которые определены в специфичных для среды файлах. Таким образом, вы можете управлять иерархией конфигурации. Использование
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/
источник