Документация Adapstory
Плагины

Жизненный цикл и деплой

Как плагины устанавливаются, обновляются, откатываются и выводятся из эксплуатации.

У плагинов детерминированный жизненный цикл, за который отвечает BC-02 (Plugin Lifecycle). Понимание этого — разница между гладким upgrade'ом и ночной страничкой на отозвание.

Состояния

DRAFT ──▶ SIGNED ──▶ VERIFIED ──▶ INSTALLING ──▶ ACTIVE
                                       │             │
                                       ▼             ▼
                                    FAILED       UPGRADING ──▶ ACTIVE
                                       │             │
                                       ▼             ▼
                                   ROLLED_BACK   ROLLED_BACK
  • DRAFT — вы запушили образ, но не подписали.
  • SIGNED — Cosign-подпись есть, SBOM прикреплён.
  • VERIFIED — BC-02 верифицировал цепочку подписи + SLSA provenance. Доступен для установки.
  • INSTALLING — BC-19 provisionит namespace, секреты, network policy. Pod стартует.
  • ACTIVE — probes зелёные, MCP-инструменты зарегистрированы в BC-01.
  • UPGRADING — новая версия раскатывается blue/green или canary (ваш выбор).
  • FAILED / ROLLED_BACK — явные терминальные состояния. В audit log причина.

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

adapstory plugin build --version 0.2.0     # собирает образ + SBOM
adapstory plugin sign                      # Cosign + SLSA
adapstory plugin publish                   # → VERIFIED

Публикация не устанавливает. Тенанты или админы ставят явно, либо install-policy автопромоутит.

Install-политики

Тенанты могут настроить:

  • pinned — устанавливать только явно выбранную версию.
  • minor-auto — автоустанавливать minor-бампы той же major.
  • canary — ставить на процент пользователей сначала, промоут при здоровье.

Задаётся в админке или adapstory tenant set-policy.

Стратегии upgrade

Декларируются в spec.runtime.upgrade:

spec:
  runtime:
    upgrade:
      strategy: canary            # canary | blueGreen | rolling
      canarySteps:
        - { weight: 10, pauseSeconds: 300 }
        - { weight: 50, pauseSeconds: 600 }
        - { weight: 100 }
      healthGate:
        slo:
          errorRate: 0.01
          p99LatencyMs: 300

Если SLO пробивается на любом шаге, BC-02 автоматически откатывается.

Откат

Ручной:

adapstory plugin rollback hello-learner --tenant <tid> --to 0.1.9

Автоматический: health gate fail, Kyverno denial, 5 подряд crash-loop рестартов.

Откаты идут только назад через known-good версии (прежние ACTIVE состояния). Нельзя откатиться на версию, которая никогда не активировалась в этом тенанте.

Миграции схемы

Если новая версия меняет модель данных (BC-15), BC-02 запускает миграции перед раскаткой pod'ов.

Правила:

  • Additive миграции (новая колонка, индекс): автоматически, forward-compatible.
  • Переименования / смены типов: требуют двухверсионной миграции — v1.2 добавляет новое, v1.3 дропает старое.
  • Destructive миграции (drop column, drop table): требуют явной апрувалы админа.

Если миграция падает, весь install/upgrade падает — старая версия продолжает работать.

Вывод из эксплуатации

Удалить плагин из тенанта:

adapstory plugin uninstall hello-learner --tenant <tid>

Это:

  1. Снимает MCP-инструменты с BC-01 (LLM перестают их видеть мгновенно).
  2. Сливает Kafka consumers.
  3. Ждёт 30 секунд, пока in-flight вызовы завершатся.
  4. Удаляет namespace (и секреты — копии в Vault остаются).
  5. Помечает install как RETIRED в audit.

Данные в BC-15 схемах сохраняются, если админ явно не запросил удаление.

Multi-tenant раскатка

Когда вы публикуете 0.2.0, тенанты не обновляются синхронно — каждый уважает свою install-политику. Отслеживать здоровье в real world можно так:

adapstory plugin stats hello-learner

Вывод: какие тенанты на какой версии, error rate, LLM-spend, p99 latency.

Далее: Observability.

On this page