База знаний
Войти

Управление Комплексом

Управление РОСА Миграция возможно двумя основными способами: через графический веб-интерфейс или программный интерфейс (REST API). Оба способа обеспечивают удобное и эффективное управление системой согласно потребностям пользователя.

Графический интерфейс (GUI) предоставляет интуитивное и простое в использовании окружение для управления Комплексом. Пользователь получает доступ ко всем функциям и инструментам, позволяющим настраивать и отслеживать различные этапы миграции. Более детальное описание возможностей GUI можно найти в документе "РОСА Миграция. Руководство пользователя".

Программный интерфейс приложения (API) предоставляет программистам и разработчикам возможность взаимодействовать с Комплексом напрямую, используя набор API-методов. Это позволяет автоматизировать процессы, интегрировать систему с другими приложениями и настраивать ее функциональность в соответствии с индивидуальными потребностями и сценариями использования. С описанием API-запросов и примерами ответов можно ознакомиться в интерфейсе Swagger — соответствующий раздел доступен в меню Контроллера.

Ролевая модель

Управление ролевой моделью в РОСА Миграция осуществляется на уровне тенанта — объекта, включающего в себя набор ключей доступа, проектов и машин, доступ к которым предоставляется для пользователей и групп на основании ролевой модели. Для управления учётными записями и правами пользователей, а также для определения доступных возможностей выполнения сценариев миграции и репликации РОСА Миграция использует следующую ролевую модель: три роли определяют функционал администратора и три роли задают права пользователя:

  • System Admin — роль даёт права на доступ ко всем API и полному функционалу Комплекса.
  • Security Admin — роль позволяет просматривать объекты Комплекса.
  • Platform Operator — роль даёт права на мониторинг и управление конфигурацией Комплекса без возможности запуска заданий на миграцию, а также позволяет создавать пользователей и их окружения.
  • Super User — роль позволяет предоставлять доступ к тенантам, полноценно работать с Комплексом и миграциями, но без возможности создания новых пользователей.
  • Power User — роль даёт возможность работать с основными объектами Комплекса, кроме действий с тенантами.
  • User Operator — роль даёт доступ к осуществлению миграций, но с ограниченным набором действий.

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

Раздел "Администрирование"

Данный раздел содержит перечень вкладок с инструментами для управления объектами РОСА Миграция (рисунок 17):

  • Общие настройки;
  • Мониторинг;
  • Управление;
  • Интеграции.

Рисунок 17 — Вкладки раздела "Администрирование"

Общие настройки

В разделе "Общие настройки" отображается форма для изменения публичного адреса Контроллера, создания новых самоподписанных сертификатов, замены существующих сертификатов на сертификаты от доверенного УЦ.

Изменение публичного адреса

Для изменения публичного адреса необходимо скорректировать адрес в поле "Публичный адрес" и нажать кнопку Сохранить (рисунок 18).

Рисунок 18 — Форма для изменения публичного адреса Контроллера

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

Работа с сертификатами

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

В открывшемся окне отобразится предупреждение о недоступности установленных агентов после генерации самоподписанного сертификата (рисунок 19). Необходимо нажать кнопку ОК.

Рисунок 19 — Запуск генерации самоподписанного сертификата

После этого в области уведомлений отобразится информация об успешном изменении сертификата (рисунок 20).

Рисунок 20 — Уведомление об изменении сертификата

Следует обратить внимание, что при установке Агента сертификат корневого УЦ (ca.mindsw.io.pem), используемый Контроллером, сохраняется на машине в каталог установки (/opt/mind/etc/tls — для Linux и %Program Files%\mind\ — для Windows) для настройки доверительных отношений между Агентом и Контроллером.

При замене сертификата сервера или УЦ на Контроллере требуется переустановить Агент для обновления файла ca.mindsw.io.pem или скопировать обновлённый сертификат корневого УЦ в соответствующий каталог на машине и перезапустить Агент.

