Аннотация

Документ описывает архитектуру серверной части Платформы ROBIN (далее - Изделие).

Общие сведения

Назначение изделия

Платформа ROBIN представляет собой комплекс программных средств, предназначенных для решения задач в области роботизации бизнес-процессов, а именно:

  • осуществлять разработку новых программных роботов и действий,
  • выполнять сценарии готовых программных роботов для решения задач Предприятия Заказчика.

Серверная часть Платформы ROBIN представляет собой набор программных серверных компонент, располагающихся в зависимости от исполнения на одном или нескольких физических серверах как с образованием кластеров так и без образования кластеров.

Серверные компоненты Платформы ROBIN реализуют следующий функционал:

  • хранение информации о пользователях и правах доступа пользователей:к клиентским приложениям, к артефактам роботов и действий;
  • хранение артефактов роботов, включая исходники роботов, действий и документации по действиям;
  • хранение логов с оперативной информацией о запусках и остановах роботов;
  • хранение логов серверов приложений;
  • аутентификация клиентских приложений,
  • аутентификация и авторизация пользователей в процессе их работы с приложениями;
  • публикацию новых роботов и действий - сохранение их в хранилище роботов;
  • транспорт сообщений (логов) с оперативной информации о состоянии роботов и агентов в хранилище логов;
  • транспорт сообщений (команд управления) между консолью RMC и прикладными службами систем исполнения роботов;
  • управление запусками роботов по расписанию или по требованию оператора;
  • обеспечение безопасной передачи данных через очереди программного брокера сообщений.

Исполнение изделия

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

  • demo - все серверные компоненты размещаются на одном сервере,
  • бескластерное исполнение - все серверные компоненты разворачиваются на отдельных серверах без образования кластеров,
  • кластерное исполнение - в этой конфигурации каждый серверный компонент может быть развернут в кластере для обеспечения отказоустойчивости и возможности дальнейшего масштабирования системы.

Требования к программному обеспечению

Требования к общесистемному программному обеспечению

Для обеспечения работы серверных компонент Платформы ROBIN на серверах должно быть установлено следующее общесистемное программное обеспечение (ОПО) - всё ПО с открытым кодом:

  • операционные системы (ОС) - одна из:
  1. CentOS Linux release 7.6.1810 (Core) и выше,
  2. Red Hat Enterprise Linux 7,
  3. ОС Astra Linux Common Edition (релиз «Орёл»),
  • Java 8 JDK,
  • WildFly (JBoss Application Server) 20 и выше – сервер приложений Java EE,
  • PostgreSQL 10 x86_64 и выше - система управления базами данных,
  • FreeIPA 4.8 и выше - интегрированное решение по идентификации и аутентификации пользователей, задания политик доступа к объектам доступа,
  • Sonatype Nexus 3.30 и выше – сервис менеджера пакетов, предназначенный для хранения артефактов роботов и действий,
  • Rabbit MQ 3.8 и выше – программный брокер сообщений на основе стандарта AMQP, обеспечивает асинхронную передачу сообщений между прикладными службами Платформы ROBIN,
  • HAProxy 2.1.3 и выше - серверное программное обеспечение для обеспечения высокой доступности и балансировки нагрузки для TCP и HTTP-приложений, посредством распределения входящих запросов на несколько обслуживающих серверов,
  • ELK-сервисы (Elasticsearch, Logstash и Kibana) – стек сервисов, предназначенный для сбора и хранения логов от прикладных сервисов Платформы ROBIN и от серверов приложений, а также для выполнения клиентских запросов с целью построения отчетов.

Состав специального программного обеспечения (СПО)

В состав специального программного обеспечения (СПО) серверной части Платформы ROBIN входят:

  • Robin Management Server (RMS) – централизованная служба, выступающая в роли оркестратора. Предоставляет программные интерфейсы (API), посредством которых с ним взаимодействуют клиентские приложения. Работает под управлением сервера приложений WildFly (JBoss Application Server).
  • Robin Package Manager – сервис, предназначенный для выполнения клиентских запросов к хранилищу роботов. Работает под управлением сервера приложений WildFly (JBoss Application Server).
  • Robin RDP-Manager – сервис, работающий на отдельном сервере. Предназначен для открытия и удержания RDP-сессий. Открытие RDP-сессии на удаленном хосте необходимо для робота, который работает с приложением, имеющим графический интерфейс, эмулируя работу пользователя.
  • База данных для серверных приложений RMS – система хранения мета-информации о роботах и расписаниях их запуска. Работает под управлением СУБД PostgreSQL 10+.
  • Каталоги сервера аутентификации и авторизации пользователей. Работает под управлением FreeIPA.
  • Хранилище пакетов – система хранения артефактов роботов и действий. Работает под управлением Sonatype Nexus.
  • Хранилище логов предназначено для хранения логов. Работает под управлением ELK-сервисов (Elasticsearch, Logstash и Kibana).
  • Система транспорта сообщений - работает под управлением RabbitMQ.

