Мы разворачиваем ЛЭРС через контейнеры. При обновлении ЛЭРС Учет - тестируем новую версию с нашим окружением, затем разворачиваем ее в продакшене. (Базу данных для тестового окружения иногда создаем с нуля.)
Неудобство заключается в том, что при авторизации служб опроса в которых прописан токен - на сервере ему генерируется новый токен, а не назначается тот, что был прописан в настройках(LERS_POLLSERVICE_PollHost__Token).
Т.е. сейчас наша последовательность действий: запуск сервера и служб опроса с настроенными параметрами(в т.ч. токенами), авторизация подключаемых служб опроса, переназначение токенов добавленным службам опроса в соответствии с тем, что прописаны в их настройках.
Думаю, что логичнее было бы при авторизации служб опроса принимать тот токен, что прописан в настройках этой службы опроса.
Это совершенно нелогично. Ваше предложение делает бессмысленным процесс авторизации. Если Сервер будет принимать любой токен, который ему передает Служба опроса, то какой по вашему смысл в такой авторизации?
Сам Сервер не имеет доступа к настройкам Службы опроса и не должен его иметь.
Опишу процесс еще раз:
Мы заходим в службы опроса, видим список служб опроса, пытающихся авторизоваться. Производим авторизацию, появляется служба опроса, но она оказывается не “Подключена”, а через какое-то время с того же IP-адреса пытается подключиться “не авторизованная“ служба опроса.
Думаю, что это выглядит не логично.
Надо иметь ввиду, что в службах опроса мы вынуждены проставлять токены, т.к. сами службы могут автоматически разворачиваться на других серверах для достижения отказоустойчивости.
Если есть альтернативный алгоритм по автоматизированному тестированию (развертыванию тестового окружения и его автоматической настройке) - прошу его описать.
Просмотрели присланное видео. Идея стала более понятной. Получается, если токен задан в настройках Службы опроса, но при этом Сервер переводит ее при подключении в неавторизованные, то при ее авторизации вы хотели бы, чтобы Сервер учитывал переданный Службой опроса токен, а не генерировал новый?
Я пока цель не совсем ясно понимаю. Если вы задали на службах опроса токены через LERS_POLLSERVICE_PollHost__Token, то эти службы должны присутствовать в вашей тестовой БД с теми же токенами.
Если вы их авторизуете, то токен сервер сгенерирует и отправит службе. Она его сохранит и подключиться. Но если токен задан жёстко через LERS_POLLSERVICE_PollHost__Token, служба возьмёт именно его и попадёт в неавторизованные.
Я понимаю, что ситуация может вводить в заблуждение, но почему бы её не исключить одним из способов?
Первый - создать службы опроса с известными вам токенами в тестовой базе. Второй - убрать токены из конфигурационных файлов службы опроса и позволить принять их от сервера.
Первый вариант не всегда удобен - если тестируем установку ЛЭРС с нуля. (В CI/CD у нас прописано разворачивание и инициализация БД, разворачивание ЛЭРС-сервера и Poll-сервисов.) Теоретически можно инициировать добавление записей напрямую в БД через sql-скрипт, но это выглядит не очень, т.к. схема БД может измениться. Но вариант конечно рабочий - можно отказаться от от разворачивания с нуля, а использовать какой-то заранее снятый дамп.
Токены мы указываем вынужденно, т.к. при обновлении или при переносе на другой хост (например при отказе хостовой машины) у Poll-контейнера теряется его токен. Т.к. это происходит автоматически - терятся связь с сервером.
В целом, в идеологии CI/CD - авторизация Poll-контейнеров является скорее инфраструктурной настройкой нежели настройкой самого ПО и может быть правильнее в переменные окружения сервера добавлять разрешенные токены (по аналогии с БД - в контейнер СУБД задаются переменные окружения с создаваемыми паролями/пользователями, а в ПО передаются эти же пароли/пользователи для подключения к БД).
Ну это и есть фактический эрзац инициализации служб опроса.
Да, для этого мы и делали исходный алгоритм авторизации по токену, который можно задать в службе опроса вручную. Авторизация подключенных, но неавторизованных служб, появилась позже, как надстройка над токенами.
Я пока вижу, что идеальный вариант будет всё-таки создать службы опроса при развёртывании чистой БД. Мы можем продумать для этого удобные механизмы. Сходу приходит в голову:
В скрипте развёртывания с помощью curl вызвать REST API сервера и создать нужные службы. Открытого API для этого сейчас нет, но его можно продумать и реализовать.
У сервера есть интерфейс командной строки, и его можно расширить методом типа dotnet Lers.Server.dll cli AddPollService –Name имя_службы –Token токен_службы, вызов затем встроить в ваш ci/cd пайплайн. В отличие от REST методов, для этого не понадобится авторизация, что может быть проблемой в первом случае.
Тогда в 3.63 сделаем команду, которую можно будет использовать для создания службы опроса с заданным токеном. Только нужно помнить, что после вызова команды сервер ЛЭРС надо будет перезапустить, чтобы он увидел службы и позволил им подключаться.