Шаг 4. Изменение конфигурации

Нужно провести изменения в конфигурации, например добавить сервер, перераспределить роли, или изменить их параметры. Казалось бы, чего же проще – разложить новый файл конфигурации по всем серверам и перезапустить систему. Далее ServerShell все сделает, как на этапе загрузки (шага 3). Можно даже не перезапускать, рассчитывая на то, что ServerShell регулярно отслеживает изменения файловой системы. Однако в таком подходе есть три существенных недостатка:

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

Решению этого кейса служит набор ролей, совместно отвечающих за конфигурацию: MIC (Master Infrastructure Configurator) и IC (Site Infrastructure Configurator).

Для начала, по аналогии с шагом 1, загружаемый администратором файл конфигурации попадает через WS на MIC. Там он сохраняется и ожидает дальнейших активностей администратора. Администратор проверяет корректность загруженного файла, валидацию проводит та же роль MIC. Затем, если все успешно, администратор применяет файл API-запросом /api/admin/v1/cfg/apply. MIC инициирует сложный процесс синхронизации файла конфигурации на всех сайтах, серверах и нодах. Этот процесс доходит до каждой работающей роли, чтобы та имела возможность применить новые настройки по-горячему.

Применение конфигурации – древовидно разветвляемый процесс.

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

MIC и IC такие же роли, как и остальные, а значит их базовое поведение подчинено своим локальным ServerShell и BasedRole. А целевая функциональность держит их на вершине иерархии процесса управления конфигурацией. (см.рис.выше). Это две точки зрения на связь конфигурационных сервисов, два уровня связи: С точки зрения процесса подписки и обновления конфигурации главный MIC, и далее MIC → IC → ServerShell → BasedRole, а с точки зрения запуска системы главный ServerShell, и далее ServerShell → BasedRole → Role, в том числе MIC и IC. Адекватно нарисовать плоскую компактную диаграмму, отражающую одновременно обе точки зрения, нетривиально, но абстрактно представить эту модель более чем реально:

ServerShell запускает BasedRole, BasedRole запускает среди прочих ролей MIC, тот начинает работать и обеспечивать функционал управления конфигурацией. Аналогично IC на своем сервере. Если вдруг конфигурация меняется, MIC оповещает все доступные IC, IC оповещает все доступные ServerShell на сайте (в том числе и свой собственный), ServerShell управляет рабочими нодами и оповещает BasedRole (в том числе на ноде MIC). После этого роль MIC может изменить свое расположение и поведение. Пока IC не запущен как роль, все ServerShell осуществляют неудачные попытки подключиться к нему исходя из текущей конфигурации. Эти попытки асинхронны и не мешают осуществить целевой процесс запуска рабочих нод и ролей в них.

Еще одна диаграмма…​

MIC – особенная роль, она должна присутствовать ровно на одном сайте. Сайт, на котором располагается MIC, называется мастер-сайтом. И с другой стороны, если сайт является мастер-сайтом, то на нём должен присутствовать MIC. Другие сайты называются рабочими сайтами. При этом если сайт (неважно рабочий или мастер) обладает всем составом необходимых ролей, то он называется коммуникационным. Таким образом коммуникационный сайт – это признак продуктовой полнофункциональности сайта. Любой рабочий сайт обязан быть коммуникационным.

На диаграмме приведена иерархия подписки на изменения конфигурации на примере двоично-разветвляемого дерева (два сайта, по два сервера, по две роли):

В нижнем слое компонентов диаграммы располагаются BasedRole, но мы помним, что те в свою очередь управляют рабочими нодами с функциональными ролями. Так, один из приведенных на диаграмме BasedRole управляет запуском ноды с ролью MIC, а еще два управляют запуском нод с ролями IC. Следует тщательно обдумать эту модель, прежде чем переходить дальше.