В состав Платформы ROBIN на стороне конечного пользователя входят следующие программные компоненты:

  • Robin Management Console (RMC) – клиентское приложение, предоставляющее пользователю графический интерфейс для централизованного управления запусками роботов на удаленных хостах,
  • Robin Studio – клиентское приложение, предоставляющее пользователю графический интерфейс для разработки программных роботов,
  • Robin Player – клиентское приложение, предоставляющее пользователю графический интерфейс для управления запусками программных роботов на исполнение сценария,
  • Robin Agent – прикладной сервис, расположенный на стороне клиента (Robin Studio или Robin Player):
  1. принимает через очереди сообщений программного брокера клиентские запросы со стороны Robin Studio, Robin Player и Robin Management Console,
  2. транслирует клиентские запросы системе исполнения сценариев программных роботов Robin Executor,
  3. отправляет в RMS через очереди сообщений программного брокера информационные сообщения о событиях в системе исполнения сценариев программных роботов Robin Executor (старт/останов робота), а также сообщения об ошибках.

Требования к вычислительной технике

Аппаратная конфигурация в исполнении demo

Для целей оценки функциональности все серверные компоненты Платформы ROBIN могут быть размещены на одном сервере со следующими минимальными требованиями к аппаратному обеспечению:

Аппаратная конфигурация в бескластерном исполнении

В этой конфигурации все серверные компоненты Платформы ROBIN разворачиваются на отдельных серверах со следующими минимальными требованиями к аппаратному обеспечению:

Аппаратная конфигурация в кластерном исполнении

В этой конфигурации каждый серверный компонент Платформы ROBIN развернут в кластере для обеспечения отказоустойчивости и возможности дальнейшего масштабирования системы:

Пример аппаратной конфигурации в кластерном исполнении:

Минимальная аппаратная конфигурация в исполнении cluster может быть такой:

Требования к персоналу (системному администратору)

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

В перечень задач, выполняемых системным администратором, должны входить:

  1. Задача поддержания работоспособности технических средств, на которых устанавливаются инфраструктурные сервисы (сервера приложений) и серверные компоненты Платформы ROBIN.
  2. Задача установки (инсталляции) и поддержания работоспособности операционной системы и серверов приложений.
  3. Задача установки (инсталляции), настройки и поддержания работоспособности специального программного обеспечения Платформы ROBIN:
  • серверных приложений RMS (на WildFly):
  • RDP Manager - самостоятельное java серверное приложение,
  • базы данных для серверных приложений RMS (на PostgreSQL),
  • базы данных (каталоги) сервера аутентификации и авторизации пользователей (на FreeIPA),
  • хранилища роботов (на Nexus),
  • системы очередей (на RabbitMQ),
  • коллекторов логов (filebeat) и фильтров логов (ELK-сервис).

Права, порядок доступа, а также результаты работы системного администратора в отношении серверных компонент RMS определяет и контролирует администратор безопасности на протяжении всех этапов эксплуатации RMS - от ввода в эксплуатацию до вывода из эксплуатации - в строгом соответствии с требованиями руководящих документов Заказчика по информационной безопасности.

Специальные требования к среде исполнения изделия для осуществления безопасности функционирования

