Аннотация

Данный документ предназначен для системного программиста (администратора) серверных компонент Автоматизированной Системы «ROBIN Orchestrator» версия 2.0 (далее – АС «ROBIN Orchestrator» или изделие) и содержит описание процессов установки и настройки «ROBIN Orchestrator», требования к общесистемному программному обеспечению (ОПО) и вычислительной технике (ВТ), процедуры резервного копирования изделия и восстановления после сбоев, а также диагностические сообщения системному программисту. Функции администратора заключаются в обслуживании АС «ROBIN Orchestrator», включая установку, настройку программных и аппаратных средств, установку информационного обеспечения, управление функциональностью и логикой работы.

Права, порядок доступа, а также результаты работы системного программиста (администратора) в отношении АС «ROBIN Orchestrator» определяет и контролирует администратор безопасности на протяжении всех этапов эксплуатации АС «ROBIN Orchestrator» - от ввода в эксплуатацию до вывода из эксплуатации - в строгом соответствии с требованиями руководящих документов Предприятия по информационной безопасности. В данном документе в разделе «Общие сведения о программе» указаны назначение и функции программы и сведения о технических и программных средствах, обеспечивающих выполнение данной программы, а также требования к персоналу. В разделе «Структура программы» приведены сведения о структуре АС «ROBIN Orchestrator», ее составных частях, о связях между составными частями и о связях с другими программными средствами.

Раздел «Установка АС «ROBIN Orchestrator»» описывает условия и порядок развертывания Изделия. Раздел «Параметры запуска» описывает исполняемые файлы серверных компонентов АС «ROBIN Orchestrator» и параметры их запуска. В разделе «Настройка» приведено описание действий по настройке изделия. В разделе «Проверка и восстановление после сбоев» приведено описание действий администратора для проверки работоспособности Изделия с помощью диагностических команд. Также приведено описание действий администратора для восстановления системы после сбоев. В разделе «Сообщения системному программисту» приводится описание диагностических сообщений системному программисту.

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

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

АС «ROBIN Orchestrator» - комплекс программных средств серверной части Платформы ROBIN, предназначенных для обеспечения взаимодействия компонентов Платформы ROBIN на всех этапах жизненного цикла программных роботов – создания, хранения, изменения, тестирования, эксплуатации.

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

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

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

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

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

  • АС «ROBIN Orchestrator. Standalone».
  • АС «ROBIN Orchestrator. Enterprise».
  • АС «ROBIN Orchestrator. Cloud».

АС «ROBIN Orchestrator. Standalone» - пробная версия, предназначенная для ознакомления пользователя с возможностями Изделия. В этом исполнении все серверные компоненты устанавливаются на одном сервере, имеют полный набор функций, но ограниченный период пользования.

АС «ROBIN Orchestrator. Enterprise» - версия, предназначенная для использования на Предприятии. Может быть развернута в пределах защищенного контура корпоративной сети на ресурсах Предприятия (On-Premise). В этом случае собственником, эксплуатантом и выгодоприобретателем является само Предприятие, приобретая права собственности на Изделие в результате его покупки у разработчика.

АС «ROBIN Orchestrator. Cloud» - облачная версия. Система поставляется на рынок как RPA-платформа (PaaS). При этом собственником Системы является Провайдер Системы, а эксплуатантом – контрагенты, заинтересованные в роботизации рутинных бизнес-процессов на своих Предприятиях. Права собственности на Систему Провайдер приобретает в результате ее покупки у разработчика. А контрагенты приобретают право на пользование услугами Системы путем заключения договоров с Провайдером Системы. В версиях АС «ROBIN Orchestrator. Enterprise» и АС «ROBIN Orchestrator. Cloud» серверные компоненты могут быть развернуты на отдельных серверах как c образованием кластеров, так и без образования кластеров.

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

В зависимости от исполнения.

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

Изделие в исполнении АС «ROBIN Orchestrator. Standalone» приобретается для целей оценки состава функциональных возможностей Изделия. Все серверные компоненты Изделия в исполнении АС «ROBIN Orchestrator. Standalone» размещаются на одном сервере со следующими минимальными требованиями к аппаратному обеспечению, указанными в таблице ниже.

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

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

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

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

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

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

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

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

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

б) задача установки (инсталляции) и поддержания работоспособности общесистемных программных средств – операционной системы, СУБД на узлах Системы;

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

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

