Обновление и откат

Перед обновлением

1. Зафиксируйте текущую версию сервера, агента, протокола и сборочный пакет агента.
2. Создайте согласованную копию PostgreSQL, ClickHouse, объектов S3, конфигурации и ключей и проверьте восстановление.
3. Сохраните текущий EXE-релиз агента, legacy ZIP-релиз при наличии, манифесты, SHA-256 и ключи подписи.
4. Проверьте миграции, регистрацию тестового агента и совместимость политик на staging.
5. Определите окно обслуживания и способ отката.

Обновление сервера

cd server
docker compose config --quiet
docker compose build --no-cache
docker compose up -d
docker compose ps
docker compose exec app python -c "import urllib.request; print(urllib.request.urlopen('http://127.0.0.1:5000/api/health/ready').status)"

Контейнер db-init выполняет инициализацию и миграции до запуска приложения. В команде readiness выше указан базовый путь /; при публикации под /roy используйте /roy/api/health/ready. После обновления проверьте вход в интерфейс, рабочие области, регистрацию тестового агента, получение политики, события, инциденты, Socket.IO и загрузку пакета агента.

Обновление пакета агента

Перед публикацией проверяют версию агента, совместимость протокола, происхождение и контрольную сумму пакета, доступность штатного установщика. Основной EXE-сценарий использует защищённую выдачу и SHA-256; проверка подписи Ed25519 манифеста относится к legacy ZIP-сценарию. Проверка контрольной суммы и проверка подписи имеют разное назначение.

Автоматическое обновление агентов

Сервер публикует актуальную версию, SHA-256 и ссылку на пакет через API версии агента. При heartbeat клиент сообщает свою версию; сервер может создать задание обновления и выдать одноразовый grant на скачивание.

Для Windows основным auto-update package является EXE-установщик с installer_type=exe. Агент скачивает его по grant, проверяет SHA-256 и запускает CopkaRoySetup.exe /quiet /auto-update /install-path .... Режим auto-update требует существующую валидную identity и не использует новый registration key. Legacy ZIP-путь с CopkaRoyUpdater.exe остаётся fallback: он проверяет подпись Ed25519 манифеста и SHA-256 каждого файла. Launcher коммитит новую версию только после локальной health/readiness проверки.

Процентная волна и аварийная остановка

Участники волны выбираются детерминированно по workspace, версии релиза и client_id. Поэтому увеличение процента расширяет стабильную выборку, а повторный запуск с тем же значением не выбирает случайно другие компьютеры. Рекомендуемый порядок: 1% → 10% → 25% → 50% → 100%.

Процент рабочей области читается и изменяется через GET/PATCH /roy/api/v1/owner/workspaces/<workspace_uuid>/agent-update-rollout. PATCH принимает JSON {"percentage": 25}, отменяет только состояния queued и leased и пересчитывает очередь. Значение Owner API переопределяет .env только для выбранной рабочей области.

Кнопка «Остановить обновления» является отдельным аварийным рубильником. Она сохраняет паузу в настройках рабочей области, блокирует ручную и автоматическую очередь и аннулирует неиспользованные grants. Уже выполняющиеся установки намеренно не обрываются.

Откат

1. Сначала остановите распространение обновления в разделе установки агента.
2. Для агента предпочтительно выпустите код последней исправной сборки под следующим номером версии — это безопасное исправление вперёд.
3. Локальный launcher автоматически возвращает предыдущий слот, только если новая версия не запускается или не проходит readiness до commit.
4. Остановите новую версию серверного приложения.
5. Верните прежний образ, compose-конфигурацию и .env.
6. Если миграция несовместима назад, восстановите дамп PostgreSQL на отдельную БД и переключите приложение.
7. Убедитесь, что плохой пакет больше не выдаётся, а процент новой волны не увеличивается.
8. Выполните smoke-тест и задокументируйте причину отката.

Согласованность версии и базы данных

Этот комплект документации описывает только СОПКА.Рой 1.0.0. Описание процедуры обновления не является объявлением других выпусков. До применения поставки проверьте совместимость схемы и сохраните восстановимую копию всех постоянных хранилищ.

Миграции Alembic выполняются отдельным db-init под учётной записью мигратора. Не запускайте старую и новую схему записи произвольно одновременно. Откат контейнера не откатывает PostgreSQL, ClickHouse и S3; план возврата включает совместимую схему или согласованное восстановление данных. Начатое обновление агента и ещё не выданное предложение обновления обрабатываются по-разному.

Приёмка после обновления

Проверьте вход и роли, выбранную область, heartbeat тестового клиента, получение политики, доставку события через worker в ClickHouse, открытие существующего объекта S3 и выполнение безвредной команды. Только готовность HTTP-порта не подтверждает работоспособность всего комплекса.

Нагрузка при распространении

Бюджет 1000 одновременно работающих агентов в «Системных требованиях» не включает одновременное скачивание пакета всей сетью. Процент волны определяет долю выбранных клиентов, а лимит параллельности - число одновременно выполняемых обновлений; эти ограничения не взаимозаменяемы. Полосу, временные файлы, запас диска и работу старых и новых экземпляров сервера учитывают отдельно. После обновления на прежнем профиле проверяют задержки, ошибки и рост очереди.

Обновление AI-чата и схемы

История диалогов и учёт квот входят в PostgreSQL; обновление интерфейса не сбрасывает их. Текущая схема объединена в первую миграцию 0001. Для принятия прежних ревизий оператор создаёт резервную копию и проверяет структуру; пересоздание базы для обновления не требуется.

Подробнее: AI-чат: анализ безопасности.