Для замены существующих сертификатов на выданные доверенным УЦ следует нажать на значок напротив поля "Сертификат" и убрать флажок "Самоподписанный". Отобразятся следующие поля, которые необходимо заполнить (рисунок 21):

  • Сертификат контроллера — это сертификат сервера в формате Base64 (.pem), например:
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
  • Приватный ключ сертификата контроллера — это закрытый RSA-ключ (.key). например:
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
  • Промежуточный сертификат УЦ — это сертификат корневого или промежуточного УЦ, выпустившего сертификат Контроллера в формате Base64 (.pem), например:
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Рисунок 21 — Заполнение полей для замены сертификатов

Далее нужно нажать кнопку Сохранить. В открывшемся окне отобразится предупреждение о недоступности установленных агентов. Необходимо нажать кнопку ОК.

Следует обратить внимание, что при установке Агента сертификат корневого УЦ (ca.mindsw.io.pem), используемый Контроллером, сохраняется на машине в каталог установки (/opt/mind/etc/tls — для Linux и %Program Files%\mind\ — для Windows) для настройки доверительных отношений между Агентом и Контроллером. При замене сертификата сервера или УЦ на контроллере требуется переустановить агент для обновления файла ca.mindsw.io.pem или скопировать обновлённый сертификат корневого УЦ в соответствующий каталог на машине и перезапустить Агент.

Мониторинг

Состояние сервисов и систем

На вкладке "Состояние сервисов и систем" отображена информация о состоянии служб и ресурсов Контроллера. В этом разделе осуществляется мониторинг, проверка и оценка состояния запущенных сервисов (рисунок 22).

Рисунок 22 — Вкладка "Состояние сервисов и систем"

При необходимости возобновления работы сервисов необходимо нажать на Перезапустить напротив соответствующей строки, а в открывшемся окне предупреждения нажать ОК (рисунок 23).

Рисунок 23 — Подтверждение перезапуска сервиса

Логи

На вкладке "Логи" автоматически записывается важная информация о событиях Контроллера и Агента. При необходимости фильтрации логов Администратор может ввести запрос в соответствующую строку или выбрать в выпадающем списке последние запросы, а также установить количество отображаемых записей и выбрать временной интервал, за который они были сформированы (рисунок 24).

Рисунок 24 — Вкладка "Логи"

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

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

Также можно загрузить полный архив журналов с Контроллера, нажав на кнопку Скачать полный архив журналов (рисунок 25). Такой архив нужен для массового устранения неполадок, связанных с заданиями миграции и состоянием Контроллера. Архив включает в себя все логи с Syslog-сервера и JSON-файлы заданий на миграцию.

Рисунок 25 — Загрузка архива журналов с Контроллера

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

  • Загрузить dmesg -T (для ОС Linux);
  • Загрузить builder.log'и (для ОС Windows);
  • Загрузить журналы агентов.

Рисунок 26 — Выбор логов для скачивания

Для сбора диагностической информации на Контроллере также предусмотрен скрипт collect_diagnostic_information.sh, который располагается по пути /opt/mind/share/. Для запуска необходимо выполнить следующую команду:

bash collect_diagnostic_information.sh

После этого в файл по пути /tmp/collect_<date>.tar.gz выполнится сборка следующих логов:

  • system command (df -h, lsblk -f, dmesg -T (N = 2000 для dmesg -T) );
  • nginx logs (N = 1000);
  • podman logs (N = 1000);
  • services logs ("mind_api", "mind_jobworker", "mind_scheduler", "mind_logs", "mind_taskworker", "mind_vaults") N = 1000;
  • postgreSQL – информацию по таблицам (jobs, units, sets, protsets, unit_agents, sec_logs) N = 1000.

Аудит

На вкладке "Аудит" доступен журнал аудита системных событий. События представлены отдельными строками, которые можно отфильтровать по датам, а также произвести поиск по тегам, основывающимся на информации в полях записей. Для просмотра нужных полей можно воспользоваться элементами прокрутки и управления отображением столбцов в таблице (рисунок 27).

Рисунок 27 — Интерфейс журнала аудита

