Comments 16
Вот в момент создания env-файла что-то пошло не так. В ноде есть возможность подключить одной строчкой структурированный конфиг в формате json — зачем после этого использовать какой-то env?
UFO just landed and posted this here
Чтобы при развертывании приложении в Docker или Azure или что там популярно на этой неделе точно так же читать конфиг из process.env.SOMETHING, а не генерировать этот json на основе переменных (невелик труд, но все-таки).
Вы видимо не поняли концепцию. Модуль dotenv подключает переменные окружения из файла .env в стандартный process.env.
Т.е. пока вы запускаетесь локально, вы имитируете в удобной форме передачу параметров процессу в виде человеко читаемого текстового файла. А потом, при запуске в продакшн окружении внутри doker-контейнера например или в качестве heroku-application вы уже не будете указывать .env файл и ваш код без изменений получит эти же переменные от среды исполнения по стандартному механизму передачи переменных окружения (doker, heroku или как в примере у автора azure).
А цепляя config.json с помощью require вы по сути хардкодите у себя параметры в модуле, полностью игнорируя стандартные механизмы передачи конфигурационных данных через переменные окружения.
Описанный в статье способ, удобен при работе с сервисами деплой кода на которые осуществляется из систем контроля версий. В вашем случае, вы будете вынуждены задеплоить свой условный config.json с приватными данными (токены, авторизация в базах данных, etc) в репозиторий. Иначе у вас не получится передать ваш файл с конфигурацией сервису исполнения. Переменные окружения полностью решают эту проблему.
Т.е. пока вы запускаетесь локально, вы имитируете в удобной форме передачу параметров процессу в виде человеко читаемого текстового файла. А потом, при запуске в продакшн окружении внутри doker-контейнера например или в качестве heroku-application вы уже не будете указывать .env файл и ваш код без изменений получит эти же переменные от среды исполнения по стандартному механизму передачи переменных окружения (doker, heroku или как в примере у автора azure).
А цепляя config.json с помощью require вы по сути хардкодите у себя параметры в модуле, полностью игнорируя стандартные механизмы передачи конфигурационных данных через переменные окружения.
Описанный в статье способ, удобен при работе с сервисами деплой кода на которые осуществляется из систем контроля версий. В вашем случае, вы будете вынуждены задеплоить свой условный config.json с приватными данными (токены, авторизация в базах данных, etc) в репозиторий. Иначе у вас не получится передать ваш файл с конфигурацией сервису исполнения. Переменные окружения полностью решают эту проблему.
Как вообще кто-либо что-либо узнаёт? Но в Node самый большой номер порта — это 65534. Почему? Понятия не имею. Я не могу знать абсолютно всё.RFC 793: под Source Port и Destination Port 16 бит.
А дальше? Почему не 65535-то?
Ах, он про это. Но, в любом случае, не понимаю, почему предьява именно к Node.js. На Windows, например, порт максимальный 65,534 в принципе, и это не связанно с node.js.
потому что порт со всеми установленными битами это широковещательный порт
Два раза перечитал статью в поисках шуток про java.
Про
Если говорить о переменных окружения то наиболее приемлемый кажется вариант с использованием PM2 pm2.keymetrics.io/docs/usage/environment и вцелом запуск под PM2 кажется наиболее приемлемым для продакшна. Т.к. можно запустить приложение на нескольких ядрах, перезапускать приложение при сбоях и при перерасходе памяти.
А параметры вообще лучше перенести в обычный файл parameters.json, который не хранится в репозитарии а генерируется в диалоге при npm install. (В репозитарии обчыно хранится parameters.dist.json с значениями по умолчанию)
Про
Переменные окружения — одна из фундаментальных конструкций среды Node.js,можно спросить что значит фундаментальность.
Если говорить о переменных окружения то наиболее приемлемый кажется вариант с использованием PM2 pm2.keymetrics.io/docs/usage/environment и вцелом запуск под PM2 кажется наиболее приемлемым для продакшна. Т.к. можно запустить приложение на нескольких ядрах, перезапускать приложение при сбоях и при перерасходе памяти.
А параметры вообще лучше перенести в обычный файл parameters.json, который не хранится в репозитарии а генерируется в диалоге при npm install. (В репозитарии обчыно хранится parameters.dist.json с значениями по умолчанию)
Переменные окружения — одна из фундаментальных конструкций среды Node.js, но почему-то я никогда не стремился научиться правильно ими пользоваться
Одно из фундаментальных понятий ОПЕРАЦИОННОЙ СИСТЕМЫ! Не node.js не Java, операционной мать её системы!!!111 Как объясните мне КАК? Как можно не понимать фундаментальных элементарных вещей?? fuuuuuuu…
Адуха какая-то. Ладно, я ещё могу понять тех людей, которые писали про хранение настроек в .ini файлах, там хоть смысл какой-то был.
Но
- Ставить отдельный пакет
- Ставить отдельное расширение для VS Code
- Писать специальный JSON (который поддерживается только в VS Code)
Всё для того, чтобы писать настройки в файл с переменными окружения, который обладает только одним уровнем вложенности и не расширяем — это то, что могло родиться только в результате тяжёлой травмы (уж не знаю, от Java, Microsoft или ещё чего).
Насколько проще, логичнее и более масштабируемо использовать простой config...
Обычно задача решается весьма тривиально без регистрации и смс лишних пакетов, возможны вариации под проект (например чтение process.argv, подгрузка config.local.js который в .gitignore и т.п.)
// config.js
export default {
dbConnectionString: process.env.DB_CONNECTION_STRING || 'mongodb://mongo/db',
};
Sign up to leave a comment.
Использование переменных окружения в Node.js