Як слід зберігати змінні середовища?

Це дуже широке запитання щодо методів та порад щодо змінних / структури середовища. Але в кінцевому підсумку я шукаю відповіді на дуже специфічне питання "Як мені зберігати змінні середовища"?

По-перше, деякі пояснення:

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

Наразі ми зберігаємо всі змінні середовища в такій структурі:

<playbook>.yml                   # Various playbooks for deployment
roles/windows                    # Ansible role for Ubuntu
roles/ubuntu                     # Ansible role for Ubuntu
config/hosts/<name>.yml          # Ansible inventory
config/hosts/vars/<name>.json    # Environment specific variables 

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

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

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

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

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

Будь-які пропозиції?

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

Загальні фактори

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

Використання консулів К. В. Пар

Змінні середовища завантажуються з сховища артефактів (ніколи не є оригінальним git repo) і завантажуються в дерево KV з парними просторами, наприклад

/env/dev1/my/application/v1.1.1

Якщо попередній dev1 - це ім'я середовища, my / application - це область імен додатків, а v1.1.1 - версія змінних оточуючих середовищ, які слід використовувати.

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

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

Зберігання артефакту "Розгортання" зі вбудованими змінними

Це щільно з'єднує точну версію артефакту з версією конфігурації. Якщо ви змінили конфігурацію, тоді вам довелося відновити цей артефакт розгортання.

Сам артефакт розгортання був, по суті, файлом yaml, який містив URL-адресу до розрядного двійкового файлу та всю приєднану до нього конфігурацію.

Платформа містить компоненти для зчитування змінних, а потім виведення їх у дерево процесів програми під час її запуску.

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

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

Бонусні бали

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

Справді, керування секретами - це власна банка глистів. Але це, мабуть, варто задуматися.

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

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

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

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