При двойном нажатии на любую запись аудита справа отобразится форма с детальной информацией по конкретному логу (рисунок 28).

Рисунок 28 — Детальная информация по логу

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

Рисунок 29 — Регулировка отображения системных событий

Поле "ID СОБЫТИЯ" содержит идентификатор события на Контроллере.

Поле "ДАТА" содержит информацию о дате и времени регистрации события на Контроллере.

В поле "СУБЪЕКТ ОПЕРАЦИИ" содержится имя учётной записи, которая сгенерировала событие.

В поле "КРИТИЧНОСТЬ" содержится описание уровня критичности события. Подробная шкала оценки критичности событий приведена в таблице 3.

Поле "НАЗВАНИЕ" содержит имя события.

В поле "АДРЕС ОБЪЕКТА ОПЕРАЦИИ" отображается имя или IP-адрес Контроллера, указанный в PublicURL.

В поле "НАЗВАНИЕ ХОСТА" указано имя компьютера/хоста, на котором установлен Контроллер.

Поле "СУБЪЕКТ ОПЕРАЦИИ" указывает, для какой учетной записи была выполнена операция

В поле "РОЛЬ ПОЛЬЗОВАТЕЛЯ" указана роль, назначенная учётной записи пользователя, выполнившего операцию. Подробная информация о ролевой модели приведена в документе .

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

Поле "IP-АДРЕС" содержит адрес виртуальной машины (рабочей станции), с которой пользователь отправил запрос.

В поле "КЛАСС" для удобства учёта и анализа все регистрируемые события группируются в несколько Классов, каждый из которых объединяет события, сходные по объекту или содержанию действия.

Описания классов приведены в таблице 4.

Значения поля "ДЕЙСТВИЕ" приведены в таблице 5.

Поле "ТИП ОБЪЕКТА" может быть заполнено одним из следующих значений:

  • group (группа);
  • job (задание);
  • project (проект);
  • unit (машина);
  • user (пользователь).

В поле "ID ОБЪЕКТА" в случае определения ID задания (job) используется GUID. Для остальных объектов используется числовое значение. ID – уникальный идентификатор объекта, для которого было выполнено действие.

В поле "ПОДСИСТЕМА" указывается принадлежность объекта или действия к одному из модулей: migrate, guard или controller.

Поле "ОПИСАНИЕ СОБЫТИЯ" — это расширенная информация о действии, которое было выполнено. Для событий с типом объекта job в данном поле приводится его внутренний идентификатор (GUID). При перезапуске сервиса через веб-интерфейс в лог записываются логин и идентификатор пользователя, выполнившего действие. Для всех остальных типов объектов приводится текстовое описание события, либо пустое поле, если описание не применимо.

Поле "РЕЗУЛЬТАТ" может быть заполнено одним из следующих значений, приведенных в таблице 6.

Статистика миграций

На вкладке "Статистика миграций" отображена информация о состоянии прохождения миграций в каждом продукте на Контроллере (рисунок 30).

Рисунок 30 — Вкладка "Статистика миграций"

Ротация логов

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

  • журналами событий, хранящимися в /var/log/mind;
  • журналами аудита;
  • событиями, хранящимися в базе victorialogs.

Для управления другими файлами журналов требуется настроить конфигурацию сервиса journald. Информация по настройке приведена в разделе "Настройка хранения событий в системных журналах".

Чтобы установить желаемые значения для управления глубиной хранения событий, ротацией по времени хранения или размеру занимаемого объёма на диске, необходимо привести переключатель "Включено" в активное положение, после чего поля в форме станут доступными для редактирования. (рисунок 31).

Примечание – Максимальный размер логов указывается в МБ.

Рисунок 31 — Вкладка "Ротация логов"

Управление доступами

Тенанты

На вкладке "Тенанты" отображается информация о созданных тенантах, а также пользователях и группах пользователей, которые имеют права на доступ в соответствующий тенант. Администратор может создать новый тенант, нажав на кнопку + Добавить. В открывшейся форме необходимо ввести название тенанта и нажать кнопку Сохранить (рисунок 32).

