Раздел 2. Описание операций технологического процесса¶

2.1. Окружения и развёртывание¶

Ландшафт BOX5-DIT-MGSN включает три контура: DEV, TEST и PROD. DEV используется для разработки и первичной проверки изменений исполнителем, TEST - для проверки поставки перед переносом в промышленную эксплуатацию, PROD - для рабочего контура заказчика. Контуры должны иметь согласованный состав доменов, образов и конфигурационных параметров, влияющих на бизнес-логику. Различия ограничиваются назначением контура, количеством подключённых камер, топологией узлов и способом интеграции с ПК-КОТ: в TEST используется сокращённый набор камер и заглушка интеграции, в PROD - полный промышленный набор камер и штатное подключение к ПК-КОТ.

Подробный состав подсистем приведён в приложениях С2 и С4. В настоящем разделе фиксируется операционный порядок развёртывания и обслуживания окружений.

Единая deployment-схема с размещением узлов, доменов, контейнерных групп, хранилищ, брокеров сообщений, песочницы Node-RED и внешних подключений приведена в И3, подразделе 1.2. В И2 эта схема не дублируется: технологические операции ниже выполняются относительно указанной в И3 схемы размещения. Физическая сетевая топология площадки заказчика, включая VLAN, маршрутизацию, межсетевые экраны и внешние балансировщики, находится в зоне ответственности заказчика и в настоящем документе намеренно не описывается.

Исходный Mermaid-код схемы: И2-MER-002. 2.1. Окружения и развёртывание.

2.2. Процедура развёртывания¶

Изменения проходят последовательность DEV -> TEST -> PROD. Развёртывание PROD выполняется после успешной проверки той же версии дистрибутива на TEST. Для TEST применяется та же последовательность, но с тестовым набором камер и параметрами заглушки ПК-КОТ. Целевой TEST-контур разворачивается как кластер из одной мастер-ноды и двух вычислительных нод, PROD - как кластер из одной мастер-ноды и 11 вычислительных GPU-нод.

2.2.1. Проверка предварительных условий¶

До установки дистрибутива администратор проверяет состав системного ПО и состояние узлов.

На всех узлах должны быть установлены утилиты: ca-certificates, curl, gnupg, tmux, vim, nano, autossh, htop, tcpdump, lsb-release, nload, nmap, ffmpeg, ncdu, jq, dnsutils, net-tools, python3.

На вычислительных нодах с GPU файл /etc/docker/daemon.json должен задавать NVIDIA runtime как runtime по умолчанию:

{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "live-restore": false,
    "storage-driver": "overlay2",
    "log-opts": {
        "max-file": "10",
        "max-size": "100m"
    }
}

После установки драйверов на вычислительных нодах отключается переход в сон и гибернацию:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

На мастер-ноде и вычислительных нодах с GPU должен быть отключён swap, если это требуется эксплуатационным профилем площадки. Для узлов, где запускаются медиасервер и инференс, также должны быть подготовлены tmpfs-каталоги, используемые межпроцессным обменом и HLS-данными:

tmpfs   /mnt/ram0    tmpfs   rw,nodev,nosuid,size=1G           0  0
tmpfs   /tsm_tmpfs   tmpfs   rw,nodev,nosuid,size=16G,mode=0777 0  0

2.2.2. Подготовка дистрибутива и каталогов данных¶

На исходном сервере подготовить архив Docker-образов:

docker save $(docker images --format '{{.Repository}}:{{.Tag}}') \
  | gzip > /data/update/dockerimg.tgz

Если команда завершается с ошибкой из-за нетегированных образов, перед повторной подготовкой архива удалить неиспользуемые Docker-объекты командой docker system prune по согласованию с ответственным администратором.

Каталог с основными конфигурационными файлами переносится на мастер-ноду:

sudo rsync -avzh /home/esik/CODE esik@<master_node>:/home/esik/

Архив dockerimg.tgz должен быть перенесён на все ноды кластера и загружен:

docker load -i /data/update/dockerimg.tgz

Значение COMPOSE_DATA_SWARM_PATH в файле ~/CODE/box3/utils/swarm/swarm.sh должно совпадать на всех целевых серверах. Базовое значение для поставки:

COMPOSE_DATA_SWARM_PATH="/data/compose-data2"

На каждой ноде кластера создать каталоги данных приложения:

#!/usr/bin/env bash

COMPOSE_DATA_SWARM_PATH="/data/compose-data2"

