Інструмент зберігання відповідно до конфігурації середовища

У мене є вимога зберігати інформацію про конфігурацію для кожного середовища в інструменті.

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

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

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

Примітка : В даний час налаштування знаходяться в змінних TeamCity, а розгортання здійснюється через сценарії PowerShell.

— Тім
джерело

На платні речі? Чи є у вас система управління конфігурацією? що ви використовуєте для розгортання?

— Тенсібай

Оплачені параметри будуть налаштовані. В даний час налаштування знаходяться в змінних TeamCity, а розгортання здійснюється через сценарії PowerShell.

— Тім

Не суворо відповідь, звідси коментар - чи розглядали ви використання Octopus Deploy для розгортання, що дозволяє керувати конфігурацією навколишнього середовища дуже гнучко.

— Річард Слейтер

Якщо ви використовуєте розріджену систему управління джерелами гілки, наприклад ClearCase, ви можете просто розгалужувати файли з модифікаціями, ви можете переглянути стратегії обробки змін OSD (залежно від операційної системи) в VCS. Якщо ви використовуєте git, вам потрібно буде постійно відновлювати гілки, які не використовуються за замовчуванням, постійно. Деякі інструменти конфігурації мають параметри середовища за допомогою змінних. У Ansible я маю файл зі змінними за замовчуванням та накладками для невиробничих середовищ. Не зберігайте жодних налаштувань в інструментах CI, вони повинні бути всі в VCS. У тому числі конфігурації TC.

— Іржі Клуда

рекомендуємо зберігати всю конфігурацію з джерелом. ми маємо декілька сервісів azure і використовуємо синтаксис трансформації блакитного кольору для всіх налаштувань середовища. див. msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx . І ми насправді робимо це разом із силовою оболонкою під час розгортання в рамках установки. Залежно від місця підключення до конвеєра, ви можете зробити це перед тим, як розміщувати біти на коробці або, після паролів, після. Ми використовуємо Azure Key Vault для секретів, щоб вони ніколи не з’являлися в контролі джерел.

— Повернення коштів не повернено,

Є багато інструментів, які можуть зробити щось подібне, включаючи засоби управління конфігурацією, такі як шеф-кухар, відповідальний або ляльковий; та інструменти KVS, такі як консул та ін. Ви також можете інтегрувати його як крок збирання у свій сервер CI або усунути проблему, використовуючи конфігурацію в реальному часі під час виконання проти зовнішнього сховища конфігурації (знову-таки, на кшталт консула чи etcd, або будь-якої бази даних взагалі).

— Адріан
джерело

Можливо, інше репо? Один з філіями для QA, UAT, Prod (не більше). Репо, що відрізняється від звичайних репост "Код як код" та "Інфраструктура як код".

Це високо нюанс. Скільки конфігурацій на env. Чи перемикається між випусками? Якщо ці перемикачі стану підтримують стан, незважаючи на бінарні розгортання. Для кого з клієнтів, клієнтів, гостей або користувачів ви підтримуєте конфігурацію?

Я написав купу записів у блозі (та прототипи / демонстрації) на цю тему протягом 5 років - включаючи інтерфейси для перемикання (якщо вони потрібні).

— paul_h
джерело