Основными обязанностями администратора безопасности являются:

  • модернизация, настройка и поддержка работоспособности комплекса технических средств (серверов, рабочих станций);
  • установка, модернизация, настройка и поддержка работоспособности системного и базового программного обеспечения;
  • установка, настройка и поддержка работоспособности прикладного программного обеспечения.

Права, порядок доступа, а также результаты работы системного программиста (администратора) в отношении серверных компонент АС «ROBIN Orchestrator» определяет и контролирует администратор безопасности на протяжении всех этапов эксплуатации Системы - от ввода в эксплуатацию до вывода из эксплуатации - в строгом соответствии с требованиями руководящих документов Предприятия по информационной безопасности.

Структура изделия

Состав изделия

В состав специального программного обеспечения (СПО) серверной части Платформы 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.

Приложения, которые включены в состав ROBIN Orchestrator, представлены на скринах ниже с описанием характеристик:

Первые три компонента (LogStash,ElasticSearch и Kibana) представленные на скрине, относятся к одному стеку и взаимосвязаны.

Алгоритм работы изделия

  1. Администратор выполняет установку серверных компонент АС «ROBIN Orchestrator» на требуемых серверах.
  2. Администратор с помощью интерфейсов администрирования выполняет настройку серверов приложений и баз данных АС «ROBIN Orchestrator».

Установка

В данном разделе описываются условия и порядок развертывания (установка) серверных компонентов АС «ROBIN Orchestrator» в следующих вариантах исполнений:

  • АС «ROBIN Orchestrator. Standalone»,
  • АС «ROBIN Orchestrator. Enterprise»,
  • АС «ROBIN Orchestrator. Cloud».

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

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

Администратор должен:

  1. получить задание на развертывание серверных компонентов АС «ROBIN Orchestrator»;
  2. подготовить ansible-хост, с которого будет выполняться установка;
  3. обеспечить условия доступа к целевым серверам с ansible-хоста;
  4. выполнить установку с помощью ansible-скриптов,
  5. выполнить пост-установочные процедуры.

Задание на развертывание серверных компонентов Изделия

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

  • должен быть указан вариант развертывания,
  • должна быть схема физической инфраструктуры серверов с указанием ip-адресов всех серверов,
  • архив ansible-deploy.tar.gz с дистрибутивом серверных компонентов АС «ROBIN Orchestrator» для выбранного варианта исполнения и ansible-скриптами вместе с конфигурационными файлами.

Варианты развертывания

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

  • «Установка Standalone» - установка на одном сервере,
  • «Установка Clusterless» - установка на нескольких серверах без образования кластеров,
  • «Установка Clusterful» - установка на нескольких серверах с образования кластеров.

«Установка Standalone»

«Установка Standalone» выполняется для исполнения АС «ROBIN Orchestrator. Standalone». Технические характеристики сервера должны соответствовать требованиям, приведенным в таблице ниже.

«Установка Clusterless»

«Установку Clusterless» рекомендуется выполнять на Предприятии с небольшим объемом ресурсов и невысокой степенью эксплуатации программных роботов со следующими показателям назначения:

  • одновременно работающих в системе пользователей – не более 1 000,
  • одновременно работающих в системе программных роботов – не более 1 000,
  • число транзакций в секунду для СУБД PostgreSQL – не менее 100 000,
  • число запросов в секунду для WildFly – не менее 1000,
  • число запросов в секунду для FreeIPA – не менее 100 000,
  • число передаваемых сообщений в секунду через подсистему транспорта служебных сообщений – не менее 100 000.

Технические характеристики серверов должны соответствовать требованиям, приведенным в таблице:

«Установка Clusterful»

«Установка Clusterful» выполняется, как правило, на Предприятии с достаточным объемом ресурсов и высокой степенью эксплуатации программных роботов для исполнения АС «ROBIN Orchestrator. Enterprise» или для исполнения АС «ROBIN Orchestrator. Cloud» со следующими показателям назначения:

  • одновременно работающих в системе пользователей – более 10 000,
  • одновременно работающих в системе программных роботов – более 10 000,
  • число транзакций в секунду для СУБД PostgreSQL – не менее 100 000,
  • число запросов в секунду для WildFly – не менее 1000,
  • число запросов в секунду для FreeIPA – не менее 100 000,
  • число передаваемых сообщений в секунду через подсистему транспорта служебных сообщений – не менее 100 000.

