Microservice Starter (msvc)

Описание

Обеспечивает подъем пользовательских/проектных микросервисов (внешние процессы). Состав микросервисов домена определяется классом сущностей доменного центра `mservices`. Процессы поднимаются там же в docker-контейнере, где работает и сама платформа. Под каждый микросервис в рабочем каталоге ноды создается отдельная папка, куда распаковывается содержимое архива, и который становится рабочим каталогом.

В соответствии с настройками сущности `mservice` производит подъем сервиса в режиме active-passive или active-active. На всех сайтах, или на конкретных.

Поднятие процесса происходит с указанием в качестве рабочей папки той, в которую распакован архив. Это путь "/var/lib/era/_workdir/<NODE>/mservices/<DOMAIN>/<ENTITY_NAME>". Одновременно с поднятием формируется файл `/var/lib/era/_workdir/<NODE>/mservices/<DOMAIN>/<ENTITY_NAME>.pid` в котором лежит активный пид процесса операционной системы.
Если падает процесс - его сразу же переподнимает генсервер управления портом, обновляет данные в pid-файле.
Если падает генсервер управления портом, процесс убивается заряженным мониторингом, а генсервер сразу же переподнимается супервизором домена.
Если удаляется домен, то мониторинг тормозит процесс.
Если закрывается нода, то она успевает тормознуть дочерние процессы.
Если рушится нода, то при следующем запуске домена он на основе pid-файлов подчистит лишние процессы. Если процессов нет, а файлы есть - он попытается прибить процесс по идентификатору. Команда запуска не сверяется.
Если изменяется соответствующая сущность `mservice`, то не позже чем через 1 секунду начинается процесс синхронизации микросервисов домена. Процесс синхронизации запускается каждые 60-65 секунд даже без наличия изменений.
Если во время попытки запустить процессы происходит какой-то крэш - повторная попытка домена синхронизировать - через 10 секунд.
Если синхронизация завершается с ошибкой - повторная попытка домена синхронизировать микросервисы - через 10-15 секунд.
Если синхронизация завершается пропуском какой то части микросервисов (архив не успел скачаться, не обнаружен, чексуммы не совпадают) - повторная попытка домена синхронизировать микросервисы - через 20-25 секунд.
При ошибках часть микросервисов могла успеть запуститься, часть не успеть, поэтому перед стартом принудительно вызывается остановка.
+ Вновь созданные сущности проходят процедуру фильтра по сайту, подготовки данных, поиска и распаковки архива вложения, и запуска соответствующего настройкам сущности процесса обслуживания.
Удаленные сущности останавливаются, процесс завершается, pid-файл удаляется, данные из каталога с распакованным архивом удаляются.
+ При синхронизации измененной считается сущность, в которой произведено любое изменение любого поля, за исключением поля `ext`.
Загрузка нового архива во вложение тоже считается изменением сущности, поскольку мета-данные файла прописываются в поле `opts.attachment_info`.
Измененные сущности вызывают остановку процесса микросервиса (`kill`, без очистки каталога с распакованным архивом) и последующий его запуск вновь.
Всякий раз при запуске/перезапуске производится проверка наличия вложения zip-архива у сущности. Если команда unzip не может его распаковать - такое вложение считается битым, сущность исключается из загружаемых.
Если архива к сущности не привязано (пустой объект в поле `opts.attachment_info`) - сущность анализируется.
Если архив к сущности привязан, но еще отсутствует на ноде - сущность удаляется из списка активных до следующей итерации синхронизации (не позднее чем через 20 секунд).
Если архив к сущности привязан, но его данные не совпадают с информацией о вложении в сущности - сущность удаляется из списка активных до следующей итерации синхронизации (не позднее чем через 20 секунд).
Если архив к сущности не изменен (его данные совпадают с информацией в файле `/var/lib/era/_workdir/<NODE>/mservices/<DOMAIN>/<ENTITY_NAME>.archive-info.json`), то повторной распаковки не производится (даже если каталог вручную испорчен).
Если архив к сущности изменен (его данные отличаются с информацией об уже распакованном архиве) - каталог сервиса удаляется, и архив распаковывается заново, создается файл `*.archive-info.json`
Если архив к сущности удален, то сущность удаляется из списка активных до следующей итерации синхронизации, завершаются процессы, чистится каталог микросервиса.
+ Нетронутые сущности продолжают выполняться без остановок.
+ Процесс микросервиса сам должен формировать полный URL доступа. Выбирать протокол подключения и способ авторизации. Авторизовать подключение под токеном канала интеграции, либо под системным пользователем. Эти параметры должны быть переданы ему в `cmdline` / `cmdparam` сущности `mservice`.

Table 1. Системные характеристики

Код

msvc

Режим работы

Сервис

Режим резервирования

Active-Active

Типы сайтов

Любые

Слой

Бизнес-логика

Размещение

Внутренний

Сохранение и восстановление состояния при перезагрузке

-

Приложение

era_msvc

Управляемое приложение

Определяется элементами коллекции mservices

Ограничения

  • .

Параметры

Table 2. Параметры
Имя Тип Умолчание Описание

name

str

required

Имя. Может состоять из латинских букв и цифр, должно начинаться с буквы.

roletype

str

required

Тип роли. Возможные значения: "msvc".

iface

str

required

Алиас сетевого интерфейса сервера, на котором будет происходить внутреннее взаимодействие ролей между собой.

ext

json

empty

Дополнительные опции роли. Содержит json объект или список.

enabled

bool

empty

Флаг активности роли. При установке в false роль не участвует в валидации и не запускается.

roleid

int

required

Идентификатор роли. Уникален для всей системы, независимо от сайта или сервера.
Нельзя изменить после присвоения. Целое число от 1 до 9999

separate

bool

required

Признак выделения роли в отдельную ноду.

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

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

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

Пример узла
{
  "name": "msvc1",
  "roletype": "msvc",
  "iface": "eth0",

  "roleid": 11320,
  "separate": true
}