Работа с конфигурацией Платформы

Реализовано 3 способа проверки и применения конфигурации Платформы:

  • для проверки конфигурации (не)сохраненной функции (check функции);

  • для проверки сохраненной, но еще не примененной конфигурации (check кластера);

  • для проверки с применением конфигурации (apply кластера).

При запуске этих операций выполняется проверка успешности компиляции библиотек, необходимых для работы сервисов. При многократном запуске операций их выполнение помещается в независимые очереди.

Генерируются и компилируются следующие библиотеки:

  • Библиотека типов.

  • Типы данных.

  • Метаданные.

  • Перечисления.

  • Интерфейсы.

  • Группы.

  • Дополнительные служебные функции и расширения.

  • Пользовательские методы.

  • Определение функции.

  • Входящий/исходящий трансформаторы.

  • Библиотека функций.

  • Процессы.

  • Алгоритмы.

  • Библиотека маппинга для процессов.

  • Шаги Установка переменных.

  • Шаги Запуск БП.

  • Настройки маппинга в шагах процессов (вкладки Локальные переменные, После выполнения).

  • Библиотека маппинга для каждого сервиса UI.

  • Библиотеки обработчиков - для каждой активной системы (кроме 1С) создается своя библиотека с кодом обработчиков, привязанных к этой системе.

Проверка процессов и алгоритмов

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

Проверка включает в себя общую проверку конфигурации, а также текущих трансформаций и процессов.

Проверка запускается в редакторах процессов и алгоритмов. При этом компилируется библиотека и возвращается результат компиляции. Библиотека типов компилируется только если были изменения в ее объектах. Проверять можно как сохраненные, так и не сохраненные процессы.

../_images/image54.png

При выполнении функции check:

  • В ЦН появляется запись о результате проверки в разделе Обслуживание ‣ Управление конфигурацией.

  • В логах сервера ЦН в зависимости от успешности проверки:

    • При успешной проверке: сообщение о сохранении временной dll с идентификатором.

      ../_images/image610.png

    • При неуспешной проверке: сообщение о допущенной в функции ошибке с указанием места ошибки.

      ../_images/image75.png

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

Проверка конфигурации

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

../_images/image10.png

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

  • В ЦН отображается всплывающее окно и запись в разделе Управление конфигурацией с результатом проверки:

    • При успешной проверке: Проверка конфигурации прошла успешно!.

    • При неуспешной проверке в тексте ошибки перечислены причины.

  • В логах сервера ЦН в зависимости от успешности проверки:

    • При успешной проверке и совпадении контрольной суммы с текущей контрольной суммой выводится сообщение Проверка конфигурации кластера [идентификатор кластера].

      ../_images/image11.png

    • При успешной проверке и несовпадении контрольной суммы в процессе проверки происходит сохранение dll конфигурации. Начало проверки - Проверка конфигурации кластера [идентификатор кластера]. Окончание проверки - Выполнена проверка конфигурации кластера [идентификатор кластера].

    • при неуспешной проверке в логах сообщения выводится сообщение о допущенной в функции ошибке с указанием места ошибки.

      ../_images/image12.png
      ../_images/image1310.png

  • При выполнении действия check из очереди учитываются сохраненные изменения, т.е. действие из очереди выполняется на той конфигурации, которая актуальна на момент начала выполнения, а не на момент вызова этой операции.

Применение конфигурации (Apply)

Для применения текущей конфигурации используется кнопка Применить конфигурацию.