Технические характеристики серверов должны соответствовать требованиям, приведенным в таблице:

Порядок подготовки к установке

Все действия по установке серверных компонентов АС «ROBIN Orchestrator» производятся пользователем с правами root с выделенного управляющего сервера (ansible-хост), имеющего доступ по SSH ко всем управляемым серверам. На управляющем сервере должна быть установлена операционная система CentOS 7.

Порядок подготовки к установке серверных компонентов АС «ROBIN Orchestrator» заключается в следующем:

  1. Выполнить установку необходимых пакетов на ansible-хост.
  2. Распаковать архив ansible-deploy.tar.gz с дистрибутивом серверных компонентов АС «ROBIN Orchestrator»
  3. Выполнить настройку конфигурационных параметров ansible-скриптов.
  4. Сгенерировать сертификат для балансировщика и установить его в нужное место.
  5. Выполнить настройку доступа по SSH ко всем управляемым серверам.
  6. Открыть требуемые порты для балансировщика.

Ansible-хост

Установка пакетов

Поскольку установка серверных компонентов АС «ROBIN Orchestrator» выполняется автоматически с помощью ansible-скриптов (ansible-playbooks), то прежде всего необходимо установить пакет ansible и другие необходимые для него пакеты:

yum install epel-release python-netaddr unzip yum install ansible

Выполнить установку дополнительного модуля jbosscli, находясь в директории скриптов:

mkdir -p /usr/share/ansible/plugins/modules/ sudo cp ./files/jbosscli.py /usr/share/ansible/plugins/modules/

Распаковка архива

Архив ansible-deploy.tar.gz с дистрибутивом серверных компонентов АС «ROBIN Orchestrator» необходимо распаковать в какой-нибудь директории, например: cd /opt tar zxf ansible-deploy.tar.gz

Структура файлов и папок в директории ansible-deploy:

Описание файлов и директорий дистрибутива приведено в таблице:

Имя файла или директории Назначение Размещение
ansible.cfg Задает локальные настройки Ansible в том числе файл инвентаризации ./ - корневой каталог скриптов
hosts.ini Файл инвентаризации - задает целевые хосты, на которых будут устанавливаться серверные компоненты. Хосты могут быть объединены в группы. ./ - корневой каталог скриптов
start.yml Главный ansible-скрипт, который устанавливает серверные компоненты ./ - корневой каталог скриптов
wf-restart.yaml Ansible-скрипт для рестарта службы wildfly.service ./ - корневой каталог скриптов
all.yaml Задает общие и специальные настройки (пароли, пути к хранилищам сертификатов, имена устанавливаемых пакетов и т.д.) серверных компонентов ./group_vars/
./files Директория содержит пакеты с дистрибутивами общего и специального программного обеспечения, скрипты, публичные ключи и другие артефакты, необходимые для выполнения процедуры установки серверных компонент ./
./roles Содержит ansible-роли с задачами по установке серверных компонент. Подробности о том, что такое ansible-роли, можно найти в документации по Ansible: https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html ./
auditbeat.yml.j2 Jinja-шаблон для задачи по установке компонента auditbeat ./templates/
elasticsearch-single.yml.j2 Jinja-шаблон для задачи по установке Elasticsearch без кластера на одном сервере ./templates/
elasticsearch.yml.j2 Jinja-шаблон для задачи по установке Elasticsearch в кластере ./templates/
filebeat.yml.j2 Jinja-шаблон для задачи по установке компонента filebeat ./templates/
haproxy.cfg.j2 Jinja-шаблон для задачи по установке компонента HAProxy ./templates/
haproxy-rsyslog.conf Jinja-шаблон для задачи по установке компонента HAProxy и службы rsyslog ./templates/
haproxy-standalone.cfg.j2 Jinja-шаблон для задачи по установке HAProxy без кластера на одном сервере ./templates/
kibana.yml.j2 Jinja-шаблон для задачи по установке компонента Kibana ./templates/
logstash.conf.j2 Jinja-шаблон для задачи по установке компонента Logstash ./templates/
nexus.service Jinja-шаблон с настройками Nexus-сервиса ./templates/
nginx-repo.conf.j2 Jinja-шаблон с настройками Nginx-сервиса ./templates/
rdpmanager. application.properties.j2 Jinja-шаблон с настройками Nginx-сервисаRDP-менеджера ./templates/
rms2-infinispan.xml Jinja-шаблон с параметрами распределенного кэша infinispan сервиса rms2 ./templates/
rms2.properties Jinja-шаблон с параметрами сервиса rms2 ./templates/
rpm-infinispan.xml Jinja-шаблон с параметрами распределенного кэша infinispan сервиса rpm (для wf-standalone.yaml и wildfly.yaml) ./templates/
rpm.properties Jinja-шаблон с параметрами сервиса rpm (для задачи по установке WildFly) ./templates/