Рисунок 28 — Добавление тенанта

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

Группы

На вкладке "Группы" Администратор может создать локальную группу включить в нее пользователей и назначить доступ к определённым тенантам. Для создания группы необходимо нажать кнопку + Добавить (рисунок 33).

Рисунок 33 — Добавление новой группы

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

После этого созданная группа отобразится в перечне на вкладке "Группы". При нажатии Смотреть в столбце "Тенанты" или "Пользователи" можно просмотреть список тенантов, к которым у группы есть доступ, а также пользователей, которые включены в данную группу.

В столбце "Действие" Администратор может отредактировать информацию о группе, нажав на пиктограмму (карандаш) напротив соответствующей строки. Для удаления группы необходимо нажать на (корзина).

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

На вкладке "Пользователи" Администратор может просматривать, создавать, редактировать и удалять учётные записи пользователей, а также назначать роли.

Для создания локальной учётной записи пользователя необходимо нажать кнопку + Добавить одного пользователя.

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

При заведении локального пользователя также можно добавить возможность принудительной смены пароля после первого входа под этим пользователем. Для этого следует установить флажок в поле "Требовать смены пароля после входа".

После заполнения формы необходимо нажать Сохранить (рисунок 34).

Рисунок 34 — Добавление нового пользователя

После этого созданный пользователь отобразится в перечне на вкладке "Пользователи". Доменные учётные записи автоматически появляются на данной вкладке при первом входе на Контроллер.

При нажатии Смотреть в столбце "Тенанты" или "Группы" можно просмотреть список тенантов к которым у пользователя есть доступ, а также группы, в которые включён соответствующий пользователь. Во всплывающей форме можно выбрать новые для пользователя объекты и нажать + Добавить.

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

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

В столбце "Роль" каждому пользователю можно назначить нужную роль с определёнными правами, выбрав нужное из выпадающего списка. У одного пользователя может быть несколько ролей, в таком случае права ему назначаются суммарно от каждой роли.

В столбце "Статус" можно увидеть, активна ли данная учётная запись или заблокирована. Администратор может заблокировать учётную запись, нажав на (заблокировать).

В столбце "Действие" Администратор может заблокировать учётную запись, нажав на (корзина). Для редактирования информации необходимо нажать на (карандаш) в соответствующей строке. Для изменения пароля пользователя необходимо нажать на пиктограмму (ключ).

В столбце "Действие" также можно принудительно завершить активные сессии пользователей. Для этого необходимо нажать на пиктограмму (выход) в соответствующей строке. Отобразится окно предупреждения, в котором необходимо нажать ОК (рисунок 35).

Рисунок 35 — Подтверждение закрытия сессии пользователя

Группы LDAP

На вкладке "LDAP" администратором осуществляется привязка ролей к группам из LDAP-каталога, а также просмотр, редактирование и назначение ролей на группы. Для назначения новой роли требуется нажать кнопку + Сопоставить роль и группу LDAP и в карточке роли в выпадающем списке и выбрать соответствующую роль. В поле "Выберите сервер" необходимо указать имя конфигурации для подключения к LDAP-серверу. В поле "Тенанты" необходимо указать тенант на группу (рисунок 36).

Рисунок 36 — Вкладка "LDAP"

В поле "Запись о группе" необходимо указать DistinguishedName группы, которой требуется назначить данную роль. Для этого следует использовать формат:

distinguishedName: "cn=Администратор,cn=Users,dc=ldaptest,dc=mind,dc=io".

Если роль необходимо назначить нескольким группам, следует нажать кнопку + Добавить группу в карточку роли.

Для редактирования записи о группе необходимо нажать на (карандаш) напротив соответствующей строки. Для удаления нажать на (корзина). Для просмотра и добавления тенанта необходимо нажать на "Смотреть" в соответствующей записи (рисунок 37).

Рисунок 37 — Работа с тенантами

Политики

На вкладке "Политики" отображается особый набор правил безопасности. Для редактирования необходимо привести переключатель "Включено" в активное положение (рисунок 38).

