Руководтсво администратора/разработчика

Документация

Начало работы

Обновление


Виды

Описание двух видов обновления и схема реализации

Существуют два вида обновленией: обновление сервисов и обновление данных.

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

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

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


Трансляция изменений

Изменения объектов могут быть включены в обновления для сторонних сервисов (если ваш сервер является источником обновления для другого сервиса). Для этого необходим выбрать пункт "Транслировать изменения" - "Включить". Таким образом, в случае запроса со стороны стороннего сервиса будут отправлены изменения данного объекта.


Настройка обновлений

Существует возможность настраивать обновление как для объектов, так и для шаблонов.

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

Если вы не хотите обновлять все объекты шаблона, вам необходимы выбрать пункт "Входящие обновления" - "Выключить (обновление вложенных объектов (для шаблона)".

В этих случаях при дальнейших обновлениях эти объекты (или все объекты шаблона) будут исключены из запроса на обновление.


Этап №1

Получение списка объектов, доступных для обновления

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

Обновление может быть инициализировано как вручную (через прямые запросы на Database Buildbox Service (далее DBS) сервера, так и через GUI-интерфейс Workplace Buildbox (далее WBS).

Схема представленная выше иллюстрирует этапность запросов между тремя сервисами.

1. WBS отправляет запрос на DBS c указанием последней метки ревизии.

2. DBS отправляет подобный запрос на сервис Updater DBS (Сервис, который указан в настройках проекти и с которого мы можем получать обновления. Обычно это или корневой сервис компании Buildbox, либо корневой сервис предприятия, от которого могут быть наследованы другие сервисы)

3. Updater DBS возвращаем массив данных, с указанием идентификаторов объектов, заголовков, сгруппированных по ид-шаблонов (для удобства вывода и сжатия данных при транзакции)

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

Обращаем внимание! Например, если объект "Иванов" не будут обновлен в рамках текущего обновления, то следующее обновление объекта возможно только если он будет изменен после текущего обновления.


Обновление сервисов

Как происходит взаимодействие сервисов между собой для обеспечения бесперебойного обновления сервисов

Платформа обеспечивает выполнение требованиям CI/CD для доставки обновления ПО сервисов на сервера кластера.

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

Итак, существует несколько сервисов, которые непрерывно взаимодействуют друг с другом, а именно:

  • Proxy (прокси-сервис - обеспечивает проксирование запросов для разных сервисов через одно/несколько доменных имен);
  • Loader (загрузчик) - сервис, которые работает на каждом их хостов и отвечает за запуск сервиса по команде Балансировщика;
  • Balancer (балансировщик) - сервис, который следит за состоянием кластера, обеспечивает гарантированное количество запущенных сервисов, распределяет нагрузку (количество запущенных сервисов) между нодами кластера, обеспечивает плавное обновление сервисов;
  • Registry (реестр сборок) - сервис, обеспечивающий сборку релизов сервисов и хранение и доступ к сборкам.
Balancer Loader Registry
1. Балансировщик получает задание на обновление сервиса    
  2. Загрузчик отправляет запрос на обновление на Реестр (присваивает номер запросу).  
  2-3 Загрузчик делает запросы в Реестр на статус выполения запроса на обновление. Статусы могут быть: ОК (обновление готово), NOT (для данного сервиса нет обновлений), FAIL (сборка новой версии вызвала ошибку) 3. Реестр делает запрос на git сервиса и вычитывает все коммиты по тегам. Сравнивает их с версиями уже собранных версий, и если есть коммиты (теги), сборок которых нет в реестре, то скачивает их и делает сборки (компилирует по все доступные платформы)
1-4. Балансировщик делает запросы в Загрузчик на получение статуса выполнения запроса. Статусы могут быть: ОК (обновление готово), NOT (для данного сервиса нет обновлений), FAIL (сборка новой версии вызвала ошибку)

4. Загрузчик инициирует процесс проверки на наличие новых релизов.

  1. запрос карты релизов
  2. сравнение с релизами в локальном хранилище
  3. скачивание и распаковка нового релиза
 

5. Балансировщик делает запрос о перезагрузки сервиса с указанием политики обновления:

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