Хранение и компиляция кода

Настоящий документ описывает технические средства хранения исходного текста и объектного кода программы «Парсвайс», а также технические средства компиляции исходного текста в объектный код в том виде, в котором они используются на дату редакции. Правообладатель программы — индивидуальный предприниматель Крылов Руслан Хуважиевич.

1. Хранение исходного текста

Исходный текст программы хранится в системе контроля версий GitVerse компании СберТех. Серверы GitVerse размещены на территории Российской Федерации. Репозитории находятся в организации правообладателя parsewise.

Репозитории закрытые: анонимный доступ к ним отсутствует. Доступ на чтение и запись имеет только правообладатель, подключение выполняется по протоколу SSH с ключом правообладателя. Третьим лицам доступ к исходному тексту не предоставляется.

В репозиториях хранится полная история изменений: каждое изменение зафиксировано с описанием, автором и датой. Выпуски виджета отмечены тегами вида v3.12.5. Рабочие копии репозиториев находятся на компьютере правообладателя, с которого выполняется сборка (раздел 3).

2. Хранение объектного кода

Места хранения

Все места хранения объектного кода находятся в Яндекс Облаке, регион ru-central1, на территории Российской Федерации.

Запись в реестры и в хранилище выпусков выполняется только учётными записями правообладателя. Образы из реестра облачной установки получает кластер Kubernetes правообладателя по сервисной учётной записи; наружу этот реестр не предоставляется. Заказчику, устанавливающему программу в своём контуре, выдаётся отдельная учётная запись с доступом только к образам его поставки в реестре поставки.

Версии и неизменность

Каждый образ контейнера идентифицируется контрольной суммой SHA-256. Содержимое образа с данной контрольной суммой изменить нельзя: любое изменение даёт образ с другой контрольной суммой.

• Сервер программного интерфейса и панель управления выкатываются из основной ветки и номеров версий не имеют. Очередной образ получает тег latest; предыдущий образ остаётся в реестре без тега и удаляется правилом очистки через 7 дней, что позволяет вернуться к нему. Выкатка однозначно определяется коммитом в GitVerse, из которого собран образ, и может быть собрана из него повторно.
• Сервис векторизации хранится с тегом, содержащим версию сервера инференса и ревизию модели; манифесты Kubernetes ссылаются на образ по контрольной сумме.
• Реестр поставки: теги выпусков не перезаписываются, тег latest не используется.
• Виджет выпускается версиями по семантической нумерации, текущая версия — 3.12.5. Каждый выпуск размещается по отдельному пути, содержащему номер версии, например releases.parsewise.ru/widget/3.12.5/widget.iife.js, и отдаётся с признаком неизменяемого содержимого. Номер версии увеличивается при каждом выпуске, поэтому файлы опубликованного выпуска не перезаписываются; ранее выпущенные версии остаются доступны по своим адресам. Путь widget/latest/ указывает на последнюю выпущенную версию. Файл manifest.json каждого выпуска содержит номер версии, время выпуска и адреса файлов.

3. Технические средства компиляции

Компиляция и сборка выполняются правообладателем на его компьютере под управлением macOS скриптами, которые хранятся в репозиториях программы. Внешних систем непрерывной интеграции в цепочке сборки нет. Образы контейнеров собираются для платформы linux/amd64 и сразу загружаются в реестр.

Общие средства

Токены доступа к реестрам пакетов передаются в сборку образа как секреты BuildKit и в слои образа не попадают.

Сервер программного интерфейса

Исходный текст на Python исполняется интерпретатором, входящим в образ, поэтому объектным кодом сервера является образ контейнера: базовый образ, системные пакеты, Python-пакеты и исходный текст сервера. Python-пакеты устанавливаются командой pip install --no-index из склада пакетов, подключаемого по контрольной сумме; на этом шаге сеть отключена. Один образ запускается в трёх процессах: сервер программного интерфейса, обработчик очередей и планировщик задач.

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

Порядок сборки: npm ci устанавливает пакеты через реестр-посредник правообладателя, next build компилирует исходный текст на компьютере правообладателя, затем Docker по файлу Dockerfile.prebuilt упаковывает результат компиляции в образ с Node.js 24 и библиотекой обработки изображений sharp 0.33.5 для linux/amd64. Шрифт интерфейса хранится в репозитории и при сборке не загружается. В репозитории также хранится многоэтапный Dockerfile, выполняющий ту же компиляцию целиком внутри контейнера из тех же источников.

Виджет

Выпуск выполняется командой npm version: она устанавливает пакеты через реестр-посредник правообладателя (скрипт scripts/npm-ci-proxy.sh), собирает бандл командой vite build, фиксирует номер версии коммитом и тегом, отправляет их в GitVerse и размещает файлы выпуска в Yandex Object Storage (скрипт scripts/deploy.js).

Сервис векторизации

Сервис векторизации собственного исходного текста не содержит и не компилируется. Его образ собирается скриптом images/embedder/build.sh из репозитория k8s: к копии сервера инференса text-embeddings-inference версии cpu-1.6 добавляются файлы модели векторизации deepvk/USER-bge-m3 зафиксированной ревизии и её лицензия. Перед сборкой контрольная сумма файла весов модели сверяется с опубликованной.

Развёртывание

Собранные образы разворачиваются в кластере Yandex Managed Service for Kubernetes правообладателя, зона доступности ru-central1-a. Скрипт деплоя перезапускает развёртывание командой kubectl rollout restart и дожидается готовности новых экземпляров командой kubectl rollout status. Манифесты Kubernetes хранятся в репозитории k8s.

4. Сторонние компоненты при сборке

Все сторонние компоненты, необходимые для сборки, сборка получает из собственных хранилищ правообладателя в Яндекс Облаке и из российского зеркала пакетов. Зарубежные индексы пакетов и реестры образов контейнеров, в том числе Docker Hub, PyPI и registry.npmjs.org, при сборке не используются.

Копии базовых образов создаются скриптом scripts/mirror-images.sh из репозитория k8s. Склад Python-пакетов формируется заранее скриптом scripts/build-wheelhouse.sh из репозитория back-fastapi: пакеты по файлу requirements.lock получаются через реестр-посредник правообладателя parsewise-pypi-proxy в Yandex Cloud Registry и упаковываются в образ. Реестры-посредники при первом запросе пакета получают его из публичного реестра и сохраняют в своём хранилище; сборка обращается только к реестру-посреднику.

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

Контакты

• Правообладатель: индивидуальный предприниматель Крылов Руслан Хуважиевич
• ИНН: 772373909220
• ОГРНИП: 322774600593457
• Техническая поддержка: help@parsewise.ru