Для управления политиками паролей доступны следующие настройки:

  • Максимальное время жизни пароля (задается в секундах) – по умолчанию составляет 90 дней;
  • Минимальное время жизни пароля (задается в секундах) – по умолчанию составляет 30 дней;
  • Количество попыток неправильного ввода пароля до блокировки – по умолчанию без ограничения;
  • Время блокировки пользователя при превышении числа попыток неправильного ввода (задается в секундах) – по умолчанию 3 минуты;
  • Время блокировки неактивного пользователя (задается в секундах) – по умолчанию составляет 45 дней;
  • История хранения паролей – по умолчанию пароли не хранятся;
  • Максимальное время жизни сессии пользователя (задается в секундах) – по умолчанию 86400 секунд (24 часа);
  • Минимальная длина пароля – по умолчанию 8 символов;
  • Минимальное количество букв в верхнем регистре – по умолчанию не менее 1 символа;
  • Минимальное количество букв в нижнем регистре – по умолчанию не требуется;
  • Минимальное количество цифр – по умолчанию не менее одного символа;
  • Минимальное количество спец.символов – по умолчанию не менее одного символа;
  • Пороговое значение для отправки уведомления об истечении срока пароля (задается в % от максимального времени жизни пароля) – по умолчанию 90. При превышении порогового значения времени жизни пароля пользователь получит письмо с уведомлением о том, что срок действия пароль скоро истечёт.

Рисунок 38 — Редактирование политик

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

Интеграции

Внешние секреты

На вкладке "Внешние секреты" осуществляется настройка интеграции с внешней системой хранения и управления секретами SecMan. Для добавления нового сервера необходимо нажать кнопку + Добавить и в открывшейся форме "Добавить сервер" заполнить следующие поля (рисунок 39):

  • Название – ввести имя хранилища секретов;
  • Тип – выбрать SecMan;
  • Параметры подключения – вести данные для подключения к серверу, заполнив необходимые поля в шаблоне:
    • serverUrl — адрес внешнего сервера SecMan, к которому будет идти обращение. Параметр является обязательным. Адрес сервера должен быть указан в формате "serverUrl":"t.xxxxxx.test.domain.com";
    • MFAMethodID — идентификатор метода аутентификации пользователя. Данный параметр указывается, если пользователь в системе SecMan защищён OTP;
    • namespace — название пространства имён в SecMan. Параметр опционален. Данные следует указывать в формате "namespace":"CIXXYYZZYY_CIIXXYYZZYY";
    • AD — имя LDAP-домена для авторизации в SecMan. Параметр является обязательным. Следует указывать в формате "AD":"ad\external.domain.com";
    • insecure — параметр, который игнорирует проверку сертификатов. В случае указания true проверка не будет осуществляться.

Рисунок 39 — Добавление внешнего сервера

После нажатия кнопки Сохранить на вкладке "Внешние секреты" отобразится созданный сервер с типом "secman", а в разделе "Ключи доступа" станет возможным выбор типа ключа "SecMan".

LDAP-серверы

На вкладке "LDAP серверы" осуществляется привязки ролей пользователей РОСА Миграция к группам из каталога LDAP. Для этого необходимо нажать кнопку + Добавить и в открывшейся форме ввести значения в следующие поля (рисунок 40):

  • Имя сервера – уникальное имя LDAP-сервера;
  • Адрес сервера – IP-адрес LDAP-сервера в формате ldap://<domain_controller_fqdn>:<ldap_port>, например ldap://controller.example.local:389;

Примечание – Для подключения к Контроллеру домена по LDAPS (LDAP с TLS) следует указывать адрес сервера в формате ldaps://<domain_controller_fqdn>:<ldap_port>, например: ldaps://controller.example.local:636.

  • Установить флажок "Игнорировать проверку SSL сертификата" для возможности отключения проверки сертификатов при настройке интеграции с Контроллерами домена через ldaps://;
  • Базовый DN – путь до OU или каталога, где будут размещаться учетные записи пользователей и групп пользователей, для которых требуется предоставлять доступ к Контроллеру в формате DistinguishedName, например: dc=ldaptest,dc=mind,dc=io;
  • Bind DN – путь до учетной записи пользователя, под которой будет выполняться подключение к Контроллеру домена в формате DistinguishedName, например: cn=Администратор,cn=Users,dc=ldaptest,dc=mind,dc=io.