mkdir -p "${COMPOSE_DATA_SWARM_PATH}/backups/st-access/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/backups/st-auth/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/asset-storage/assets/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/logs/events-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/logs/mediaserver/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/logs/nri_inference/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/logs/report-video-extractor/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/monitoring-redis-data/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/video-events-cropped/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/video-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/events-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/inf-load-balancer/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/load-balancer-redis-data/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference/inference_ipc/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/inference_ipc/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/converted/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/models-registry/models/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/lite-scenario-storage/lite-scenarios/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/scenario-storage/scenarios/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/report-pdf-xlsx-generator/reports/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/translations-store/translations/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/kafka3.4/kafka-data/config/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/kafka3.4/kafka-data/data/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/data-storage/minio_data/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/vc_videos/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/facecloud/person-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/archive-videos/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-asset-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-asutp/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-lite-scenario-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-models-registry/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-postgres-pk-kot/pgdata/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-scenario-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-severstal-integration/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/severstal/pgdata-translations-store/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/event-ex-clickhouse-data/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/event-statistic-clickhouse-data/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/event-storage-click-house-data/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/pgdata-camera-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/pgdata-comments/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/pgdata-event-storage/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/pgdata-object-visit-zone-counter/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/pgdata-report-email/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/pgdata-report-pdf-xlsx-generator/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/st-access-postgres/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/st-audit/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/st-auth-postgres/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/statistics/st-virt-cam-video-upload/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/ui-rest/logs/nginx"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/ui-rest/react/build/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/elk-log/grafana/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/elk-log/loki/"
mkdir -p "${COMPOSE_DATA_SWARM_PATH}/elk-log/prometheus/data/"

2.2.3. Настройка песочницы и моделей¶

На вычислительную ноду, где разворачивается песочница Node-RED, перенести данные песочницы:

rsync -avzh /data/sandbox-compose-data esik@<gpu_node>:/data/

На все вычислительные ноды перенести каталог моделей:

rsync -avzh /data/models esik@<gpu_node>:/data/
sudo chown -R 1000:1000 /data/models
sudo chown -R 1000:1000 /data/sandbox-compose-data

В каталоге ~/CODE/node-red-sandbox задать пути к данным, моделям и ассетам:

cd ~/CODE/node-red-sandbox/
sed -i 's|^COMPOSE_DATA_DIR=.*|COMPOSE_DATA_DIR=/data/sandbox-compose-data/|' .env
sed -i 's|^MLFLOW_MODELS_PATH=.*|MLFLOW_MODELS_PATH=/data/models|' .env
sed -i 's|^NRI_ASSETS_HOST_DIR=.*|NRI_ASSETS_HOST_DIR=/data/sandbox-compose-data/nri-assets|' .env

Архив sandbox-compose-data.tgz распаковать в каталог COMPOSE_DATA_DIR, а архив nri-models.tgz - в каталог MLFLOW_MODELS_PATH.

Если порт песочницы отличается от 80, задать NGINX_HOST_PORT и изменить порт в конфигурации nginx песочницы. Порт песочницы должен отличаться от порта web-интерфейса BOX5-DIT-MGSN:

cd ~/CODE/node-red-sandbox/
sed -i 's/^NGINX_HOST_PORT=.*/NGINX_HOST_PORT=<PORT>/' .env
sed -i 's/listen 80;/listen <PORT>;/' nginx/nginx.conf

В конфигурации песочницы задать адрес, по которому пользовательский интерфейс обращается к Node-RED:

cd ~/CODE/box3/node-red-sandbox/
sed -i 's/^REACT_APP_HOST_NAME=.*/REACT_APP_HOST_NAME=<IP>:<PORT>/' .env

Для интеграции песочницы с BOX5-DIT-MGSN задать URL загрузки сценариев на мастер-ноду:

cd ~/CODE/box3/node-red-sandbox/
sed -i 's|^BOX_POST_SCENARIOS_URL=.*|BOX_POST_SCENARIOS_URL="http://<master_ip>/api/severstal/severstal-lite-scenario-storage/upload-scenarios/"|' .env

В файле ~/CODE/box3/ui-rest/ui-config/config.json указать адрес iframe песочницы:

"SCENARIOS_FRAME_URL": "http://<sandbox_ip>:<PORT>/"

После изменения адресов проверить оставшиеся упоминания старого IP:

grep -inR <old_ip> ~/CODE/box3

2.2.4. Лицензия и параметры инференса¶

