Де я повинен розмістити конфігурацію програми?

Нещодавно я читав дебати на тему " Де слід зберігати властивості, які залежать від навколишнього середовища? ".

Класичним способом є наявність декількох файлів властивостей, один за оточенням, і на основі змінної середовища (DEV, PROD ...) ви вибираєте, де їх читати під час запуску програми (наприклад, із профілями Spring).

З іншого боку, якщо ви використовуєте контейнер для розгортання програми, говориться, що така конфігурація повинна виходити з самого середовища (використовуючи змінні середовища, які читає програма), тому зображення не змінюється між середовищами.

Які плюси і мінуси кожного підходу? Чи існує "найкращий" підхід для контейнерного сценарію?

Хто сказав, що файли властивостей і змінні середовища, де взаємовиключні?

Існує різниця між "де я зберігаю конфігурацію програми?" І "звідки в моєму додатку джерело його конфігурації?"

Найімовірнішим результатом є те, що кожен, ймовірно, повинен просто продовжувати робити те, що вони роблять з файлами конфігурації як механізмом зберігання (думати довгостроково, стійкий стан, поки існує середовище).

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

Це означає, що вам потрібно мати два робочі потоки розгортання -

1. Я можу застосувати додаток у середовище, пройшовши процес контролю X зміни та роблячи огляди Y за допомогою інструменту Z, що б там не було.
2. Я розгортаю свою конфігурацію оточення в середовище, проходячи процес контролю змін і роблячи огляди B з інструментом C, той самий процес, різний результат.

Використовувати приклад управління змінними середовища в якості пар ключових значень в інструменті, як консул, якщо ви зберігаєте конфігураційні файли в git, то такі інструменти, як git2consul з ручкою, отримують цю конфігурацію в середовищі, коли вона оновлюється.

Якщо у вас є додаток, який очікує, що буде конфігурація доступна як файл конфігурації, ви можете уникнути доставки декількох копій файлу конфігурації з додатком, побудувавши процес розгортання з чимось на зразок консульського шаблону, який має можливість перетворити ваш Значення консула повертаються у файл.

 Ми робимо це 3 штуки (або артефакти) для кожної запущеної програми.

1. Додаток, який ми розробляємо. Це те саме, незалежно від оточення. Щоб відповідати вашому прикладу, це буде Spring-додаток як баночка / війна.
2. Контейнер, який запустить додаток. Це те саме, незалежно від оточення. Якщо ви використовуєте Spring Boot, вам більше не потрібен Tomcat, а просто виконання Java. Тому використовуйте контейнер openjdk Docker.
3. Конфігурація, яка потрібна додатку. Це єдине, що різне в різних середовищах. У додатку Spring ви, ймовірно, будете використовувати файл властивостей.

Файл конфігурації живе в окремому контролі джерела. Це раніше було Git, але зараз ми використовуємо SaaS, який ми створили під назвою Config, за адресою http://www.configapp.com . Основною особливістю Config є легке керування конфігурацією, що відповідає специфічному середовищу. Щоб запустити нашу програму на новому сервері, ми витягуємо контейнер Docker, артефакт програми та файл конфігурації для цього середовища. У контейнері ми монтуємо каталог, де зберігаються програма та файл конфігурації, як частина запущеного контейнера. Наш додаток той самий. Наш контейнер / зображення однаковий. Тільки файл конфігурації інший.

Щодо змінного файлу конфігурації та середовища. Найдовше ми використовували файли конфігурації. Коли ми використовували PaaS / хмару, ми використовували змінні середовища. Це було додатковою роботою, якщо у вас багато конфігурації, тому ми в кінцевому підсумку використовуємо змінні середовища для визначення правильного файлу конфігурації. У нас є одна програма, яка перетворила властивості на змінні середовища, але це нетипово. Якщо у нас є санкціонований фірмою централізований сервер конфігурації, ми використовуємо це, інакше нам подобається простота файлів конфігурації.

Отже, підводячи підсумок, ми витягуємо app.jar, app.properties, openjdk Docker. Потім ми запускаємо openjdk Docker, монтуючи розташування app.jar та app.properties. Єдине, що стосується середовища - це app.properties. Щоб легко керувати властивостями програми, незалежно від того, скільки клавіш властивостей, середовищ, екземплярів кластера / регіону, ми використовуємо Config.