Противоречит ли dotenv приложение с двенадцатью факторами?
Я прочитал о конфигурации приложения Twelve Factor - Раздел III и искал способ сделать это в NodeJS. Кажется, что большинство людей рекомендуют dotenv хранить конфиги в переменных окружения.
Тем не менее, кажется, что dotenv противоречит приложению Twelve-Factor, как говорится:
Другой подход к конфигурации - это использование файлов конфигурации, которые не включены в систему контроля версий, таких как config/database.yml в Rails. Это огромное улучшение по сравнению с использованием констант, которые проверены в репо кода, но все еще имеют недостатки: легко по ошибке проверить в файле конфигурации репо; Существует тенденция разбрасывать конфигурационные файлы в разных местах и разных форматах, что затрудняет просмотр и управление всей конфигурацией в одном месте. Кроме того, эти форматы, как правило, зависят от языка или структуры.
Приложение с двенадцатью факторами хранит конфигурацию в переменных среды (часто сокращается до env vars или env). Env vars легко переключать между развертываниями без изменения кода; в отличие от конфигурационных файлов, существует небольшая вероятность того, что они случайно попадут в репозиторий; и в отличие от пользовательских файлов конфигурации или других механизмов конфигурации, таких как Java System Properties, они являются независимым от языка и ОС стандартом.
Имея смысл этого утверждения, кажется, что с помощью dotenv вы создадите файл конфигурации .env который затем экспортирует их как переменные среды.
Не нарушит ли это приложение с двенадцатью факторами, так как .env файл может случайно попасть в код репо?
3 ответа
12фактор не нарушается, пока кто-то на самом деле не совершит и не вытолкнет .env;)
.env Файл также может храниться вне самого репо, поскольку библиотека или приложение все еще должны прочитать .env файл и вставить переменные в среду. В зависимости от вашей реализации это может быть так же просто, как изменение пути от ".env" в "../.env",
С помощью .env файлы могут быть хорошим компромиссом, позволяющим разработчикам легко управлять средами, но при этом быть совместимыми с лучшими практиками среды при развертывании. У меня может быть 30-40 приложений с 12 факторами, работающими на виртуальной машине, и необходимость управлять каждой средой в отдельности - это ужасно без "шиммы" .env,
ОП задал хорошо продуманный вопрос.
Я бы сказал, что dotenv противоречат 12-фактору, раздел 3, по двум причинам.
По определению, то есть этот абзац: «Другой подход к конфигурации — это использование файлов конфигурации, которые не проверяются в системе контроля версий, ... все еще имеет недостатки: легко ошибочно проверить файл конфигурации в репозиторий; ... ( поэтому 12-факторное приложение использует другой подход, поскольку) сохраняет конфигурацию в переменных среды», теперь вы видите, только потому, что файл может/должен быть объявлен внутри
.gitignore, не освобождает dotenv от проверки «легко ошибочно проверить файл конфигурации в репозитории».В противном случае приложение может полностью соответствовать 12-фактору, раздел 3, если оно считывает конфигурацию из и только из env var. Но функция dotenv позволяет приложению автоматически
./.envесли он доступен. В этом смысле файл — несмотря на его обманчивое название — ЯВЛЯЕТСЯ конфигурационным файлом, насквозь. Опять же, это относится к категории подходов к настройке, которых явно избегает 12-фактор.
При этом dotenv по-прежнему остается одним из жизнеспособных вариантов. Другие варианты включают в себя: управление переменными окружения на уровне докеров; или в пользовательском unix
.*rcфайл; или в конфигурации веб-сервера; или в
/etc/profile(цитата из этого другого поста SO). предлагает один из самых универсальных форматов файлов (между прочим, docker env_file одинаково прост, хотя их спецификации различаются), однако это единственное решение, которое «загрязняет» кодовую базу целевого приложения еще одной зависимостью.
Итог, это нормально, также забавно, что многие
dotenvреализация наследует утверждение о том, что она началась с принципа 12-факторного приложения, но лишь немногие признают, что его
.envподход отличается от 12-факторного приложения.
Большинство систем контроля версий имеют способы игнорирования определенных файлов.
Git имеет .gitignore
SVN имеет "Особое игнорирование"
В качестве примечания, эти методы аналогичным образом используются для игнорирования node_modules каталог, чтобы избежать ненужного копирования файлов.