При применении конфигурации производятся следующие действия:

  • В журнале ЦН в момент запуска применения конфигурации логируется инициатор запуска и текущая версия конфигурации:

    Запуск применения конфигурации. Запущено пользователем: [пользователь]. Версия до применения конфигурации: [номер версии]. Номер версии будет увеличен при применении.

  • В логах сервера управления в зависимости от успешности проверки.

    • При успешной проверке и совпадении контрольной суммы происходит проверка, применена ли конфигурация, и выводится сообщение с актуальной версией. Если не применена - применяется.

    • Начало применения: Применение нового состояния метаданных для кластера [идентификатор кластера].

    • Регистрация конфигурации на применение: Обновление актуальной конфигурации в хранилище.

    • Завершение проверки конфигурации на применение и ее сохранение: Обновление актуальной конфигурации в хранилище завершено успешно.

      ../_images/image15.png

    • Окончание действия apply: Настройки репликации Центра настройки успешно применены. Версия [номер версии].

    • При успешной проверке и несовпадении контрольной суммы происходит сохранение dll конфигурации и применение конфигурации. Начальное и конечное сообщение в логах как в прошлом пункте.

    • При неуспешной проверке выводится сообщение начала действия apply, сообщения о сохранении dll конфигурации и об ошибке.

  • В логах узла присутствуют записи только об успешных конфигурациях.

    • При совпадении версии с предыдущей. действия apply: Поступило ping сообщение от ControlServer.

      ../_images/image16.png

    • Окончание действия apply: Применение конфигурации сети, версия [номер версии].

    • При несовпадении версии с предыдущей происходит запуск необходимых компонентов.

  • В ЦН запись об успешном применении появляется в момент передачи стабильной конфигурации на применение в Node. Это значит, что конфигурация скомпилирована, но еще не применена на узлах. В ЦН появляется всплывающее окно и запись в разделе Обслуживание с результатом проверки:

    • При успешной проверке: Применение конфигурации прошло успешно!.

    • При неуспешной проверке в тексте ошибки перечислены причины.

    В Журнале действий пользователя (при использовании Guard - в журнале Guard) сохраняется применение стабильной конфигурации для кластера и центров настройки (настройки репликации).

    ../_images/image17.png

  • ЦН отправляет на координатор команду на применение конфигурации (координатор должен сформировать новую версию конфигурации и распространить её на все серверы кластера). Получив такую команду, координатор проверяет, есть ли в его кеше информация о сервере, который отправил эту команду (является ли этот сервер членом кластера). Проверяется имя и ip-адрес сервера, отправившего команду на применение конфигурации. Если в кеше координатора найдены серверы кластера с таким именем или ip-адресом (в ЦН соответствует значению в поле Адрес на странице сервера), координатор примет эту команду. Если основная проверка не пройдена, координатор дополнительно запросит у DNS-серверов значение ip-адресов для имён серверов кластера, которые находятся в его кеше, и сравнит с ip-адресом сервера, отправившего команду на применение конфигурации. Если все проверки не пройдены, координатор отклонит команду на применение конфигурации и вернёт ошибку с текстом, аналогичным ошибке ниже:

    Ошибка обработки запроса MessageId = 881b711d-fd75-41e5-8435-196515fe8388[00000000-0000-0000-0000-000000000000],
ProcessId = 00000000-0000-0000-0000-000000000000: Код 400: [Некорректное сообщение] Сервером srv-dt-dev01 отклонено сообщение, полученное от Центра управления (srv-test01).
В списке зарегистрированных Центров настроек на сервере srv-dt-dev01 отсутствует адрес сервера Центра настроек 192.168.101.14.
Необходимо выполнить регистрацию Центра настроек с адресом 192.168.101.14 на сервере srv-dt-dev01 с помощью команды setCS

Если предыдущая компиляция еще не завершена, при многократном запуске apply конфигурация нового применения отличается от выполняемой в данный момент. При этом происходит отмена предыдущей компиляции и начинается компиляция по последнему запуску проверки.

Сценарий

Пользователь, применивший конфигурацию в 00:01

Конфигурация изменилась

Пользователь, применивший конфигурацию в 00:02

Ответ 1

Ответ 2

1

А

Нет

А

202 в 00:02

200

2

А

Нет

Б

200 в 00:03

200

3

А

Да

А

202 в 00:02

200

4

А

Да

Б

200 + ошибка в 00:02

200

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

Устранение ошибок обновления

Откат на предыдущую версию конфигурации

В ЦН возможен откат на примененную ранее конфигурацию с помощью метода post/api/{clusterId}/metadata/restoreStable. При этом все сохраненные и непримененные изменения будут удалены.

Внимание

Откат выполняется на версию, которая была применена в последний раз, а не фактическую конфигурацию кластера.

Рассинхронизация версий

При получении команды на обновление от ЦН кластер выполняет сравнение версий конфигурации. Если текущая конфигурация более новая, сервер-координатор отклоняет обновление и передает в ЦН номер его версии. Для установки более старой версии на кластер предусмотрен метод /api{clusterId}/metadata/apply с параметром versionBefore с указанием номера версии кластера, которую необходимо заместить.

Обновление от неизвестного Центра настроек

При получении команды обновления от ЦН кластер проверяет получена ли команда от текущего хоста, где находится сам координатор. Если команда получена с другого сервера, то выполняется проверка вхождения этого хоста в список известных серверов. Если команда получена от сервера, который не входит в кластер и там не зарегистрирован ЦН для данного кластера, то координатор отклоняет обновление. Для регистрации нового ЦН необходимо выполнить команду на хосте координатора с указанием адреса ЦН:

  • Для Windows:

    DatareonPlatformService.exe SetCS <ip adress>

  • Для Linux:

    sudo /usr/bin/datareon/platform/DatareonPlatformService setCS <ip adress>

После выполнения команды требуется отправить обновление повторно.