Конфигуриране на променливи на средата

Съдържание:

• Резюме
  • Проблем
  • Решение
  • Състояние
• Подробности
  • Допускания
  • Ограничения
  • Позиции
  • Аргумент
  • Последици
• Свързани
  • Свързани решения
  • Свързани изисквания
  • Свързани артефакти
  • Свързани принципи
• Бележки

Резюме

Проблем

Искаме нашите приложения да могат да се конфигурират извън артефактите/двоичните файлове/изходния код, така че едно изграждане да се държи различно в зависимост от средата си на внедряване.

• За да постигнем това, искаме да използваме конфигуриране чрез променливи на средата.

• Искаме да управляваме конфигурацията чрез файлове, които можем да поставяме под контрол на версиите.

• Искаме да осигурим известна ергономичност за разработчиците, като например знание какво може да се конфигурира и кои са съответните стойности по подразбиране.

Решение

Избрахме .env файлове със свързан файл със стойности по подразбиране и файл със схема.

Състояние

Взето. Открити сме да разгледаме нови възможности, когато се появят.

Подробности

Допускания

Предпочитаме да разделяме кода на приложението и кода на средата. Допускаме, че приложението трябва да работи по различен начин в различни среди, като среда за разработка, тестова среда, демонстрационна среда, производствена среда и т.н.

Предпочитаме отрасловата практика „12 factor app“ и още повече свързаната практика „15 factor app“.

Много от предишните ни проекти са използвали конвенцията за файл .env или подобна директория .env. Типична практика е те да се държат извън контрола на версиите и вместо това да се използва друг начин за внедряването, версионирането и управлението им.

Ограничения

Искаме да държим тайните извън нашата система за контрол на версиите (VCS) за управление на изходния код (SCM).

Искаме да се стремим към съвместимост с популярни софтуерни рамки и библиотеки. Например Node има модул „dotenv“ за четене на конфигурация от променливи на средата.

Позиции

Обмислихме няколко подхода:

• Съхраняване на конфигурацията в приложението, например във файл config.js.

• Съхраняване на конфигурацията в средата, например във файл .env.

• Извличане на конфигурацията от известно място, например от лицензен сървър.

Аргумент

Избрахме подхода с файл .env, защото:

• Той е популярен, включително сред експертите.

• Следва модела на .env файловете, които нашите екипи са използвали успешно много пъти в много проекти.

• Той е прост. По-специално за сега сме съгласни със значителните компромиси, които виждаме, като липсата на възможности за одит в сравнение с подхода с лицензен сървър.

Последици

Трябва да намерим начин да отделим конфигурацията чрез променливи на средата, която е публична, от всяко управление на тайни.

Свързани

Свързани решения

Очакваме всички наши приложения да използват този подход.

Ще планираме да надградим всички наши приложения, които използват по-слабо способен подход, като твърдо кодиране в двоичен файл или в изходния код.

Ще оставим непроменени всички наши приложения, които използват по-способен подход, като лицензен сървър.

Свързани изисквания

Ще добавим devops възможности за файловете, включително куки (hooks), тестове и непрекъсната интеграция.

Трябва да обучим всички членове на екипа за разработка за това решение.

Свързани артефакти

Всяка област, в която внедряваме, ще се нуждае от собствен .env файл и свързани файлове.

Свързани принципи

Лесно обратимо.

Бележки

Примерен файл .env:

NAME=Alice Anderson
EMAIL=alice@example.com

Примерен файл .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

Примерен файл .env.schema само с ключовете:

NAME
EMAIL