Инструмент для хранения каждой конфигурации среды

11

У меня есть требование для хранения информации о конфигурации в инструменте для каждой среды.

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

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

Я искал некоторое время и не вижу никаких инструментов, которые бы подходили под этот счет. Есть какие-нибудь предложения?

Примечание . В настоящее время настройки находятся в переменных TeamCity, а развертывание - через сценарии PowerShell.

deployment configuration-management configuration software-recommendation casc Тим
источник
На платные вещи? Есть ли у вас система управления конфигурацией? что вы используете для развертывания?
Тенсибай
Платные опции будут настроены. В настоящее время настройки находятся в переменных TeamCity, а развертывание - через сценарии PowerShell.
Тим
Не совсем ответ, а следовательно, и комментарий - рассматривали ли вы возможность использования Octopus Deploy для развертываний, поскольку это позволяет вам гибко управлять конфигурацией среды.
Ричард Слейтер
Если вы используете систему управления разреженными источниками ветвления, например ClearCase, вы можете просто разветвлять файлы с изменениями, вы можете посмотреть на стратегии обработки изменений OSD (зависящих от операционной системы) в VCS. Если вы используете git, вам придется постоянно перебазировать ветки, не являющиеся стандартными. Некоторые инструменты конфигурации имеют настройки для каждой среды через переменные. В Ansible у меня есть файл с переменными значениями по умолчанию и оверлеями для непроизводственных сред. Не храните никаких настроек в инструментах CI, все они должны быть в VCS. Включая конфиги ТС.
Иржи Клуда
рекомендуем хранить всю конфигурацию с источником. У нас есть несколько служб Azure, и мы используем синтаксис преобразования Azure для всех настроек среды. см. msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx . И мы фактически делаем это с PowerShell во время развертывания как часть установки. В зависимости от того, где вы подключитесь к конвейеру, вы можете сделать это перед тем, как поместить биты в поле или, для паролей, после. Мы используем хранилище ключей Azure для секретов, поэтому они никогда не отображаются в системе контроля версий.
Нет возврата, нет возврата,

Ответы:

6

Есть много инструментов, которые могут сделать что-то подобное, включая инструменты управления конфигурацией, такие как Chef, Ansible или Puppet; и инструменты KVS, такие как Consul и т. д. Вы также можете интегрировать его в качестве шага сборки на своем сервере CI или обойти проблему, используя оперативную конфигурацию во время выполнения, с внешним хранилищем конфигурации (опять же, что-то вроде Consul или etcd или любой базы данных вообще).

Адриан
источник
1

Возможно другое репо? Один с ответвлениями для QA, UAT, Prod (из ни более). Репо отличается от ваших обычных репо «Код как код» и «Инфраструктура как код».

Это очень нюанс. Сколько конфиг на env. Это переключается между выпусками? Должны ли эти состояния переключения поддерживать состояние, несмотря на двоичное развертывание. Для какого клиента, клиента, гостя или пользователя вы поддерживаете конфигурацию?

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

paul_h
источник