Для безопасного выполнения Платформой ROBIN своих функций к среде функционирования предъявляются следующие требования в части касающейся безопасности и отсутствия влияния сторонних средств:

  1. Не должно происходить запуска ОС в однопользовательском режиме, так как в этом случае невозможно гарантировать неизменность конфигурации системы или выполнения задач по ее обслуживанию. Кроме того, должны быть выполнены условия по запрету выполнения команд для осуществления перехода в однопользовательский режим (например «telinit 1»).
  2. Всю системную конфигурацию среды исполнения должен проводить только администратор безопасности, за которым документально закреплена ответственность в части политики информационной безопасности.
  3. Доступ прикладных служб Платформы ROBIN к открытым портам сервера приложений RMS должен быть защищен от несанкционированного доступа межсетевым экраном, а все сетевые соединения защищены посредством использования протокола TLS или SSL.

Пользователи Платформы ROBIN

Конечные пользователи Платформы ROBIN представлены тремя группами:

  • группа администраторов - пользователи этой группы используют клиентское приложение Robin Management Console (RMC) для управления удаленными запусками роботов,
  • разработчики роботов - пользователи этой группы используют клиентское приложение Robin Studio,
  • операторы роботов - пользователи этой группы используют клиентское приложение Robin Player для локального запуска роботов.

Доступ пользователей к клиентским приложениям регулируется через их вхождение в группы, а также правилами разграничения доступа (ПРД), созданными в FreeIPA. Правила разграничения доступа определяют кто (пользователь), откуда (хост), куда (хост) и к какому приложению (службе) имеет право обращаться. За создание учетных записей пользователей, групп и правил разграничения доступа отвечает администратор Сервера идентификации пользователей FreeIPA. Права, порядок доступа, а также результаты работы администратор Сервера идентификации пользователей FreeIPA определяет и контролирует администратор безопасности на протяжении всех этапов эксплуатации Изделия - от ввода в эксплуатацию до вывода из эксплуатации - в строгом соответствии с требованиями руководящих документов Заказчика по информационной безопасности.

Функциональная архитектура серверной части Платформы ROBIN

Функциональные возможности Robin Management Server

Назначение RMS

RMS предназначен для обработки запросов от пользователей клиентских приложений - RMC, Robin Studio, Robin Player.

Функциональные возможности сервисов RMS

Сам RMS состоит из двух J2EE-приложений, выполняемых в WildFly как сервисы.

Сервисы RMS предоставляют конечным пользователям обширные функциональные возможности:

  • выполняют аутентификацию клиентских приложений RMC, Robin Player и Robin Studio,
  • позволяют пользователям клиентских приложений:
  1. управлять запусками и остановами роботов,
  2. просматривать журналы выполнения роботов,
  3. получать оперативную информацию о состоянии удаленных агентов, зарегистрированных в RMS (запущен/не запущен),
  4. получать оперативную информацию о текущем состоянии роботов (запущен/завершен),
  5. управлять запусками и остановами роботов на удаленных агентах в том числе составлять для них расписания запуска,
  6. просматривать историю запуска роботов на удаленных агентах,
  7. создавать/удалять учетную запись пользователя, предназначенную для открытия RDP-сессии на удаленном хосте,
  8. активировать/деактивировать учетную запись пользователя, предназначенную для открытия RDP-сессии на удаленном хосте.

Аутентификация и авторизация пользователей и клиентских приложений

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

Аутентификация клиентских приложений

В корпоративной и облачной версиях продукта присутствуют приложения (RMC, Robin Studio, Robin Player, Robin Agent), взаимодействующие с серверной частью. Процедура аутентификации клиентских приложений реализована по технологии единого входа (Single sign-on, SSO), которая позволяет этим приложениям безопасно взаимодействовать с серверными компонентами (RMS, RPM, HTTP-proxy) Платформы ROBIN без необходимости повторной аутентификации, используя SSO-токен. Сервис RMS выполняет роль SSO-сервера. Во время установления сессии (handshake), подтверждается взаимная аутентичность клиентского приложения и сервера RMS.

После прохождения аутентификации клиентское приложение получает SSO-токен (JWT-токен), который клиентское приложение вместе с временной меткой указывает в заголовке всех своих запросов к серверным приложениям. Все серверные приложения (RMS, RPM, HTTP-proxy) при каждом запросе валидируют токен клиентского приложения с помощью публичного ключа сервиса RMS, проверяют время действия токена и временную метку.