Примечание – Для подключения к Контроллеру домена достаточно использовать учетную запись с правами на просмотр содержимого OU и каталогов, а также чтение атрибутов учетных записей пользователей и групп, например, учетной записи, состоящей в группе Domain Users.

  • Пароль – пароль пользователя.

Рисунок 40 — Форма добавления LDAP сервера

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

После успешного тестирования необходимо нажать на кнопку Сохранить.

Примечание – После добавления LDAP-сервера в интерфейсе в целях безопасности будет скрыто отображение значения полей "Базовый DN" и "Bind DN".

Для настройки подключения к LDAP с TLS необходимо выполнить следующие действия:

  1. добавить сертификат LDAP в доверенные на ОС:
  • поместить сертификат в /usr/share/local/ca-certificates (если директория отсутствует, то создать её);
  • в /etc/hosts добавить новую строку с IP-адресом LDAP-сервера и его доменным именем;
  • выполнить команды:
    • для ОС Astra Linux 1.7.7, Ubuntu Server 20.04 и Ubuntu Server 24.04:
cd /usr/share/local/ca-certificates
sudo update-ca-certificates

- Для ОС РЕД ОС 8 и SberLinux 8.10.x:

cd /usr/share/local/ca-certificates
sudo update-ca-trust
sudo update-ca-trust extract
  1. в интерфейсе Комплекса перейти в раздел "Администрирование", в списке "Управление доступами" выбрать пункт "Группы LDAP" и выполнить настройку. Подробная информация по настройке приведена в п. Группы LDAP.

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

Kerberos

Для миграции машин под управлением ОС Windows, находящихся в Active Directory с аутентификацией по протоколу Kerberos, необходимо на вкладке "Kerberos" выполнить следующие действия (рисунок 41):

  1. перевести переключатель "Включено" в активное положение, после чего поля в форме станут доступными для редактирования;
  2. в поле "Realm по умолчанию" ввести имя домена;
  3. в поле "Серверы DC" ввести серверы Контроллера домена через запятую;
  4. в поле "Сервер аутентификации" указать необходимый сервер.

Рисунок 41 — Форма настройки интеграции с Kerberos

После этого необходимо нажать на кнопку Сохранить.

Почта

На вкладке "Почта" администратором осуществляется настройка оповещений о ходе миграции по электронной почте.

Перечень событий, по которым будут отправляться оповещения приведены в таблице 7.

Для настройки правила оповещения необходимо нажать кнопку +Добавить правило и в открывшейся форме выбрать значения в следующих полях (рисунок 42):

  • Тип оповещения – Информация или Предупреждение;
  • Тип объекта – тим, о котором будут приходить оповещения:
    • Проект – о заданиях в проекте;
    • Тенант и указание ID оповещения – обо всех заданиях в указанном тенанте;
    • Задание – о конкретном задании в проекте;
    • Все – о заданиях на контроллере;
  • "Объект" – имя объекта (в зависимости от типа выбранного объекта в предыдущем поле) и его id, для которого будут генерироваться оповещения;
  • "Получатели" – один или несколько email-адресов получателей оповещений.

Рисунок 42 — Добавить новое правило

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

Для настройки SMTP необходимо нажать кнопку º и в открывшейся форме заполнить следующие поля (рисунок 43):

  • "Адрес почтового сервера";
  • "Порт для подключения";
  • установить флажок "Использовать SSL/TLS" при необходимости шифрования;
  • "Имя пользователя", которое будет отображаться при получении оповещений;
  • "Пароль";
  • "Email отправителя", который будет отображаться при получении оповещений.

Рисунок 43 — Настройка SMTP

