Централизованная конфигурация Windows для сторонних приложений?

Question

Мы смотрим на стандартный способ настройки различных «конечных точек» нашего приложения. Наше приложение представляет собой распределенную систему с приложениями для рабочего стола Windows, «службами» Windows Server и базами данных. В настоящее время мы настраиваем каждую часть, используя файлы XML. Это немного выходит из-под контроля, поскольку мы работаем с более крупными клиентами, которые могут иметь десятки серверов, на которых работает наше приложение, и сотни настольных клиентов.

Может ли кто-нибудь порекомендовать технологию Microsoft или стороннюю компанию, которая позволит нам централизовать всю эту информацию о конфигурации и управлять ею в одном месте для всех наших приложений? Любые изменения будут «проталкиваться» в конечную (ые) точку (и), которая заинтересована.

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

Нашей основной деятельностью является не «Службы централизованной конфигурации». Мы являемся ГИС-компанией, которая предоставляет решения для различных коммунальных предприятий по всему миру.

Answer 1

Я сделал несколько вещей, чтобы дать себе эту функциональность на протяжении многих лет. Я создаю корпоративные приложения, которые могут быть распределены по многим серверам. Я не хочу скрывать настройки конфигурации в каждом файле конфигурации служб или в файле web.config каждого веб-сервера. Для конкретного приложения я обычно создаю таблицу настроек приложения в базе данных приложения. В таблице только два поля. SettingName и SettingValue. Затем я пишу веб- или wcf-сервис, единственной функцией которого является получение этих настроек. Я пишу функцию GetSetting, где вы передаете «SettingName», и она возвращает SettingValue или пустую строку, если ваш параметр не найден. Таким образом, я могу хранить все настройки приложения для всех компонентов приложения в одном месте. Обслуживание и устранение неисправностей для этого действительно просто, я не собираюсь разбираться с огромным количеством конфигурационных файлов, разбросанных по дюжине веб-серверов и серверов приложений.

Для более масштабных приложений я мог бы создать отдельную базу данных AppSettings, где я добавлю новое поле в мою таблицу, упомянутую выше. Имя приложения. Мой web или wcf сервис для этого подхода имеет такой же вызов метода (GetSetting) только в этой области, я передаю ApplicationName и SettingName и возвращает SettingValue или пустую строку.

Выполнение любого из этих действий позволяет централизовать все настройки приложения для приложения любого размера или магазина ИТ. Это сработало очень хорошо для нас.

Answer 2

Вы можете использовать RSS вместе с BitTorrent для распространения изменений. См. Википедия . Однако это не зависит от MS, но должно обеспечить необходимую гибкость - сервер конфигурации, содержащий конфигурацию и предоставляющий каналы, необходимые для настройки клиентов и, возможно, серверов.

Answer 3

Есть ли VCS через защищенный канал?

Например, git через ssh (оба доступны в cygwin).

Я думаю, что первым шагом является создание защищенного канала (если вам нужна способность к толканию, подтягивание может быть другим).

Что касается управления "версиями" в разных "ветках", что лучше системы контроля версий?

Что касается требований Microsoft, то хорошо, что программное обеспечение Microsoft, существующее в этой области, будет плохо сосать в вашем случае (как не лучший инструмент для работы).