Документ описывает профиль deploy/airgap/docker-compose.airgap.yml и комплект,
подготавливаемый штатным сборщиком. Версии образов и зависимости конкретной
поставки определяются её манифестом. Действующая установка на другом Compose
профиле может иметь иные пути, порты и состав компонентов.
Связанные документы: функции, установка, эксплуатация, жизненный цикл.
Начальный ориентир для небольшой испытательной установки: x86_64, 4 ядра CPU,
8 ГБ RAM, 50 ГБ свободного диска; рекомендуемый запас — 8 ядер, 16 ГБ RAM,
200 ГБ SSD. Это плановые значения, а не результат нагрузочной аттестации.
Для ноутбука с 8 ГБ RAM задать XKSM_CELERY_CONCURRENCY=1;
не включать дополнительные необязательные сервисы.
Ресурсы для конкретного парка определяются измерениями при согласованных
числе серверов, датчиков, частоте опроса и сроках хранения.
Поставка Base 20261026repair2 приложения 2.64.0 рассчитана на Ubuntu 24.04
amd64 и включает 36 deb-пакетов Docker 29.9.2 / Compose 5.6.1.
Офлайн-установка пакетов и CLI проверены в контейнере Ubuntu; daemon, чистая ОС
и reboot этим не проверены. SHA256 приведены в инструкции установки. Старый ноутбучный комплект от 21.10.2026 требует готового Docker/Compose.
Наличие пакетов не подтверждает чистую установку. Другие ОС требуют отдельной
проверки точной редакции. Windows используется как клиент через браузер;
серверная установка Windows данным профилем не предусмотрена.
Требуются root/sudo для установки пакетов и Docker, каталогов и сертификатов. Рабочее место требует браузера с JavaScript и HTTPS-доступом к экземпляру.
Совместимость с РЕД ОС, Astra Linux и ALT Linux должна подтверждаться отдельными протоколами для точной редакции ОС, ядра, Docker и выбранного состава поставки. Наличие Docker само по себе не подтверждает совместимость, сертификацию либо выполнение требований к доверенной ОС. Без протокола такой статус не заявляется.
| Сервис | Назначение | Данные |
|---|---|---|
| backend | FastAPI, аутентификация, инвентаризация и API | PostgreSQL, файлы /var/xksm |
| celery | Фоновые задачи опроса и обработки | Redis, PostgreSQL, ClickHouse, /var/xksm |
| celery-beat | Планирование периодических задач | Файл расписания контейнера; восстановление проверить |
| frontend | Статический веб-интерфейс | Образ frontend |
| edge | Внешний HTTPS reverse proxy | Конфигурация и сертификаты TLS |
| postgres | Инвентарь, организации, права, задачи и настройки | Том postgres_data |
| redis | Очереди задач, кэш и координация опросов | Том redis_data |
| clickhouse | Телеметрия и аналитические данные | Том clickhouse_data |
В исходном офлайн-профиле используются PostgreSQL 16.15, Redis 7.4.11,
ClickHouse 24.8.14.39; фактические digest фиксируются в манифесте выпуска.
NGINX 1.30.6 используется для edge и статического веб-интерфейса. PostgreSQL
обновлён в пределах основной ветки 16. Проверочный состав — Base без AI,
федерации и внешних СХД. AI отключён (AI_ENABLED=false); Qdrant, AI gateway,
langchain и python-jose в runtime-профиль не входят.
Наличие других сервисов в репозитории не означает их включения в поставку.
Федерация по умолчанию выключена; для её испытаний нужны включение настройки,
подходящая лицензия, права и второй экземпляр.
Внешние публикации текущего профиля:
| Назначение | Порт | Ограничение |
|---|---|---|
| Веб-интерфейс и API через edge | 443/TCP | Только необходимые клиентские сети |
| Локальный HTTP edge | 127.0.0.1:80/TCP | Только loopback хоста |
| NetFlow | 2055/UDP | Только согласованные источники, если функция используется |
| sFlow | 6343/UDP | Только согласованные источники, если функция используется |
Базы данных и backend API не публикуются отдельными хост-портами. Внутри Compose: backend 8000/TCP, frontend 8080/TCP, PostgreSQL 5432/TCP, Redis 6379/TCP, ClickHouse HTTP 8123/TCP и native 9000/TCP. Эти порты не нужно открывать внешним пользователям или в Интернет. Выход к BMC обычно требует HTTPS 443/TCP, однако порт задаётся индивидуально. IPMI использует 623/UDP; SSH — 22/TCP при использовании соответствующих операций. Пробросы NAT могут менять внешние порты. Для внешних СХД, SMTP, федерации и других интеграций нужны отдельно согласованные маршруты и правила.
Офлайн-установка не требует загрузок из Интернета при наличии полного комплекта образов и системных зависимостей выбранной ОС. Локальные DNS/NTP и доступ к оборудованию должны быть предусмотрены. Доверие к HTTPS-сертификату и имя проверяются на рабочих местах. Исходящие подключения конкретных включённых интеграций проверяются отдельно; работа изолированного режима подтверждается испытанием с запрещённым Интернетом.
Каталог установки, например /opt/xksm, содержит:
.env настройки и серверные секреты
images.tar образы поставки
docker-compose.airgap.yml описание сервисов
install.sh / update.sh установка и обновление
keys/ серверные JWT-ключи
license/ подписанная лицензия
tls/ конфигурация edge и сертификаты
migrations/ ClickHouse-миграции
VERSION версия выпуска
docker/ пакеты Docker/Compose, только в полном варианте
ARTIFACT-MANIFEST.json манифест поставки
CHECKSUMS.sha256 контрольные суммы
Данные БД находятся в именованных Docker-томах, а не автоматически в
/opt/xksm/data. Том xksm_var подключён к /var/xksm backend и worker и содержит
файлы приложения, включая прошивки, журналы и резервные копии согласно настройкам.
Фактические имена томов зависят от Compose project name; расположение проверяется
через docker volume inspect. Файл расписания beat требует отдельного учёта при
пересоздании контейнера.
.env, приватные ключи и файлы лицензии не должны включаться в публичный архив
диагностики. Права каталогов и UID контейнеров устанавливаются штатным установщиком.
Пароли BMC/SSH в БД требуют сохранения соответствующего ключа шифрования.
Потеря ключа делает такие записи непригодными; его смена без ротации не расшифрует
старые данные. Потеря Redis может привести к потере очереди и состояния задач,
поэтому нельзя обещать отсутствие последствий или безусловное повторное выполнение.
Количество управляемых устройств и срок хранения ограничиваются ресурсами, лицензией и настройками. Значения «10 000+ серверов», «86 млн событий/сутки», «<0,5 с» и коэффициенты сжатия без соответствующего воспроизводимого протокола не являются подтверждёнными характеристиками данного проверочного экземпляра.
Измерить суточный прирост PostgreSQL, ClickHouse, журналов и файлов при выбранной частоте опроса. Рассчитать объём на согласованный срок с запасом на индексы, миграции и резервные копии. Фактические retention/TTL таблиц проверяются по схеме конкретного выпуска; этот документ не обещает автоматического удаления данных через единый фиксированный срок. Мониторить свободное место и ошибки записи.
Согласовать RPO/RTO и состав копии. Включить PostgreSQL, необходимые данные
ClickHouse, /var/xksm, .env, ключи, лицензию, TLS, Compose-конфигурацию и
манифест. Копирование файлов работающей БД не заменяет согласованную процедуру
создания консистентной копии. Хранить копии с ограниченным доступом на отдельном
носителе. Не выполнять docker compose down -v при сохранении данных.
Приёмка восстановления: развернуть копию на отдельной чистой машине, проверить вход, организации/права, расшифровку сохранённых BMC-секретов без их вывода, инвентарь, историю метрик и работу фоновых задач. Зафиксировать время и потери данных; только после этого подтверждать достигнутые RPO/RTO. Обновление и откат описаны в инструкции установки.
В /opt/xksm команда sudo docker compose -f docker-compose.airgap.yml
--env-file .env logs --tail=200 backend celery celery-beat edge читает журналы
выбранных сервисов. Общий статус — та же команда с ps вместо logs.
Внутренние файловые журналы приложения находятся в /var/xksm/logs,
прошивки — /var/xksm/firmware, резервные копии — /var/xksm/backups.
Журнал запуска установщика оператор сохраняет в $HOME/xksm-install.log;
этот файл не является автоматическим архивом всех журналов приложения.
Root/sudo и членство в Docker-группе дают административные полномочия на хосте; эксперту для обычной работы достаточно отдельной учётной записи приложения. Учётная запись скачивания закрытых файлов не является входом в приложение. Контакт развёртывания и сопровождения: support@xkserv.ru, +7 (499) 504-42-22, будние дни 09:00–18:00; часовой пояс согласуется отдельно.
Исходный код и история изменений ведутся в Git-репозитории проекта XKSM.
Структура: backend/ — серверный код Python, миграции и зависимости;
frontend/ — TypeScript/React, статические ресурсы и lock-файл npm;
deploy/airgap/ — описание контейнеров и упаковка офлайн-поставки;
scripts/ — инструменты сборки и проверки; docs/ — документация и протоколы.
Секреты продукции, лицензии пользователей и приватные ключи подписи не должны
включаться в Git, исходный архив или установщик.
Сборка backend определена в backend/Dockerfile.onprem: установка зависимостей
из зафиксированного набора, подготовка on-prem режима, компиляция выбранных
модулей в нативные .so средствами Cython и C-компилятора по
scripts/onprem_cython_modules.txt внутри backend, затем компиляция остальных
модулей Python командой python -m compileall -b -q и удаление исходных .py
из конечного слоя приложения. Миграции Alembic работают в sourceless-режиме.
Байткод не следует считать криптографической защитой или гарантией
невозможности восстановления исходного кода.
Сборка frontend определена в frontend/Dockerfile: Node.js, установка зависимостей
через npm ci --legacy-peer-deps --no-audit --no-fund, затем npm run build.
Результат dist/ помещается в образ NGINX. Это создание статических HTML/JS/CSS,
а не передача клиенту среды Node.js для исполнения серверной части.
Точные версии инструментов, базовых образов и зависимостей устанавливаются
по Dockerfile/lock-файлам и манифесту конкретного выпуска, а не по слову latest.
Объектный код распространяется в контейнерных образах: backend с .so/.pyc,
frontend со статикой и вспомогательные образы. images.tar содержит экспорт
образов; установщик .run и файловый архив содержат этот экспорт, конфигурацию,
миграции и скрипты. ARTIFACT-MANIFEST.json, VERSION, SHA256 и ID образов
связывают комплект с версией и состоянием исходников. Для изменённого рабочего
дерева дополнительно фиксируются признак dirty и SHA256 исходного snapshot:
один commit не идентифицирует незакоммиченные изменения.
Хранение исходников, сборочных журналов, исходных snapshot, объектных образов и выпускаемых архивов организуется в закрытых хранилищах с разграничением прав на чтение, изменение и публикацию. Публикационный каталог выдаёт получателю только согласованные файлы; учётные данные скачивания передаются отдельно. Резервировать нужно также Git-историю, lock-файлы, Dockerfile, сборочные средства, манифесты и эталонные суммы. Резервные копии исходного/объектного кода следует хранить отдельно от основной площадки, ограничивать доступ и периодически проверять восстановление. Наличие этого порядка не подтверждает, что его фактическое исполнение уже проверено.
Данные для окончательной редакции: правообладатель подтверждает адреса и страну хранилищ и сборочных площадок, технические средства, ответственных и регламент резервирования. Эти сведения пока не предоставлены; раздел не подтверждает фактическое размещение инфраструктуры.