Создание / управление файлами конфигурации для размещенного приложения

Изменить - я начинаю изучать Perl Template-Toolkit. Кажется, это хорошо подходит для решения проблемы, описанной ниже. Кто-нибудь с ним играл? Любой (подробный) совет?

Я задал вопрос об управлении конфигурацией и не получил ответа. Возможно, мой вопрос был слишком расплывчатым, поэтому перейдем к медным гвоздям. Вот процесс, которому мы следуем при подключении нового экземпляра клиента к нашему размещенному приложению: как бы вы с этим справились? Я склоняюсь к сценарию Perl для заполнения шаблонов для создания сценариев оболочки, файлов конфигурации, файлов конфигурации XML и т. Д. Если кратко взглянуть на CFengine и Chef, кажется, что они не собираются сокращать объем работы, потому что я ' d по-прежнему придется вручную указывать все изменения / правки в инструменте. Похоже, что это не большая выгода от прямого прикосновения к файлам конфигурации.

1. Мы добавляем раздел в основной файл конфигурации для основного (стороннего) приложения. Эта строфа имеет значения, которые
   • определяет имя экземпляра (клиента)
   • порт прослушивателя TCP для этого экземпляра (в настоящее время не используется)
   • имя базы данных DB2 (серийный числовой идентификатор, уже существует, они предварительно подготовлены для нас администраторами баз данных)
   • три файла подконфигурации, по имени - они должны быть созданы из 3 шаблонов и названы в честь экземпляра
2. Файлы подконфигурации определяют:
   • Путь к файлу для томов DB2
   • Путь к файлу для хранения объектов
   • Путь к файлу только для одного из томов DB2 (да, избыточный для первого элемента.
3. Запускаем несколько команд приложения, запускаем экземпляр
4. Мы делаем кое-что с LDAP (делаем OU для экземпляра и т. Д.)
5. Мы добавляем раздел в файл конфигурации для нашего прослушивателя безопасности, который действует как сквозной переход к LDAP.
   • имя экземпляра
   • LDAP OU
   • TCP порт например
   • Имя базы данных DB2
6. Мы перезапускаем прослушиватель безопасности (в нерабочее время), меняем основной файл конфигурации с пункта 1, останавливаем и перезапускаем экземпляр. Теперь он аутентифицируется через LDAP.
7. Мы добавляем команды остановки и запуска для этого экземпляра в сценарии аварийного переключения HA.
8. Мы импортируем файл конфигурации XML в экземпляр, который определяет вещи для фактического приложения для клиента - имена пользователей, группы, разрешения и бизнес-правила. XML предоставляется группой внедрения.

Теперь мы настраиваем приложение загрузки данных.

6. Мы добавляем раздел к существующему файлу конфигурации верхнего уровня, который указывает на новый файл конфигурации уровня клиента. Новый файл конфигурации уровня клиента включает:
   • имя экземпляра (клиента)
   • имя базы данных DB2
   • произвольное количество файлов подконфигурации, по имени
7. Каждый из файлов подконфигурации определяет:
   • пути к каталогам для загрузки, обратной связи, резервного копирования и сбоя
   • эти пути к файлам имеют общий путь к папке, зависящей от клиента, а затем по одной папке для каждого файла подконфигурации
8. Необходимо создать каждый из этих файловых путей.
9. Нам нужно добавить этот экземпляр клиента в наши сценарии мониторинга, которые подтверждают, что правильные процессы запущены и в которые можно войти. Конечно, эти файлы конфигурации мониторинга включают имя экземпляра, порт TCP, имя базы данных DB2 и т. Д.
10. Также есть приложение для создания отчетов, которое необходимо настроить для нового экземпляра. Вы уловили идею.
11. Также существует XML, который загружается в WAS командой промежуточного программного обеспечения. Мы даем им значения для подключения к XML - они могут очень легко передать нам шаблон, и мы могли бы вернуть им завершенный XML.