Есть ли способ получить доступ к переменной (aws-ssm) на протяжении всего проекта в узле js, отличном от process.env?

#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, но другие модули выше имеют больше возможностей.