С использованием Docker#

Раздел предназначен для администратора Docker-поставки Sherpa Orchestrator. Для выполнения команд необходим доступ к серверу и Docker Compose. Необходимо использовать клиентские файлы и образы одной версии. Наличие параметра или скрипта следует проверить в установленной поставке.

Диагностика после установки и обновления#

Установщик и скрипт обновления предлагают запустить диагностику. Для повторной проверки из каталога установки используется команда:

cd /opt/SherpaOrchestrator
sudo bash sh_scripts/diagnostics.sh

Проверяются контейнеры, выбранные компоненты, версии, свободное место, подключение к БД, миграции, Vault, SIEM, nginx, Хранилище, веб-интерфейс и журналы. Исправления, которые предлагает скрипт, требуют отдельного подтверждения. Перед подтверждением необходимо прочитать описание действия.

Результат без замечаний означает успешное выполнение предусмотренных проверок. Он не заменяет проверку пользовательского сценария или доставки событий в SIEM. При ошибке необходимо сохранить название проверки и сообщение, устранить причину и повторить диагностику. Проверка миграций в этой поставке не доказывает соответствие всех объектов схемы БД.

Срок хранения системных метрик#

В файле .env параметр STORE_SYSTEM_METRICS_DAYS задает число дней хранения системных метрик. Значение по умолчанию — 30. Значение 0 отключает автоматическую очистку этих метрик. Необходимо использовать целое неотрицательное число.

Планировщик удаляет устаревшие записи. Уменьшение срока может привести к удалению истории, которую нельзя вернуть увеличением параметра. Параметр не задает сроки хранения Работ, аудита или сообщений Роботов.

Пример: для хранения системных метрик за последние 14 дней необходимо указать в .env:

STORE_SYSTEM_METRICS_DAYS=14

Для применения нового срока необходимо пересоздать только backend-контейнер в согласованное окно обслуживания:

cd /opt/SherpaOrchestrator
sudo docker compose up -d --no-deps --force-recreate orchestrator

Требования к паролям#

Параметры .env применяются к новым паролям Пользователей и Аккаунтов при создании или смене пароля:

Длина проверяется в байтах: для не-ASCII символов она может отличаться от числа символов. Минимальная и максимальная длины должны быть положительными целыми числами. Если максимум меньше минимума, используется минимум. Некорректные значения длины и некорректное регулярное выражение заменяются значениями по умолчанию. Регулярное выражение задается без разделителей.

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

cd /opt/SherpaOrchestrator
sudo docker compose up -d --no-deps --force-recreate orchestrator

Обычный перезапуск контейнера не перечитывает переменные окружения из .env.

Резервное копирование и перенос#

Перед обновлением или переносом необходима проверенная резервная копия. Дамп БД не включает Хранилище, конфигурацию и секреты Vault. Состав копии и ограничения описаны в статье Резервное копирование и восстановление.

Перенос local-поставки в Docker выполняется на той же версии, на том же сервере и без смены СУБД. Необходимо сохранить HOST_IP, ключ шифрования, основную и архивную БД, Хранилище, сертификаты и исходную установку для отката. На время копирования и проверки требуется остановить приложение и другие источники записи.

До начала переноса необходимо получить у технической поддержки Sherpa инструкцию "Перенос local-поставки в Docker" для используемой версии и СУБД. Смена сервера, IP, версии или СУБД требует отдельного плана. Нельзя запускать новую и старую установки одновременно с одной рабочей БД.

При переносе на новый сервер со старой БД может потребоваться восстановление лицензионной привязки. До работ необходимо получить у технической поддержки Sherpa инструкцию перепривязки для используемой версии и СУБД: MariaDB или PostgreSQL. Процедура выполняется администратором после резервного копирования. Временный доступ к setup.php и временные файлы необходимо удалить сразу после проверки.

Аудит БД и SIEM#

Аудит БД может содержать SQL-запросы и чувствительные значения. До включения необходимо определить права доступа, срок хранения, ротацию и свободное место. Включение аудита может потребовать перезапуска БД в окно обслуживания. Для отдельного источника аудита MariaDB необходимо получить у технической поддержки Sherpa инструкции настройки плагина и мониторинга для используемой версии.

Для штатной интеграции SIEM необходим полный комплект поставки с компонентом orchestrator-siem-exporter. При новой установке компонент выбирается в установщике, при обновлении — в меню состава установки. До начала работ необходимо получить у технической поддержки Sherpa инструкцию установки или обновления с SIEM для используемой версии и СУБД. Ниже приведены требования и проверка результата, а не полная процедура установки.

Приемник SIEM должен поддерживать Syslog по TLS, RFC 5424 и RFC 6587 octet-counting. Соединение устанавливает backend. Администратор SIEM предоставляет адрес, порт, имя сервера в сертификате, CA и при необходимости клиентскую пару для mTLS. Администратор Orchestrator настраивает SYSLOG_HOST, SYSLOG_PORT, параметры SYSLOG_TLS_*, служебные учетные данные и фильтр SIEM_DB_FILTER.

Пустой SYSLOG_HOST не включает отправку: при включенном аудите данные могут продолжать накапливаться. Экспортер передает события источника аудита БД, которые прошли фильтр. Это не копия всех действий Пользователя в интерфейсе. Правила обнаружения и оповещения задаются отдельно в SIEM.

Для проверки доставки администратор БД выполняет безопасный запрос обычной разрешенной учетной записью, а администратор SIEM ищет маркер в полученных событиях:

SELECT 'SHERPA_SIEM_CHECK_001' AS marker;

Фильтр должен пропускать select; служебный пользователь интеграции исключен из экспорта. Успешная диагностика без полученного контрольного события не подтверждает доставку. При длительной недоступности приемника необходимо контролировать очередь, журналы и свободное место.