В облачной версии клиентское приложение (RMC, Robin Studio, Robin Player) допускается к процедуре аутентификации только в случае валидного токена компании. Проверка токена компании выполняется до процедуры аутентификации приложения. Токен компании получает ответственное лицо компании в своем личном кабинете после регистрации на Портале МаркетПлейса Облачной Фабрики Роботизации. Администратор указывает токен компании во время установки каждого клиентского приложения. На клиентских компьютерах токен компании хранится в защищенной (зашифрованной) конфигурации приложения. Токен компании может быть помечен как не валидный администратором компании и вместо него может быть выпущен новый. После того как текущий токен будет помечен как не валидный, воспользоваться им будет уже нельзя и потребуется процедура его замены.

Аутентификация пользователей

Если аутентификация приложения прошла успешно, то далее выполняется аутентификация пользователей.

Возможны следующие режимы аутентификации пользователя:

  • пользователь клиентского приложения является пользователем корпоративного домена AD, рабочая станция, на которой выполняется запуск клиентского приложения, включена в тот же домен, а между сервером идентификации (FreeIPA) и контроллером домена AD установлены доверенные отношения;
  • пользователь клиентского приложения является пользователем домена FreeIPA.

Если пользователь клиентского приложения является пользователем корпоративного домена и при этому между сервером идентификации (FreeIPA) и контроллером домена AD установлены доверенные отношения, то:

  • Аутентификация пользователя инициируется средствами клиентского приложения в момент его запуска. При этом пользователю не надо вводить свои учетные данные (логин/пароль),
  • Аутентификацию пользователя выполняет контроллер AD,
  • Авторизацию пользователя выполняет сервер каталогов FreeIPA.

Если пользователь клиентского приложения не является пользователем AD (является только пользователем домена FreeIPA), то клиентское приложение должно запросить у пользователя логин и пароль и выполнить процедуру аутентификации пользователя.

Авторизация пользователей

Возможны следующие режимы авторизации пользователя:

  • Если пользователь клиентского приложения не является пользователем AD (является только пользователем домена FreeIPA), то аутентификация и авторизация пользователя выполняется сервером идентификации FreeIPA.
  • Если пользователь клиентского приложения является пользователем корпоративного домена и между сервером идентификации (FreeIPA) и контроллером домена AD установлены доверенные отношения, то аутентификация пользователя выполняется контроллером домена AD, а авторизация пользователя выполняется сервером каталогов FreeIPA.

В этом случае вся информация о пользователе хранится на контроллере AD. Список AD групп, в которые входит пользователь, подтягиваются из AD, а его роли находятся в каталогах FreeIPA по их маппингу на группы AD.

Функциональные возможности Менеджера RDP-сессий

Менеджер RDP-сессий позволяет по запросу авторизованного пользователя RMC установить RDP-сессию на удаленном хосте для запуска роботов.

Важно

Для работы робота на хосте необходимо, чтобы предварительно был запущен Robin Agent или Robin Player. Если эти приложения не запущены, то сначала требуется установить RDP-сессию на удаленном хосте и запустить их. Если для этих приложений установлен режим автозагрузки, то приложения стартуют автоматически во время открытия пользовательской RDP-сессии.

Для запуска робота необходимо, чтобы был запущен Robin Player (процесс робота будет запущен приложением Robin Player из под учетной записи текущего пользователя RDP сессии). В качестве параметров Менеджер RDP-сессий получает от RMC параметры учетной записи пользователя, от имени которого будет установлена RDP сессия и будет выполнен робот.

Функциональные возможности серверного приложения Robin Package Manager (RPM)

Robin Package Manager предоставляет возможность аутентифицированным приложениям выполнять 2 вида запросов:

  • запрос на скачивание пакетов (проектов роботов, готовых роботов);
  • запрос на публикацию пакетов (проектов роботов, готовых роботов);

Оба типа запросов обрабатывает серверное приложение RPM (менеджер пакетов) оркестратора.

Взаимодействие пользователя с RPM происходит по протоколу HTTPS (порт 443 RMS) и требует предварительной аутентификации приложения.

Публикация пакетов «проекта робота» и «робота»

Приложение RPM, при получении от студии пакета выполняет следующие действия:

  • получает из пакета информацию о контракте и версии;
  • проверяет что в хранилище нет уже опубликованного пакета с таким контрактом и версией;
  • генерирует уникальный идентификатор пакета, под которым информация о нет будет размещена в каталоге FreeIPA;
  • создаёт новую запись о пакете в каталоге FreeIPA;
  • добавляет пакет в группы, если они были указаны в запросе;
  • размещает пакет на хранение на сервере Nexus.