После этого можно отправить тестовое сообщение на указанный адрес для проверки настроек, нажав кнопку Протестировать (рисунок 44).

Рисунок 44 — Тестовое сообщение

В случае ошибки в веб-интерфейсе отобразится соответствующее уведомление.

После выполнения всех настроек на указанный в правиле Email будут приходить оповещения о ходе выполнения миграции. В письмах присутствует следующая информация (рисунок 45).

  • Имя контроллера (hostname);
  • Имя и ID тенанта;
  • Имя и ID проекта;
  • Имя и ID задания;
  • Имена и ID машины источника и приёмника.

Рисунок 45 — Пример оповещения

Для удаления всех настроек подключения к SMTP-серверу с Контроллера нужно нажать кнопку Очистить.

Syslog

На вкладке "Syslog" администратором осуществляется отправки событий безопасности (audit logs) и информации о включённом/выключенном шифровании в задании в систему SIEM с использованием протокола syslog. Логи отправляются в формате CEF (Common Event Format). Для включения требуется нажать кнопку +Добавить и в открывшейся форме (рисунок 46):

  1. в поле "Адрес подключения" ввести IP-адрес или домен сервера syslog;
  2. в поле "Тэг" ввести тег сообщений, которые отправляются в syslog;
  3. в поле "Протокол" выбрать:
  • TCP;
  • UDP;
  1. в поле "Тип" выбрать соответствующий пункт. КомплексРуководитель поддерживает отправку логов через протокол syslog в двух режимах:
  • audit – для передачи событий безопасности (audit logs) и информации о шифровании заданий в SIEM-системы (в формате CEF);
  • general – для экспорта общих журналов событий во внешние системы сбора логов.

Рисунок 46 — Форма настройки отправки событий безопасности в SIEM

Оба типа (audit и general) могут работать параллельно. Для этого необходимо создать две отдельные конфигурации Syslog – в первой указать тип audit, во второй указать тип general – затем настроить разные "Тэги" или "Адреса подключения" при необходимости.

Совместная настройка позволяет отправлять аудит-логи в SIEM, а общие логи – в системы мониторинга, а также распределять нагрузку между серверами.

На вкладке "Бэкапы" (рисунок 47) администратором осуществляется настройка хранения резервных копий, что помогает обеспечивать отказоустойчивость Контроллера. Сервис mind-backup осуществляет восстановление следующих компонентов Комплекса:

  • Сертификаты;
  • Основной конфигурационный файл config.yml;
  • Драйверы;
  • InfluxDB;
  • Nginx;
  • Postgres.

Рисунок 47 — Вкладка "Бэкапы"

Пример конфигурационного файла mind-backup:

{
   "interval": {
   "exactTime": "2006-01-02T14:50:05Z",
   "step": "DAY"
   },
   "numberOfCopies": 3,
   "path": "/tmp"
}

где:

  • path — путь до директории, куда будут складываться резервные копии; не должен быть пустым;
  • numberOfCopies — максимальное количество резервных копий; работает только для автоматического создания, по этому параметру реализована ротация;
  • interval — структура, описывающая интервал проведения автоматических резервных копий;
  • step — шаг; может принимать значения HOUR, DAY, WEEK (соответственно: раз в час, раз в день, раз в неделю). Для последних двух значений используется параметр exactTime (рисунок 48);
  • exactTime — время, указывающее, в какой конкретный момент делать бэкап. В случае "step": "DAY" учитывается только переданное время, в случае "step": "WEEK" учитываются день недели и время.

Рисунок 48 — Вкладка "Бэкапы"

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

Конфигурационный файл сервиса хранится в БД, обновить его можно с помощью API или при помощи интерфейса программной строки CLI (в случае неисправности API).

Подробная информация об API-вызовах для работы с конфигурационным файлом приведена в документе "Руководство по работе с API".

Работа с mind-backup через CLI

Утилита mind_backup предоставляет интерфейс для управления резервным копированием и восстановлением оркестратора, находится по пути /opt/mind/bin/mind_backup.

Пример команды:

