Iris — Кросс-платформа, личный кабинет, активация, биллинг, автообновление¶
Архитектура того, как Iris продаётся и доставляется клиентам: установка на разных ОС,
личный кабинет (лицензии/оплата/активация) и качественное автообновление в течение
оплаченного периода (например, €5000/год → год обновлений). Опирается на уже
построенный слой лицензирования (app/licensing/, scripts/issue_license.py,
docs/LICENSE_SERVER_SPEC.md).
0. Главное ограничение: GPU решает, что такое «кросс-платформ໶
Iris — это ИИ на NVIDIA CUDA + Docker. Поэтому «любой может запустить на чём угодно» для GPU-нагрузки нереалистично. Честная матрица:
| ОС | GPU-путь | Статус | Как |
|---|---|---|---|
| Linux | NVIDIA Container Toolkit | ✅ основной | Docker + toolkit (как сейчас) |
| Windows 10/11 | WSL2 + Docker Desktop + NVIDIA-драйвер | ✅ полноценно | CUDA работает в контейнере через WSL2 (production-ready с Docker Desktop 3.1) |
| macOS | нет NVIDIA/CUDA | ⚠️ только CPU / eval | CPU-режим (деградация ~7 ядер/камеру) или порт под Apple Silicon (ONNX CoreML/MPS — отдельный большой труд) |
Вывод: продаём для Linux и Windows (обе — с GPU). macOS — только демо/CPU или «не поддерживается для продакшена». Так и говорим клиентам — это честно и снимает завышенные ожидания.
1. Модель дистрибуции: тонкий нативный агент поверх ОДНОГО контейнерного стека¶
Не переписываем Iris под каждую ОС. Тяжёлое приложение остаётся тем же Linux-контейнером; кросс-платформенность даёт тонкий «Iris Agent» на каждую ОС:
- Windows: установщик (.exe/MSI, напр. Inno Setup или Tauri-обёртка) который: проверяет/ставит WSL2 + движок Docker, грузит образ Iris, поднимает compose-стек как службу, открывает локальный веб-UI; живёт в системном трее.
- Linux:
.deb/.rpmили shell-инсталлятор: ставит Docker + NVIDIA toolkit + стек + systemd-сервис. - macOS (если решим): CPU-only eval-сборка.
Агент отвечает за: первичную настройку, активацию лицензии (общается с порталом), автообновление, health, открытие браузера на локальный UI. Это и есть кросс-платформенный слой; ядро не меняется.
2. Личный кабинет (наше облако)¶
Веб-приложение + API (наша инфра). Что даёт клиенту:
- Аккаунты/организации: регистрация, команда, роли.
- Тарифы и оплата: подписка (напр. €5000/год). Платёжки: Stripe (международный) + YooKassa / CloudPayments / ЮMoney (РФ). Self-service через Stripe Billing Customer Portal (продление/отмена/счета).
- Лицензии: при покупке портал выпускает подписанную лицензию (серверный
issue_license), привязанную к отпечатку железа клиента, со сроком = конец оплаченного периода и тиром (камеры/модули). Управление активациями: посмотреть/сбросить привязку (перенос на другое железо). - Загрузки: установщики под каждую ОС + офлайн-бандлы (sealed-образ + модели) для air-gap.
3. Поток активации (ложится на уже построенное)¶
1. Клиент оформляет подписку в кабинете → Stripe/YooKassa webhook → провижининг.
2. Кабинет выдаёт короткоживущий activation token.
3. Клиент ставит Agent, вводит token (или логинится).
4. Agent считает hardware fingerprint → app/licensing/fingerprint.py ✅ готово
и шлёт token + fingerprint в кабинет.
5. Кабинет подписывает лицензию (привязка к fingerprint, expiry, тир) →
scripts/issue_license.py ✅ готово
6. Agent кладёт license.json; Iris проверяет (app/licensing) ✅ и применяет enforcement ✅
(лимит камер + модули, fail-open).
7. Периодический heartbeat (app/licensing/heartbeat.py ✅) → license-server подтверждает,
что подписка активна; grace-период держит air-gap/обрыв связи.
Зелёным — то, что уже реализовано в кодовой базе. Облачная часть (портал, биллинг, license-server) — то, что нужно построить.
4. Автообновление в течение оплаченного периода (ключевой механизм «€5000/год»)¶
Не использовать Watchtower — он архивирован (дек. 2025) и не умеет ни подпись, ни откат. Строим небольшой свой updater в составе Agent:
- Update-server (облако) публикует подписанные релизы: дайджест образа + подпись (Cosign/Sigstore или наш ключ) + changelog + min-version + канал (stable/beta).
- Updater в Agent:
- периодически (или на heartbeat) спрашивает update-server о новой версии в канале клиента;
- гейт по подписке: обновления предлагаются, только пока лицензия/подписка активна — это и есть «оплатил год → год обновлений»;
- скачивает подписанный артефакт (tar образа или pull из приватного реестра), проверяет подпись;
- применяет blue-green / backup-and-rollback: оставляет предыдущий образ, health-check нового, авто-откат при сбое (паттерн docker-updater, не Watchtower);
- поэтапный rollout (canary %) + авто-откат по здоровью.
- Air-gap: офлайн-бандлы обновлений из кабинета, применяются вручную/USB.
Политика при окончании подписки (важно для системы безопасности — нельзя «окирпичить»): последняя установленная версия продолжает работать, но обновления прекращаются + видимый статус «подписка истекла». Жёсткую остановку не делаем (heartbeat-grace это уже учитывает).
5. Что нужно построить в облаке (бэкенд всего этого)¶
| Сервис | Назначение | Статус |
|---|---|---|
| Портал (web + API) | аккаунты, загрузки, управление устройствами | ⬜ строить |
| Биллинг | Stripe + РФ-провайдер, webhooks → провижининг лицензии | ⬜ строить |
| License-server | выпуск + heartbeat/отзыв | 🟡 спека готова (LICENSE_SERVER_SPEC.md), код — ⬜ |
| Update-server | каталог подписанных релизов + хостинг артефактов | ⬜ строить |
| Приватный реестр / CDN | образ Iris (или подписанные tar) | ⬜ |
| Ключи подписи | лицензии (RSA ✅ есть) + образа (Cosign) | 🟡 |
| Telemetry/health (opt-in) | поддержка | ⬜ |
6. Связка «подписка ↔ лицензия ↔ обновления» (бизнес-механика)¶
- Подписка активна → лицензия валидна (
expires= конец периода, продлевается webhook’ом при оплате) → heartbeat OK → обновления доступны. - Подписка не продлена → лицензия истекает после grace → enforcement (cap/warn) + обновления останавливаются; последняя версия работает. Видимый статус в UI + кабинете.
7. Дорожная карта (поверх готового фундамента)¶
- Фаза 0 (готово): примитивы лицензий — отпечаток, sign/verify, heartbeat, enforcement, инструментарий выпуска.
- Фаза 1: Updater + update-server + подписанные релизы (Linux). Сам механизм автообновления.
- Фаза 2: Портал + Stripe/РФ-биллинг + авто-выпуск лицензии при оплате.
- Фаза 3: Windows-установщик (WSL2 + Docker Agent).
- Фаза 4: Офлайн-бандлы обновлений + управление активациями/сброс устройств.
- Фаза 5: macOS eval (CPU) — по спросу.
8. Риски и честные ограничения¶
- GPU — главный ограничитель. «Любая ОС» для GPU-ИИ нереальна: Linux + Windows(WSL2); macOS — CPU/eval.
- Лицензии моделей (GA-блокер из
docs/LICENSING.md) действуют независимо от дистрибуции — решить ДО коммерческой продажи где угодно. - Безопасность обновления системы видеонаблюдения: никогда не «кирпичить» — подпись + health-gated откат + «последняя версия продолжает работать».
- Это большая облачная/бизнес-стройка (портал + биллинг + update-инфра) — месяцы работы и эксплуатация. Фундамент на стороне устройства уже есть; облачная часть — впереди.
Связано: docs/LICENSE_SERVER_SPEC.md (формат лицензии + heartbeat), docs/APPLIANCE_DEPLOYMENT.md,
docs/PRICING.md, scripts/issue_license.py / gen_vendor_key.py, app/licensing/.