Конфигурация через переменные окружения

Содержание:

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

Резюме

Проблема

Мы хотим, чтобы наши приложения можно было настраивать за пределами артефактов/двоичных файлов/исходного кода, так чтобы одна сборка могла вести себя по-разному в зависимости от среды развёртывания.

• Для этого мы хотим использовать конфигурацию через переменные окружения.

• Мы хотим управлять конфигурацией с помощью файлов, которые можно хранить в системе контроля версий.

• Мы хотим обеспечить удобство для разработчиков, например знание того, что можно настраивать, и значений по умолчанию.

Решение

Выбраны файлы .env с соответствующим файлом значений по умолчанию и файлом схемы.

Состояние

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

Подробности

Допущения

Мы предпочитаем разделять код приложения и код окружения. Мы предполагаем, что приложению нужно работать по-разному в разных средах, например в среде разработки, тестовой среде, демонстрационной среде, производственной среде и т. д.

Мы отдаём предпочтение отраслевой практике «12 factor app» и ещё больше родственной практике «15 factor app».

Многие наши предыдущие проекты использовали соглашение о файле .env или аналогичном каталоге .env. Типичная практика — не хранить их в системе контроля версий, а использовать другой способ их развёртывания, версионирования и управления ими.

Ограничения

Мы хотим исключить секреты из нашей системы контроля версий (VCS) для управления исходным кодом (SCM).

Мы хотим стремиться к совместимости с популярными программными фреймворками и библиотеками. Например, у Node есть модуль «dotenv» для чтения конфигурации через переменные окружения.

Позиции

Мы рассмотрели несколько подходов:

• Хранить конфигурацию в приложении, например в файле config.js.

• Хранить конфигурацию в окружении, например в файле .env.

• Получать конфигурацию из известного места, например с сервера лицензий.

Аргументация

Мы выбрали подход с файлом .env, потому что:

• Он популярен, в том числе среди экспертов.

• Он следует шаблону файлов .env, которые наши команды успешно использовали много раз во многих проектах.

• Он прост. В частности, нас пока устраивают существенные компромиссы, которые мы видим, например отсутствие возможностей аудита по сравнению с подходом сервера лицензий.

Следствия

Нам нужно найти способ отделить конфигурацию через переменные окружения, являющуюся общедоступной, от управления секретами.

Связанное

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

Мы ожидаем, что все наши приложения будут использовать этот подход.

Мы запланируем обновление любых наших приложений, использующих менее мощный подход, например жёсткое кодирование в двоичном файле или в исходном коде.

Мы оставим без изменений любые наши приложения, использующие более мощный подход, например сервер лицензирования.

Связанные требования

Мы добавим devops-возможности для этих файлов, включая хуки, тесты и непрерывную интеграцию.

Нам нужно обучить этому решению всех коллег-разработчиков.

Связанные артефакты

Каждой области, где мы развёртываем, понадобится собственный файл .env и связанные файлы.

Связанные принципы

Легко обратимо.

Примечания

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

NAME=Alice Anderson
EMAIL=alice@example.com

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

NAME=Joe Doe
EMAIL=joe@example.com

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

NAME
EMAIL