На мастер-ноде установить сервис лицензирования Guardant:

cd grdcontrol-3.25/
sudo ./install.sh
sudo systemctl restart grdcontrol.service

Серийный номер лицензии и тип активации фиксируются в корневом файле ~/CODE/box3/.env. Если поставка домена inference использует отдельный файл ~/CODE/box3/inference/.env, значения должны быть синхронизированы и в нём:

LICENSE_KEY_SERIAL=<key>
ACTIVATION_TYPE=offline

На вычислительных нодах количество потоков инференса должно соответствовать количеству GPU. Для сервера с восемью GPU:

LIST_GPU='[0,1,2,3,4,5,6,7]'
INFERENCE_COUNT=8

В закрытом контуре используется оффлайн-активация через HTTP API контейнера guardant-control-center на порту 19191.

1. Остановить кластер:

cd ~/CODE/box3/
./utils/swarm/swarm.sh stop

1. Перезапустить runtime лицензирования с очисткой локального состояния:

sudo systemctl stop grdcontrol.service
sudo rm -Rvf /var/guardant/
sudo systemctl start grdcontrol.service

1. Запустить только сервис лицензирования:

cd ~/CODE/box3/inference
docker network create my-network-name-inference
docker compose up -d inf-guardant-control-center

1. Сформировать файл запроса активации:

mkdir -p /tmp/activation
curl http://localhost:19191/get_request \
  | jq -r '.request' > /tmp/activation/request.request

1. Передать request.request для оффлайн-активации. Полученный файл request.license положить в каталог /tmp/activation.
2. Загрузить ответ активации:

jq -Rs '{response: .}' /tmp/activation/request.license \
  | curl -X POST http://localhost:19191/set_response \
      --header "Content-Type:application/json" \
      --data @-

1. Проверить успешную активацию:

docker logs inf-guardant-control-center | grep Activated

1. Остановить временно запущенный сервис лицензирования и удалить временную сеть:

cd ~/CODE/box3/inference
docker compose down
docker network rm my-network-name-inference

2.2.5. Инициализация кластера и назначение ролей¶

На мастер-ноде инициализировать Docker Swarm:

docker swarm init --advertise-addr <IP-адрес_мастер-ноды>

Если у сервера один подходящий сетевой адрес, допускается выполнить docker swarm init без явного --advertise-addr.

Команду docker swarm join, выведенную Docker, выполнить на каждой вычислительной ноде. После подключения проверить состав кластера:

docker node ls

Для размещения сервисов узлам назначаются роли через Docker labels.

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

docker node update --label-add <роль>=true <node_id>

Распределение ролей:

Примеры назначения ролей:

docker node update --label-add db=true <master_node_id>
docker node update --label-add rest=true <master_node_id>
docker node update --label-add inference=true <gpu_node_id>
docker node update --label-add nr_sandbox=true <sandbox_node_id>
docker node update --label-add flows_manager=true <sandbox_node_id>
docker node update --label-add events_validator=true <sandbox_node_id>

Проверка назначенных ролей:

docker node ls -q | xargs docker node inspect \
  -f '{{ .ID }} [{{ .Description.Hostname }}]: {{ .Spec.Labels }}'

2.2.6. Запуск, остановка и контроль развёртывания¶

Основные команды выполняются на мастер-ноде из каталога ~/CODE/box3.

Ожидаемый результат после запуска: все ноды имеют статус Ready/Active, а в docker service ls для штатных сервисов значение REPLICAS соответствует формату x/x. Для DEV, где роли совмещены на одной машине, аналогичная проверка выполняется командами docker compose ls, docker ps и docker logs по соответствующим доменам.

Песочница Node-RED запускается на выбранной вычислительной ноде:

cd ~/CODE/node-red-sandbox
docker compose up -d

После запуска песочницы выполнить конвертацию всех моделей внутри контейнера NRI:

docker exec -it $(docker ps | grep nr-sbx-nri | awk '{print $1}' | head -n1) bash
python3 -m nri.mlflow.tools.convert_all_models --models_filter_path /models/sel-models.csv
exit

Затем на одной из вычислительных нод зайти в контейнер инференса и выгрузить модели в хранилище моделей:

docker exec -it $(docker ps | grep inf-nri-inference | awk '{print $1}' | head -n1) bash
python -m nri.mlflow.tools.push_models_to_vlflow --models_filter_path /models/sel-models.csv
exit

