Налаштування змінних середовища

Зміст:

• Підсумок
  • Проблема
  • Рішення
  • Статус
• Подробиці
  • Припущення
  • Обмеження
  • Позиції
  • Аргумент
  • Наслідки
• Пов’язане
  • Пов’язані рішення
  • Пов’язані вимоги
  • Пов’язані артефакти
  • Пов’язані принципи
• Примітки

Підсумок

Проблема

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

• Для цього ми хочемо використовувати налаштування через змінні середовища.

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

• Ми хочемо забезпечити певну ергономіку досвіду розробника, наприклад знати, що можна налаштувати і які є відповідні значення за замовчуванням.

Рішення

Обрано файли .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