Настройка конфигурационных параметров

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

Инвентаризационный файл hosts.ini

Инвентаризационный файл hosts.ini (подробности https://docs.ansible.com/ansible/2.3/intro_inventory.html) содержит имя пользователя (ansible_user), под учетной записью которого будет выполняться вход в операционную систему управляемых серверов, имена (алиасы) и адреса управляемых серверов (ansible_host). Подключение ко всем управляемым серверам выполняется по протоколу SSH на порт 22 (по умолчанию). Если подключение по SSH выполняется по другому порту, то этот порт нужно указать после адреса сервера через символ «:».

Конфигурационный файл group_vars/all.yaml

Конфигурационный файл group_vars/all.yaml содержит общие параметры и параметры, специфичные для каждого управляемого сервера.

Секция Имя переменной Значение переменной Назначение
Общие парметры standalone_mode true Установка в режиме «всё на одном сервере»
lb_address testinstall. robin.demo Адрес балансировщика для доступа к сервисам
local_install true Использовать установку из локальных пакетов вместо внешних репозиториев
repo_path /opt/ansible-deploy/files/repo Путь к директории с пакетами для локальной установки
FreeIPA domain robin.demo Домен LDAP
base_dn dc=robin,dc=demo Base DN
ldap_autoinit true Инициализировать LDAP автоматически (около 10 мин. для каждого сервера)
admin_pass Qwerty123 Пароль пользователя admin, задаваемый при автоинициализации
dm_pass Qwerty123 Пароль пользователя Directory Manager, задаваемый при автоинициализации
ldap_use_ssl false Использовать SSL для подключения к LDAP серверу
ldap1_fqdn, ldap2_fqdn, … testinstall. robin.demo Полные адреса серверов LDAP
DB db_postgres_pass Qwerty123 Пароль пользователя postgres
db_robin_pass Qwerty123 Пароль пользователя robin внутри базы данных
db_users_pass Qwerty123 Пароль пользователей user_orch, user_quartz, user_rpm внутри базы данных
flyway_ver 7.8.1 Версия пакета FlyWay
RabbitMQ rabbit_admin_pass Qwerty123 Пароль пользователя admin внутри брокера
erlang_cookie 7KzILFz03fmS Erlang cookie для связи узлов кластера
rabbit_agent_pass Qwerty123 Пароль пользователя agent внутри брокера
rabbit_rmc_pass Qwerty123 Пароль пользователя rmc внутри брокера
rabbit_rms_pass Qwerty123 Пароль пользователя rms внутри брокера
rabbit_rdp_pass Qwerty123 Пароль пользователя rdp внутри брокера
Nexus nexus_ver 3.32.0-03 Версия пакета Nexus
nexus_port 8081 Порт для доступа к Nexus. По умолчанию 8081, изменять только в случае ошибок.
nexus_admin_pwd Qwerty123 Устанавливаемый пароль пользователя admin
Wildfly wf_version 23.0.2 Версия пакета
schema_version 16.0 Версия схемы, зависит от версии пакета
wf_admin_pass Qwerty123 Пароль пользователя admin для доступа к Wildfly. Меняется в случае ручного изменения через скрипт add-user.sh.
wf_slave_secret RFB5N0NMRSEyVmc2KzI= Хэш пользователя slave для связи слэйвов между собой
HAProxy lb_cert /etc/ssl/certs/lb.pem Путь, где будет храниться сертификат с ключом балансировщика
Файлы/Пакеты auditbeat_file auditbeat-7.15.1-x86_64.rpm Имя пакета auditbeat
filebeat_rpm filebeat-7.15.0-x86_64.rpm Имя пакета filebeat
haproxy_file haproxy-2.4.7-1.el7.x86_64.rpm Имя пакета HAProxy
kibana_objects_file kibana_objects-2112021320.ndjson Имя файла с объектами для Kibana сервиса
  ldif_file ldif-2111242015.zip Имя файла с форматом представления записей службы каталогов или их изменений в текстовой форме.
  repository_war_file repository-2112021320.war  
  rms_public_file rms-public-2112021320.pub  
  rms2_war_file rms2-2112021320.war Имя файла с приложением RMS
  rms2_war_file rms2-2112021320.war Имя файла с приложением RMS
  robinrdpmanager_file robin-rdp-manager-1.0-1.x86_64.rpm Имя пакета с приложением Robin RDP Manager
  rpm_war_file rpm-2112021320.war Имя пакета с приложением Robin Package Manager
  rpms_repo_file rpms-repo-2112041757.tar.gz  
  sql_migrations_file sql_migrations-2110041449.zip  
  wf_driver_pg_file wf_driver_pg-2103231154.zip  
  wf_driver_rms2_file wf_driver_rms2-2012181023.zip  
  wf_driver_logstash_file wildfly-logstash-1.0.9-SNAPSHOT.zip  

После того как все конфигурационные параметры в файлах ./hosts.ini и ./group_vars/all.yaml будут заданы, необходимо будет выполнить: генерацию сертификата для балансировщика, настройку доступа по SSH, открытие портов, установку серверных компонентов.

Генерация сертификата для балансировщика

Сертификат должен быть выпущен Удостоверяющим Центром, выбранным по усмотрению Заказчика. Сертификат быть создан также как самоподписанный. Актуальный сертификат для балансировщика необходимо положить в директорию files вместо files/lb.pem.

Настройка доступа по SSH

Предпочтительным способом подключения к управляемым серверам по SSH является способ с использованием SSH-ключей и ssh-agent. Для этого необходимо:

  1. На ansible-хосте сгенерировать пару SSH-кдючей с помощью команды: ssh-keygen -b 4096
  2. Установить публичный ключ на всех управляемых серверах с помощью утилиты ssh-copy-id или любым иным возможным способом, известным администратору.

3) Проверить SSH доступ с помощью команды: ssh your_username@your_server_ip. Если доступ по SSH ко всем управляемым серверам обеспечен, то можно переходить к следующему шагу.