Если после конвертации требуется распространить обновлённые модели вручную, на целевых вычислительных нодах предварительно сохранить старую директорию, а затем скопировать обновлённый /data/models с ноды-источника и назначить права:

sudo mv /data/models /data/models.old
rsync -a /data/models username@swarm-nodeX:/data/
sudo chown -R 1000:1000 /data/models

2.2.7. Настройка автозапуска¶

На мастер-ноде создать файл /etc/systemd/system/box-restart.service:

[Unit]
Description=Service for restarting box after boot
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c "mkdir -p /tmp/inference_ipc && ./utils/swarm/swarm.sh stop && ./utils/swarm/swarm.sh start"
User=<user>
WorkingDirectory=/home/<user>/CODE/box3

[Install]
WantedBy=multi-user.target

На вычислительной ноде создать файл /etc/systemd/system/box-restart.service:

[Unit]
Description=Service for restarting box after boot
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=mkdir -p /tmp/inference_ipc

[Install]
WantedBy=multi-user.target

После создания файла включить службу:

sudo systemctl enable box-restart.service

2.3. Файловый обмен (процедурная часть)¶

Подраздел описывает процедурный файловый обмен: передачу дистрибутивов, конфигурационных файлов, файлов лицензии, загружаемых видеозаписей, отчётов и служебных артефактов. Форматы API, схемы внешних систем и состав таблиц описываются в документах ПА и В7; здесь фиксируются действия администратора.

2.3.1. Способы передачи файлов¶

Обмен с ПК-КОТ не считается файловым обменом: в PROD используются PostgreSQL read-only и HTTP push статусов, а в TEST - заглушка интеграции. Для процедурной проверки TEST достаточно убедиться, что сервисы svr-postgres-pk-kot и svr-severstal-integration работают с изолированным тестовым источником и не обращаются к промышленному ПК-КОТ.

2.3.2. Форматы, каталоги и контроль целостности¶

Если в эксплуатационном регламенте площадки выделены отдельные каталоги incoming, work, archive и error, их абсолютные пути фиксируются в локальном журнале работ администратора. В поставке BOX5-DIT-MGSN штатные сервисы используют каталоги и объектные хранилища, приведённые ниже; ручная подмена файлов внутри контейнеров не является штатным файловым обменом.

Для всех потоков действуют общие правила:

1. Не смешивать файлы DEV/TEST/PROD в одном рабочем каталоге.
2. Не начинать обработку файла до завершения передачи и проверки контрольной суммы, если контрольная сумма предусмотрена паспортом поставки или журналом работ.
3. Для файлов, создаваемых через UI/API, источником истины является статус операции в сервисе и запись в БД/MinIO, а не наличие файла на файловой системе контейнера.
4. При повторной передаче сначала изолировать неполный файл или неготовую версию, затем повторить минимальную неуспешную операцию.
5. Не публиковать в документации и общих каналах содержимое .env, лицензий, токенов, приватных URL и файлов с персональными или промышленными данными.

2.3.3. Обработка ошибок¶

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

2.3.4. Архивирование¶

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

2.3.5. Повторная обработка файлового обмена¶

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

Повторная обработка не используется для повторного прогона производственных видеопотоков, пересчёта уже сохранённых событий, ручного изменения MinIO/DTS или восстановления повреждённых БД. Такие случаи относятся к восстановлению данных и разбору инцидентов по документам И3 и И2, раздел 3.

Общий порядок повторной обработки:

1. Установить и устранить первопричину ошибки.
2. Зафиксировать исходную ошибку и выбранное действие в журнале работ.
3. Удалить или изолировать частично переданный файл, если его нельзя достоверно проверить контрольной суммой.
4. Повторить только минимальную неуспешную операцию, а не весь регламент развёртывания.
5. Выполнить контроль из таблицы и продолжать работы только при успешном результате.

Для конфигурации после повторного применения исправленного CODE/.env выполнить перезапуск:

cd ~/CODE/box3
./utils/swarm/swarm.sh stop
./utils/swarm/swarm.sh start

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

2.3.6. Мониторинг поступления файлов¶

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

2.4. Регламенты обслуживания¶

Регламентные операции выполняются в обязательной последовательности: изменения первично проверяются на DEV, затем поставка проверяется на TEST, после успешного результата и создания резервной копии планируется окно PROD. Операции, влияющие на промышленный контур, выполняются администратором с фиксацией версии поставки, времени начала и окончания работ, результата проверок и выявленных отклонений.

2.4.1. Чек-лист после установки или обновления¶

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

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

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