Всем привет!

Вопрос: а как вы подходите к конфигурации демонов и web приложений на perl ?
Передаете все в одном большо хэше или пишете функции для извлечения параметров ?

Контекст:
- система состоит из web приложения (скорее сервиса) и 5-6 демонов
- некоторые демоны могут иметь более одного запущенного экземпляра (настройки экземпляров могут отличаться)
- конфигурация явно разделяться на бизнес - конфигурацию и  техническую конфигурацию.
- необходимо валидировать конфигурацию


Вообщем хочу услышать ваши приемы, а еще лучше - ссылки на best practice

сетевые приложения на демонах?

Это сообщение отредактировал(а) gcc - 29.1.2009, 11:58

что ж.. топик не вызвал общественного резонанса.. жаль
тогда расскажу свое решение - надеюсь хотя бы критику услышать.

Итак:
1) Конфигурация хранится в XML файлах.  (mod_perl и log4perl - конечно в plain text). Для разбора используется XML::LibXML::Simple
2) Конфигурация разделяется на бизнес-конфиг (business.xml) и технические параметры (conf.xml)
3) Для каждого XML файла есть XSD схема - таким образом мы имеем довольно удобный механизм валидации конфигов (хотя и не идеальный..). Для валидации используем XML::LibXML::Schema
3) Конфигурация централизована, т.е.  нет специализированных конфигов для каждого демона, все кому нужен конфиг - используют модуль и далее ищут нужную информацию в большом дереве...

Бонусы такого решения:
1) на начальном этапе конфиг можно хранить как perl код, а XML и валидацию - прекрутить потом..
2) Надежность (XML + XSD - довольно хорошо отлавливают ошибки конфигурации)
3) Разделение на бизнес-конфиг и технический дает возможно отдать бизнес конфигурацию на редактирование левому человеку (веб-мастер) или потом написать независимую админку для генерации настроек

Недостатки:
1) После изменения конфига - нужно перезагружать приложение (пока не критично.. не гугл все таки =)
2) Сложно запустить два экземпляра одного демона с разными настройками.
3) Структура XML не так прозрачно отображается на perl - дерево (есть варианты..)

Ну что  ? у кого какие мысли ?
Или все используют Config::General ?
Или вся конфигурация в базе + админка ?

P.S.

ну они работают с сетью.. но это не сервера (скорее даже клиенты), просто демоны.

Это сообщение отредактировал(а) sir_nuf_nuf - 2.2.2009, 23:29

какой там резонанс этих хранителей конфигов до дуры!

JSON, YAML, INI, XML, General, Perl, tiny
все находяться Config::Any::

А почему не в базе? Я использую БД для работы с формализованными данными, если дерево не слишком сложное (а слишком сложное пытаюсь не создавать - незачем).
XML признаю только как мясо для XSLT.
XSD считаю лишней милицией.

Это сообщение отредактировал(а) tishaishii - 3.2.2009, 17:02

NuINu, перечитай вопрос. я не про формат храниения спрашивал.


tishaishii, хм а ORM  используешь ? меня запарит под конфиг заводить еще 6-8 таблиц и select к ним писать. Тем более, что завтра может поменяться "видение проекта" - и понадобится другой конфиг.

3 и 4 пункты это просто технические мелочи.

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

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

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


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

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




тоже думали... но вот в чем проблема - сама модель конфигурации сильно меняется.
т.е. конфиг - это не просто набор ключ - значение которые можно загрузить откуда-то, это сложная система объектов.

и по поводу В) - это конечно красиво.. по kill -HUP перезагружать конфигурацию без остановки демона... если бы вы еще сказали хороший способ как это реализовать ? потому как нужно полностью переинициализировать все компоненты демона с новыми параметрами.

для этого а) необходимо реализовать во всех объектах метод интерфеса - перезагрузка_конфигурации.
б) создать иерархическую систему этих компонентов. типа дерева.

с) соответсвенно по kill hup вызывать (или выставлять признак) этот метод для корневого объекта.

все остальное реализуется в конкретных объектах...

ну уж сами думайте 

как то давно прочитал: сколько нужно программистов ООП чтобы вверуть лампочку?
ни одного, гласил ответ...
нужна комнда у лампочки->ввернись.