Функциональные возможности брокера сообщений

В рамках Платформы ROBIN клиентские и серверные приложения могут обмениваться сообщениями. К таким приложениям относятся:

  • Robin-агенты (может быть несколько),
  • RMC - консоль управления роботами (может быть несколько),
  • RDPM - менеджер RDP-сессий (может быть несколько),
  • RMS - сервер управления (только один).

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

Защита сообщений

Сообщение передаются через очередь в зашифрованном виде. Каждый экземпляр приложения получает собственный ключ алгоритма симметричного шифрования (AES-256) во время в ходе процедуры аутентификации приложения.

Информационная архитектура серверной части Платформы ROBIN

В состав Платформы ROBIN на стороне серверной части входят следующие информационные активы (данные):

  • активы, хранимые в хранилище роботов: пакеты с исходниками роботов, зависимости (библиотеки), необходимые для выполнения исполняемого кода программных роботов;
  • активы, хранимые на сервере каталогов FreeIPA: учетные записи пользователей (для варианта развертывания без AD), учетная информация о роботах, права доступа пользователей к роботам и приложениям, группы пользователей и роботов;
  • активы, хранимые в базе данных RMS: структура пакетов роботов, действий и зависимостей; расписаний запуска роботов;
  • конфигурационные активы: конфигурационные файлы с настройками всех прикладных и инфраструктурных сервисов Платформы ROBIN; схема конфигурации очередей сообщений, поддерживаемых RabbitMQ;
  • активы, хранимые в системе хранения логов: логи от прикладных сервисов Платформы ROBIN.

Инфраструктурная схема серверной части с компонентами Платформы ROBIN 1.3 и 2.0

На схеме представлен пример физической инфраструктуры для размещения компонент серверной части Платформы 1.3 и 2.0. Сервера (и кластеры) на схеме объединены в функциональные группы:

Группа серверов «Сервер приложений и БД»

На данной группе серверов разворачиваются серверные компоненты RMS:

  • Robin Management Server (RMS) – централизованная служба, выступающая в роли оркестратора,
  • Robin Package Manager – сервис, предназначенный для выполнения клиентских и сервисных запросов к хранилищу роботов,
  • база данных для серверных приложений RMS (на PostgreSQL):

OrchestratorDS - источник данных для хранения структуры пакетов роботов, действий и зависимостей. QuartzDS - источник данных для хранения расписаний запуска роботов.

Кластер Robin RMS (+DC AppServer)

Кластер сервера приложений. Минимум три узла. На каждом узле установлен экземпляр сервера приложений и контролера домена серверов приложений. Один из узлов выделен под роль балансировщика нагрузки кластера. Именно на него поступает трафик с «граничного» балансировщика (функциональная группа «Балансировщик» на схеме), который направляет трафик (основываясь на части пути в запросе) на балансирующий узел кластера, и преобразует трафик из https в http.

БД PostgreSQL 10+

База данных для серверных приложений RMS (на PostgreSQL):

  • OrchestratorDS - источник данных для хранения структуры пакетов роботов, действий и зависимостей.
  • QuartzDS - источник данных для хранения расписаний запуска роботов.

Группа серверов «Хранилище пакетов»

Все артефакты в системе (как создаваемые при помощи студии, так и привносимые в обновлениях вендором) представлены в виде пакетов:

  • исходный код робота;
  • робот, подготовленный к эксплуатации;
  • действие, используемое в роботе;
  • библиотеки с бинарным кодом, которые необходимы действию - зависимости.

Все пакеты хранятся в специально предназначенном для этого хранилище - отказоустойчивое файловое хранилище пакетов.

Сервера хранилища пакетов «спрятаны» за сервером приложений. Клиентские приложения не имеют непосредственного доступа к хранилищу пакетов. Запросы поступают на сервер приложений, сервер проверят право на скачивание (либо публикацию) пакета и в случае одобрения проксирует запрос на кластер хранилища.

Состав функционального блока «Хранилище пакетов»:

  • Кластер Nexus Package Store - масштабируемое решение, позволяющее выполнять запросы на загрузку/выгрузку пакетов разных форматов, принятых для платформ .net, java, python.
  • Балансировщик кластера хранилища пакетов распределяет запросы к Nexus Package Store по узлам кластера.
  • Отказоустойчивое файловое хранилище пакетов. Как правило на предприятиях уже существуют отказоустойчивые файловые хранилища. Если таковое имеется и оно доступно по протоколу NFS, его можно использовать для хранения пакетов.

