Через RasHub клиенты RasEcosystem получают данные о кластерах и информационных базах 1С и выполняют команды администрирования.
Клиент можно подключить и напрямую к RasGate. Но тогда ему придётся знать синтаксис rac, учитывать различия между версиями платформы, разбирать консольный вывод и собирать данные от нескольких Gate. И всё это придётся повторять в каждом новом клиенте.
Эту работу я вынес в Hub. RasGate получает готовую команду, а клиенты работают с единым API и общей моделью данных.
Место RasHub в RasEcosystem
RasHub находится между клиентами и RasGate. У каждого компонента своя задача:
- клиент отвечает за пользовательский сценарий и интерфейс;
- RasHub хранит данные об инфраструктуре, формирует команды под версию
racи разбирает результат; - RasGate запускает
racс готовыми аргументами и возвращает результат процесса; - RAS выполняет административную операцию над кластером 1С.
racrac → RAS → кластер 1Сrac. Решение о повторе команды после ошибки тоже остаётся за Hub. Здесь уже нужно понимать, что команда делает с кластером или базой: повторное чтение и повторное изменение данных могут иметь разные последствия.
RasGate и подключение к RAS
В Hub отдельно настраиваются RasGate и подключения к RAS.
Для RasGate указываются адрес сервиса и API-ключ. Hub хранит результаты последних проверок Gate; его использование можно включить или отключить в настройках.
Подключение к RAS — запись о конкретном сервере администрирования 1С: название подключения, адрес сервера и порт. В проекте оно называется RAS endpoint. Для каждого подключения выбирается RasGate, через который Hub выполняет команды. Один Gate может работать с несколькими доступными ему RAS.
Путь к исполняемому файлу rac задаётся в самом Gate. В Hub для подключения указывается адрес RAS, к которому должна обратиться эта утилита. Этот адрес Hub передаёт среди аргументов каждой команды.
Если выбранный Gate недоступен, Hub не переключается на другой автоматически. Другой Gate нужно назначить в настройках подключения.
Как проходит запрос
Допустим, клиенту нужен свежий список кластеров конкретного RAS. Hub находит подключение и назначенный ему Gate, проверяет, что оба включены в настройках. Затем:
- Hub определяет версию
rac, настроенного в Gate. - Выбирает подходящий для этой версии вариант команды.
- Hub формирует аргументы и добавляет адрес RAS.
- RasGate запускает
racи возвращает результат выполнения. - Hub проверяет результат, разбирает вывод и приводит его к общей модели.
- Если данные полные и настройки за время запроса не изменились, Hub сохраняет их в локальную копию.
За время запроса настройки могут измениться. Например, администратор поменял адрес RAS, а Hub всё ещё ждёт ответ от прежнего сервера. Сохранять его как данные сервера с новым адресом нельзя. То же касается смены Gate или отключения одного из компонентов.
Перед вызовом Hub запоминает настройки подключения и Gate, а перед сохранением сверяет их с текущими. Если они изменились, ответ не заменяет локальную копию.
Зачем Hub хранит локальную копию
Если при каждом открытии экрана обращаться через Gate к RAS, интерфейсу придётся ждать ответа всей цепочки. Если она недоступна, получить данные не выйдет. Для поиска сразу по нескольким подключениям и кластерам это особенно неудобно.
Поэтому для навигации и поиска я использую локальную копию. Hub сохраняет у себя данные о кластерах и информационных базах вместе со временем их получения.
Но копия может устареть. Когда нужно проверить состояние конкретного кластера или базы, клиент может запросить свежие данные из RAS. В API эти два способа чтения называются shadow и live:
| Запрос к локальной копии | Запрос к RAS |
|---|---|
|
|
Если Hub получает полный список, он может убрать из локальной копии объекты, которых больше нет в RAS. При обновлении одного кластера или базы соседние объекты не затрагиваются. Перед сохранением Hub проверяет, что ответ разобран полностью и соответствует запросу.
Совместимость версий rac
В разных версиях платформы могут отличаться команды rac, их параметры и формат вывода. Gate сообщает версию настроенной утилиты, а Hub подбирает команды и разбирает ответы с учётом этой версии.
Например, если изменился формат списка кластеров, его разбор нужно добавить в Hub. Клиент продолжает получать ту же модель кластера, без разбора нового формата на своей стороне.
Если Hub не знает, как работать с обнаруженной версией, или ответ не проходит проверку, операция завершается ошибкой. Частично разобранные данные в локальную копию не попадают.
Когда результат операции неизвестен
Если при чтении данных оборвалось соединение, запрос часто можно повторить. Но когда команда меняет состояние RAS, такой повтор может выполнить одну операцию дважды.
RasHub может отправить команду и не получить ответ от Gate. Либо сам Gate вернёт состояние unknown — результат неизвестен. В обоих случаях RAS мог уже выполнить команду.
Если результат неизвестен, RasHub не повторяет команду изменения автоматически. Потеря ответа ещё не означает, что операция не выполнилась.
Для обновления локальной копии Hub нужен подтверждённый результат команды. Если операция требует повторного чтения, Hub заново получает данные из RAS. При неизвестном результате прежняя копия сохраняется.
Бывает и другая ситуация: изменение в RAS подтверждено, но Hub не смог заново прочитать данные или сохранить их у себя. Клиент получит ошибку, хотя сама команда уже выполнена. Здесь сначала нужно проверить состояние в RAS и обновить локальную копию, а уже потом решать, нужна ли ещё одна команда.
Очереди запросов и фоновых проверок
Запросы к RAS и проверки Gate выполняются как задачи. Запросы, ответа на которые ждёт клиент, и фоновые проверки идут в разные очереди. Hub может обрабатывать их параллельно.
Внутри одного подключения к RAS задачи выполняются по очереди, чтобы не мешать друг другу при обновлении данных. Если нужное обновление уже идёт, новый запрос может дождаться его результата без ещё одного обращения к RAS.
Проверка состояния RasGate
RasHub периодически проверяет все активные Gate. Сначала он получает состояние самого сервиса, затем отдельно проверяет доступность rac и его версию.
Сам Gate может отвечать по сети, а настроенный в нём rac — не запускаться. Поэтому у этих проверок отдельные результаты и время выполнения: по одному статусу Gate такую проблему не заметить.
Доступность Gate ещё ничего не говорит о свежести списка кластеров и баз. Для его обновления нужен отдельный запрос к RAS.
API, интерфейс и доступ
У RasHub есть HTTP API с разделением по версиям. Через него клиенты получают список подключений, ищут кластеры и базы, запрашивают свежие данные и выполняют поддерживаемые команды администрирования.
Для настройки самого Hub есть веб-интерфейс. В нём можно проверить подключения, посмотреть состояние сервиса и ошибки в его работе.
Клиент обращается к API с ключом пользователя. Перед выполнением команд администрирования Hub дополнительно проверяет права этого пользователя.
Ключи доступа к RasGate хранятся в защищённом виде. Логин и пароль администратора кластера или агента, переданные для отдельной команды, Hub использует только при её выполнении. Эти данные не сохраняются в базе и не попадают в журналы, сообщения об ошибках или ответы клиенту.
Ограничения
RasHub работает с теми командами rac, для которых умеет подготовить аргументы и проверить результат. Добавить произвольную команду в клиент недостаточно: её поддержку нужно реализовать в Hub.
При изменении формата команды или ответа rac может потребоваться обновление Hub. Для работы с RAS нужны доступный Gate, совместимый rac и доступный сервер администрирования.