#node.js #amazon-web-services #environment-variables #dotenv #aws-parameter-store
#node.js #amazon-web-services #переменные среды #dotenv #aws-parameter-store
Вопрос:
Я пытаюсь получить доступ к своим переменным среды из хранилища параметров aws, но я не уверен, как я могу получить к ним доступ во всех файлах, не делая их глобальными или не сохраняя их в process.env. Есть ли какой-либо более безопасный подход для этого. Я хотел использовать экспорт этих переменных, но поскольку экспорт процессов во время выполнения и моих параметров aws происходит после этого. Спасибо.
Примечание: — Я не использую бессерверную среду, где я могу напрямую обращаться к ним по имени переменной.
Комментарии:
1. Вы говорите об одной программе или нескольких разных программах?
2. Один проект узла js с различными файлами, в которых мне требуются эти переменные среды.
Ответ №1:
Переменные среды — это действительно плохой способ взаимодействия в рамках одного приложения. Обычно они используются как одно решение для обмена данными между несколькими приложениями.
Обычный способ сохранения и извлечения параметров конфигурации в вашем приложении — использовать модуль. Да, модули обычно содержат код, но ничто не мешает вам создать модуль, в котором хранятся только данные. Действительно, это довольно стандартный механизм для хранения настроек.
Файл JSON
Для фиксированных значений конфигурации, таких как файл конфигурации, стандартом является просто использование файла json. Например:
config.json:
{
"port": 3000
}
Тогда вы можете просто запросить файл json везде, где он вам нужен:
main.js:
config = require('./config'); // node will automatically search for
// config.js or config.json
app.listen(config.port);
some_module.js:
config = require('../../config');
console.log('we connected via port', config.port);
Файл JS
Некоторые люди считают, что JSON слишком ограничен, потому что вы не можете помещать комментарии в файл JSON. Большинство людей обычно экспортируют объект из обычного модуля js:
lib/config.js:
let config = {
port: 3000, // port to listen to, LOOK! COMMENTS!!
messagePrefix: 'Hello ', // also, don't need to quote property names
// also, can use single quotes for strings
// also, dangling quotes are supported
}
module.exports = config
main.js:
const config = require('./lib/config');
app.listen(config.port);
some_module.js:
const config = require('./lib/config');
console.log(config.messagePrefix 'World'); //Hello World
Одна вещь, которую нужно понять о том, как require
это работает, заключается в том, что она будет кэшировать значение module.exports
, сгенерированное модулем. Это заставляет модули узла вести себя как одиночные. В приведенном выше примере config
переменная в обоих main.js
и some_module.js
указывает на один и тот же объект! Я повторю это снова, потому что это важно: в приведенном выше примере существует только один объект конфигурации, созданный node.js . Это означает, что вы можете использовать модуль чистых данных, такой как config.js
file, для связи между модулями в вашем коде. Например, вы можете сделать это:
main.js:
const config = require('./lib/config');
config.messagePrefix = 'Goodbye ';
app.listen(config.port);
some_module.js:
const config = require('./lib/config');
console.log(config.messagePrefix 'World'); //Goodbye World
JS-файл, который считывает конфигурацию откуда-то еще
Поскольку мы используем обычный модуль для обмена данными конфигурации с остальной частью нашего кода, мы можем запускать любой алгоритм, который мы хотим сгенерировать конфигурации:
config.js:
let config = {};
// Try to load default config:
try {
let rawdata = fs.readFileSync('./default-config.json');
config = JSON.parse(rawdata);
}
catch (err) {
// cannot load default config, just skip it
}
// Try to load user-specific config:
try {
// Read some configs from a file:
let rawdata = fs.readFileSync('./config.json');
let userconfig = JSON.parse(rawdata);
// override default configs:
for (prop in userconfig) {
config[prop] = userconfig[prop];
}
}
catch (err) {
// cannot load user config, just skip it
}
// Override default config and user config if environment variable is set:
if (process.env.PORT) {
config.port = process.env.PORT;
}
module.exports = config;
Как показано в приведенном выше примере. Вы можете использовать любую логику для построения конфигурационных данных. Вам нужно будет проявить немного больше изобретательности, если какие-либо данные конфигурации поступают из асинхронного источника, такого как база данных, но вы можете просто обернуть весь модуль обещанием и просто дождаться конфигурации.
В общем случае конфигурация должна храниться в файлах. Не переменные среды. Переменные среды должны хранить информацию об окружающей среде, например, где находится путь к вашему компилятору C или где находится ваш веб-браузер или какой язык этот компьютер настроен для использования по умолчанию. Такие вещи, как номера портов процесса, не должны храниться в переменных среды, хотя традиционно (под традиционной я подразумеваю традицию Unix, разработанную с 1960-х годов по сегодняшний день) приемлемо использовать переменные среды для переопределения конфигураций для облегчения отладки.
В зависимости от используемой вами ОС существуют различные места, в которых люди традиционно хранят файлы конфигурации: /etc
каталог в Unix, Application Data
в Windows, ~/.config
каталог на современных настольных компьютерах Unix и т. Д.
Существует несколько модулей npm, которые могут помочь вам организовать ваши конфигурационные файлы. В зависимости от ваших потребностей вы можете найти rc или config или configstore полезными. Лично я хотел бы продвигать свой собственный модуль config-default-cjson, но другие модули выше имеют больше возможностей.