Открытие портов

Прежде всего должен быть открыт порт 22 на всех управляемых серверах для доступа к ним с ansible-хоста по SSH протоколу. В случае, если используется межсетевой экран, необходимо открыть требуемые порты для балансировщика: 80, 8081, 9080, 9443, 10990, 5671, 5672, 15672, 443, 389, 636.

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

Для установки серверных компонентов АС «ROBIN Orchestrator» необходимо выполнить: ansible-playbook start.yaml

Параметры запуска сервисов

Сервисы

Для обеспечения работоспособности серверных компонент АС «ROBIN Orchestrator» необходимо, чтобы на серверах были запущены следующие сервисы:

  • auditbeat,
  • elasticsearch,
  • filebeat,
  • haproxy,
  • ipa.service,
  • kibana,
  • logstash,
  • nginx.service,
  • nexus.service,
  • postgresql-11,
  • rabbitmq-server.service,
  • robin-xvfb,
  • robin-rdp-manager,
  • wildfly.service.

Автозапуск

Все сервисы во время установки серверных компонентов сконфигурированы на автозапуск – при загрузке операционных систем серверов все сервисы запускаются автоматически.

Штатный останов сервисов

Для штатного останова сервиса необходимо выполнить команду: sudo systemctl stop <service_name> где вместо <service_name> необходимо использовать имя соответствующего сервиса. Команда выполняется пользователем с правами root.

Штатный запуск сервисов

Для штатного запуска сервиса необходимо выполнить команду: sudo systemctl start <service_name> где вместо <service_name> необходимо использовать имя соответствующего сервиса. Команда выполняется пользователем с правами root.

Штатный перезапуск сервисов

Для штатного перезапуска сервиса необходимо выполнить команду: sudo systemctl restart <service_name> где вместо <service_name> необходимо использовать имя соответствующего сервиса. Команда выполняется пользователем с правами root.

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

