Переносимые сервисы

Поведение модуля может быть расширено функциональными возможностями переносимых сервисов. Они позволяют добавлять в модуль инструкции по запуску и использованию собственных микросервисов.

Переносимый сервис содержит адрес развертываемого образа микросервиса, его внутренние настройки и настройки в кластере.

Добавление переносимого сервиса

Добавить в модуль переносимый сервис можно на вкладке Сервисы в управлении модулем. Тут же можно изменять или удалять уже существующие.

Настройки переносимого сервиса

  • Имя — отображаемое имя, которое будет видно в пользовательском интерфейсе.
  • Уникальное имя сервиса — имя, которое будет использовано в коде или скриптах для обращения к сервису. Задаётся один раз при создании, в дальнейшем изменение невозможно.
  • Адрес образа — URL-адрес образа docker. В случае, если образ расположен в Docker Hub, допускается короткое относительное именование. В случае, если образ требует аутентификации, нужно указать логин и токен учётных данных.
  • Порт HTTP — порт, через который будет происходить взаимодействие с микросервисом. По умолчанию указан порт 3000. При настройке следует ознакомиться с документацией микросервиса и определить, какой из портов следует выбрать.
  • Количество экземпляров — количество экземпляров микросервисов, которое будет поднято. При изменении количества следует учитывать, что ELMA365 сама по себе не поддерживает какую-либо репликацию сервисов. Если это не заложено непосредственно в сам микросервис, то в общем случае каждый из запущенных экземпляров не будет каким-либо образом связан с остальными.
  • Переменные окружения — позволяет конфигурировать переменные окружения образа микросервиса. В случае, если он допускает конфигурирование через переменные среды, этот инструмент можно использовать для настроек. Для определения наличия возможности такого конфигурирования следует ознакомиться с документацией микросервиса.

Переменные окружения можно не только задавать при разработке, но и предоставлять возможность их изменения конечным пользователем. Для этого при заполнении значения можно указать шаблон, подставив свойство модуля. Например, если мы хотим дать возможность пользователю устанавливать для микросервиса значение переменной окружения requesttimeout, то для начала мы создаём свойство в модуле, через которое пользователь будет указывать значение. Назовём его serviceTimeout. Далее заходим в переносимый сервис и добавляем переменную окружения requesttimeout и указываем в ней шаблон {$serviceTimeout}.

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

Liveness — дают доступ возможностям Kubernetes автоматически перезапустить микросервис в случае его неработоспособности. Возможность использовать Liveness-пробы зависит от микросервиса. Ознакомьтесь с его документацией, прежде чем принимать решение о включении Liveness-проб и выбора их типов.

Readliness — дают доступ возможностям Kubernetes не позволять подключаться к микросервису до его полной инициализации. Возможность использовать Readliness-пробы зависит от микросервиса. Ознакомьтесь с его документацией, прежде чем принимать решение о включении Readliness-проб и выбора их типов.

Начало внимание

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

Конец внимание

Включение-выключение микросервисов

При включении модуля будут запущены все добавленные в него микросервисы. При выключении модуля микросервисы будут остановлены и удалены.

Один и тот же образ микросервиса, развёрнутый из разных модулей в одной компании, будет иметь разные экземпляры микросервиса.

Один и тот же образ микросервиса, развёрнутый из одного модуля в разных компаниях, будет иметь разные экземпляры микросервиса.

Монитор микросервисов

Для отслеживания статуса микросервисов можно зайти на страницу модуля. Когда модуль включён, на ней будет представлен список микросервисов модуля и сводная информация.

В Мониторе отображается список всех микросервисов, заданных переносимыми сервисами. По ним предоставлены данные об образе, из которого поднимается контейнер, о количестве и текущем статусе набора реплик. При наличии возможностей кластера Kubernetes предоставлять метрики будут отображены данные о потреблении ресурсов.

Взаимодействие

Скрипты

Взаимодействовать с микросервисами можно через API, предоставляемого скриптами. Он доступен в серверных скриптах и только в модуле, к которому принадлежит микросервис, например, в виджетах или бизнес-процессах модуля. В клиентских скриптах доступа к микросервисам нет. Доступ к сервисам осуществляется через пространство имён Namespace.services. Если модуль не содержит переносимых сервисов, то это пространство имён будет отсутствовать в автокомплите скриптов.

Для взаимодействием с микросервисом следует использовать метод fetch.

Мы можем отправить простой GET-запрос без дополнительных параметров, указав в качестве параметра относительный путь до API микросервиса.

const res = await Namespace.services.vap.fetch("/SayHello");
if (res.ok) {
const resText = await res.text();
}

Для того, чтобы отправить другой тип запроса, указать параметры, задать заголовки и тело запроса, можно воспользоваться методом fetch, в качестве второго параметра которого передаётся FetchRequest.

const res = await Namespace.services.vap.fetch("/RememberMe", {
        method: 'POST',
        headers: {
            Authorization: 'myToken',
            },
        body: JSON.stringify({
            name: 'Ivan',
            age: 27,
        })
    } );

При написании скриптов может потребоваться проверять состояние микросервиса. Для этого можно воспользоваться методом status. Результатом будет перечисление ServiceStatus, несущее информацию о текущем статусе.

const info = await Namespace.services.vap.status();

Общение между двумя переносимыми сервисами

Если разработчик микросервиса предусмотрел возможность взаимодействия между двумя микросервисами внутри Модуля, то настроить путь доступа из Переносимого сервиса #1 к Переносимому сервису #2 можно через переменные окружения. Для этого нужно добавить в настройку Переносимого сервиса #1 переменную окружения с названием, указанным в документации микросервиса #1, и указать в ней шаблон имени Переносимого сервиса #2. Например, {$_srv_serv2}.

Экспорт и импорт

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