Группа серверов «Кластер очереди сообщений»

Основным недостатком серверного решения версии 1.0 была невозможность горизонтального масштабирования серверной части из-за использования синхронной передачи данных между агентами и сервером RMS по типу «запрос-ответ». В новой версии системы используется Rabbit MQ, который обеспечивает асинхронную передачу данных между прикладными службами Робин Платформы через масштабируемые очереди сообщений.

Группа серверов «LDAP»

С целью обеспечения ряда требований (возможность создания атрибутов объектов после ввода системы в эксплуатацию и обеспечения регулирования прав на уровне как групп, так и единичных записей), было принято решение использовать готовое решение корпоративного справочника. Для хранения записей о объектах и субъектах системы роботизации (и распределения полномочий) было спроектировано дерево объектов, хранимых в LDAP, и запросы доступа к данному дереву.

Группа серверов «Логирование и отчетность»

Для централизованного сбора и хранения логов (а так же построения отчетов в web интерфейсе) было выбрано существующее решение ELK (система из приложений Elasticsearch, Logstash, Kibana). На всех хостах системы, на которых работают клиентские приложения платформы ROBIN, устанавливается программное обеспечение агента ELK - Filebeat, в чью функции входит мониторинг и сбор лог-сообщений из лог-файлов и пересылке их в Elasticsearch или Logstash для индексирования.

Состав функциональной группы «Логирование и отчетность»:

  • Сервер Logstash.
  • Кластер Elasticsearch с балансировкой средствами elastic.
  • Сервер Kibana.
  • Агенты Filebeat на стороне клиентских приложений.

Группа серверов «Сервера RDP Manager»

Кластер этой группы серверов обеспечивает масштабируемое решение для Менеджера RDP-сессий.

Группа серверов «Балансировщик»

Функции балансировщика в Платформы ROBIN (в поставке с одним балансировщиком) включают:

  • Маршрутизация сетевых соединений из внешней сети к компонентам в серверной подсети.
  • Маршрутизация сетевых соединений между компонентам внутри серверной подсети.
  • Балансировка нагрузки, когда целью сетевого соединения является кластер серверов.

Таблица с описанием информационных потоков между серверами

В таблице представлено описание потоков между компонентами Платформы ROBIN с указанием:

  • источника данных;
  • получателя данных;
  • инициатора запроса на получение данных;
  • состава данных;
  • протокола и порта соединения;
  • периодичности передачи данных (по команде пользователя, в соответствии со сценарием или по расписанию).