В варианте развертывания «Установка Standalone» все команды по запуску, останову, перезапуску всех сервисов выполняются на одном сервере. В варианте развертывания «Установка Clusterless» все команды по запуску, останову, перезапуску сервиса выполняются на том сервере, на котором этот сервис установлен. В варианте развертывания «Установка Clusterful» все команды по запуску, останову, перезапуску сервиса выполняются на всех серверах кластера, в котором эти сервисы установлены.

Конфигурирование и настройка

Пост-установочные процедуры

После установки серверных компонентов АС «ROBIN Orchestrator» необходимо выполнить пост-установочные процедуры конфигурирования некоторых сервисов.

WildFly

rpm.properties

На каждом из серверов Wildfly в файле /opt/wildfly/modules/rms2/main/properties/rpm.properties найти параметр nexus.nodes и прописать в нем через запятую для всех автономных серверов Nexus их IP и соответствующие Nexus ID в формате:

nexus.nodes=ID1&IP1,ID2&IP2,..,IDN&IPN

где Nexus ID и IP имеют вид:

ID=XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX IP=http://127.0.0.1:8081

Nexus ID доступны на вкладке Nexus -> Support -> System Information -> node-id (доступно для автоматизации только в Pro версии нексуса). После внесения изменений в файл rpm.properties необходимо перезапустить службу Wildfly: sudo systemctl restart wildfly.service

Пользователи

Сгенерировать свои секреты и хэши для Wildfly и прописать их в конфиг (трижды запустить add-user.sh) согласно инструкции (опционально).

Пользователь управления

Далее необходимо создать пользователя управления, который сможет подключаться с помощью консоли администрирования или удаленно с помощью интерфейса командной строки. Чтобы добавить нового пользователя, используйте add-user.sh скрипт, который находится в каталоге bin WildFly:

Вас спросят, какого типа пользователя вы хотите добавить:

Выберите a и нажмите Enter. Далее скрипт предложит вам ввести данные нового пользователя:

  • имя пользователя – ввести имя пользователя,
  • пароль – ввести пароль,
  • повторить пароль – повторно ввести пароль,
  • добавить пользователя в группу управления „ManagementRealm“ – оставить без изменения,
  • на вопрос: «Is this new user going to be used for one AS process to connect to another AS process?» ответить – no.

Новый пользователь будет добавлен в файлы свойств, используемые для аутентификации.

Далее необходимо добавить пользователя, от имени которого подчиненный хост-контроллер (slave) будет подключаться к мастеру (master), или для удаленного подключения для EJB- вызовов сервера к серверу. Чтобы добавить нового пользователя, используйте add-user.sh скрипт, который находится в каталоге bin WildFly:

Вас спросят, какого типа пользователя вы хотите добавить:

Выберите a и нажмите Enter. Далее скрипт предложит вам ввести данные нового пользователя:

  • имя пользователя – ввести имя пользователя,
  • пароль – ввести пароль,
  • повторить пароль – повторно ввести пароль,
  • добавить пользователя в группу управления „ManagementRealm“ – оставить без изменения,
  • на вопрос: «Is this new user going to be used for one AS process to connect to another AS process?» ответить – yes.

Новый пользователь будет добавлен в файлы свойств, используемые для аутентификации. Будет сгенерирован хэш вида <secret value=»UGFuMjNkZWo3NyNA» />, который нужно сохранить для дальнейшего добавления в конфиг.

Конфигурирование slave-хостов

В файле /opt/wildfly/domain/configuration/host.xml на каждом из slave-серверов:

  1. Задаем имя хоста. Оно может быть любым, но должно быть уникальным внутри домена:
  1. Добавляем полученный хэш в ManagementRealm:
  1. Указываем адрес контроллера домена «${jboss.domain.master.address:192.168.1.1}» и имя пользователя «slave»:
  1. Прописываем соответствующий адрес интерфейса public:

LDAP

Для всех клиентских приложений необходимо прописать актуальные параметры для подключения к LDAP серверу. Процедура конфигурирования и настройки клиентских приложений выполняется с помощью утилиты RobinLdbConfigUpdater.exe, которая входит в состав дистрибутивов для соответствующих редакций:

  • Robin STUDIO:

Редакция Desktop, Редакция Enterprise, Редакция Cloud,

  • Robin ROBOT:

Редакция Desktop, Редакция Enterprise, Редакция Cloud,

  • Robin RMC:

Редакция Enterprise, Редакция Cloud.