mind_backup [flags]

где flags:-v, --version – показать информацию о версии программы.

  • version – показывает текущую версию программы:
mind_backup version

Пример вывода:

VERSION: development, BUILDTIME: 1757435065, BRANCH: base-impl, COMMIT: a18af30, HOTFIX:
  • serve – запускает сервер резервного копирования в фоновом режиме:
mind_backup serve [flags]

где flags: -s, --servercfg string – путь к файлу конфигурации сервера:

mind_backup serve --servercfg /tmp/backup_server.yaml

Пример файла:

{
   "addr": "0.0.0.0:8085",
   "pgConf": {
   "rtDBUser": "cG9zdGdyZXM=",
   "rtDBPassword":
   "M3xqNURPQjEwdkdvMSRhbzZEfUE=",
   "rtDBAddress": "127.0.0.1",
   "rtDBPort": 5432,
   "rtDBName": "mind",
   "rtDBSSLMode": "disable"
   }
}

Особенности:

  • проверяет, не запущен ли уже сервер (через pgrep);
  • при обнаружении работающего сервера выводит ошибку с PID;
  • загружает конфигурацию и запускает сервер.

Примечание – Необходимо сначала остановить сервис mind_backup с помощью команды systemctl stop mind_backup. В противном случае будет указана ошибка с PID, информирующая о том, что данный сервис активен.

  • list – показывает список всех доступных резервных копий:
mind_backup list [flags]

где flags: -b, --cfg string – путь к файлу конфигурации бэкапов.

Пример:

mind_backup list --cfg /etc/mind/backup_config.yaml

Пример файла:

{
   "backupSettings": {
   "path": "/tmp",
   "interval": {   "step": "HOUR"
   },
   "numberOfCopies": 3
   },
   "pgConf": {
   "rtDBUser": "cG9zdGdyZXM=",
   "rtDBPassword":
   "M3xqNURPQjEwdkdvMSRhbzZEfUE=",
   "rtDBAddress": "127.0.0.1",
   "rtDBPort": 5432,   "rtDBName": "mind",
   "rtDBSSLMode": "disable"
   }
}

Пример вывода:

auto_backup_development_1757434140.tgz
auto_backup_development_1757435160.tgz
auto_backup_development_1757435400.tgz
  • create – создает ручную резервную копию:
mind_backup create [flags]

где flags: -b, --cfg string – путь к файлу конфигурации бэкапов.

Пример:

mind_backup create --cfg /tmp/backup_config.yaml

Примечание – Необходимо сначала остановить сервис mind_backup с помощью команды systemctl stop mind_backup. В противном случае будет указана ошибка с PID, информирующая о том, что данный сервис активен.

  • restore – восстанавливает систему из указанной резервной копии:
mind_backup restore [backup_path] [flags]

где:

  • backup_path – путь к файлу резервной копии (обязательный);
  • flags: -b, --cfg string – путь к файлу конфигурации бэкапов.

Пример:

mind_backup restore
auto_backup_development_1757435400.tgz --
cfg /tmp/backup_config.yaml

Примечание – Необходимо сначала остановить сервис mind_backup с помощью команды systemctl stop mind_backup. В противном случае будет указана ошибка с PID, информирующая о том, что данный сервис активен.

Восстановление должно выполняться на совместимой версии системы. Процесс резервного копирования и восстановления сопровождается даунтаймом, продолжительность которого зависит от скорости остановки и запуска сервисов: mind_system, mind_api, mind_healthmanager, mind_jobworker, mind_scheduler, mind_siteworker, mind_taskworker, mind_vaults.

Процесс валидации происходит следующим образом:

  • Все команды (кроме serve и version) проверяют, не запущен ли сервер.
  • При обнаружении работающего сервера команды завершаются с ошибкой.
  • Выполняется валидация настроек из конфигурационного файла.

Система уведомлений

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

  • Миграция была запущена.
  • Первичная репликация завершена и был выполнен переход в режим Flow.
  • Миграция завершена успешно.
  • Миграция завершена неуспешно.