Номер связи на схеме Источник данных Получатель данных Инициатор запроса на получение данных Состав данных Протокол и порт сервера Периодичность запроса
1 LDAP сервер (FreeIPA) Robin Studio, Robin Robot, Robin Management Console (RMC) Robin Studio, Robin Robot, Robin Management Console (RMC) Список доступных пользователю приложения роботов и проектов роботов LDAP 389 По команде пользователя
2 Сервер приложений, Сервер отчетов, Сервер очереди сообщений Robin Studio, Robin Robot, Robin Management Console (RMC), Администраторы приложений Robin Studio, Robin Robot, Robin Management Console (RMC), Администраторы приложений Пакеты содержащие роботов и проекты роботов. Информация о ходе выполнения роботов. HTML страницы с отчетами о выполнении роботов. HTML страницы административных интерфейсов серверов. HTTPS 443 AMQP 5672 По команде пользователя в соответствии со сценарием
3 Сервер приложений Через БалансировщикRobin Studio, Robin Management Console (RMC), Администраторы приложений Robin Studio, Robin Management Console (RMC), Администраторы приложений Пакеты содержащие роботов и проекты роботов. HTML страницы с отчетами о выполнении роботов. HTML страницы административных интерфейсов серверов. HTTPS 8080 По команде пользователя в соответствии со сценарием
4 База данных Сервер приложений Сервер приложений Информация о составе и ресурсных потребностях роботов TCP 5432 По команде пользователя в соответствии со сценарием
5 Хранилище пакетов Сервер приложений Сервер приложений Пакеты содержащие роботов и проекты роботов HTTP 8083 По команде пользователя в соответствии со сценарием
6 Сервер приложений LDAP сервер Сервер приложений Информация о пакетах роботов и пакетах проектов роботов LDAP 389 По команде пользователя
7 Robin Robot Через Балансировщик. Сервер очереди сообщений Robin Robot Информация о ходе выполнения роботов AMQP 5672 В соответствии со сценарием
8 Сервер приложений Через Балансировщик. Robin Robot Сервер приложений Команды управления работой роботов AMQP 5672 В соответствии со сценарием. По расписанию. По команде пользователя
9 Robin Robot Сервера Logstash Robin Robot Записи журналов выполнения роботов и приложений системы выполнения Robin Robot HTTP 5044 В соответствии со сценарием.
10 Сервера Logstash Сервера БД ElasticSearch Сервера Logstash Оптимизированные для хранения и индексирования, записи журналов выполнения роботов и приложений системы выполнения Robin Robot HTTP 9200 В соответствии со сценарием.
11 Сервер отчетов Kibana Сервер приложений Сервер приложений HTML страницы с отчетами о выполнении роботов HTTP 80 По команде пользователя
12 Сервер приложений Через Балансировщик. Кластер хранилища пакетов Сервер приложений Пакеты содержащие роботов и проекты роботов HTTP 8083 По команде пользователя. В соответствии со сценарием.
13 Сетевое хранилище файлов Кластер хранилища пакетов Кластер хранилища пакетов Файлы пакетов содержащие роботов и проекты роботов NFS 4 По команде пользователя. В соответствии со сценарием.
14 Сервер приложений Сервера сервиса RDP Manager Сервер приложений Команда на установление RDP соединения с хостом выполнения робота WSS: 443 /rms (Ver. 1.3) AMQP:5672 (Ver. 2.0) По команде пользователя. По расписанию.
15 Сервер сервиса RDP Manager Сервис RDP на хосте на котором должен работать робот Сервер сервиса RDP Manager Бинарные данные RDP сессии RDP 3389 По команде пользователя. По расписанию.
16 Кластер очереди сообщений Администраторы приложений Администраторы приложений HTML страницы административных интерфейсов серверов HTTP 15672 По команде пользователя.
17 Сервис Git Приложения из состава системы Ver. 1.3Robin Studio, Robin Robot, Robin Management Console (RMC) Приложения из состава системы Ver. 1.3Robin Studio, Robin Robot, Robin Management Console (RMC) Исходный код робота HTTPS 443 По команде пользователя. По расписанию.

Установка и настройка серверных компонент

Установка серверных компонент выполняется автоматически с помощью Ansible-скриптов (сценариев).

Ansible-скрипты:

  1. выполняют установку и конфигурирование следующего серверного ПО:
  • PostgreSQL 10+ - система управления базами данных,
  • ELK-сервис (Elasticsearch, Logstash и Kibana) – сервис, предназначенный для сбора и хранения логов от прикладных сервисов Платформы Робин, а также для выполнения клиентских запросов с целью построения отчетов.
  • FreeIPA - интегрированное решение по идентификации и аутентификации пользователей, задания политик доступа,
  • Sonatype Nexus – сервер пакетного менеджера,
  • Rabbit MQ – брокер сообщений, обеспечивает передачу сообщений между прикладными службами Робин Платформы.
  • WildFly (JBoss Application Server) – сервер приложений Java EE,
  1. загружают серверные компоненты ( j2ee-приложения) на сервер WildFly
  2. создают структуру БД в PostgreSQL,
  3. загружают структуру каталогов в FreeIPA.

Настройка конфигурационных параметров серверных компонент выполняется через конфигурационные файлы, которые являются неотъемлемой частью скриптов. Конфигурационные файлы задают:

  • задают целевые хосты, на которых будут устанавливаться приложения. Хосты могут быть объединены в группы;
  • параметры (пароли и ip) доступа к БД;
  • параметры WildFly (версии, пароль, ip, пути к исполняемым файлам);
  • параметры доступа к системе сообщений Rabbit;
  • параметрами распределенного кэша infinispan;
  • и другие параметры служб серверных компонент.

Запуск всех сервисов выполняется автоматически сразу же после завершения процедуры установки серверных компонент.