5.1 KiB
Архитектура
Место в системе
┌────────────────┐ MCP (stdio, JSON-RPC) ┌──────────────────┐
│ MCP-клиент │ ◄──────────────────────► │ omnichannel-configserver-mcp │
│ (AI-ассистент)│ │ (этот сервер) │
└────────────────┘ └────────┬─────────┘
│ HTTP (session)
▼
┌──────────────────┐
│ config_server │
│ (Flask API/UI) │
└────────┬─────────┘
│ задачи агентам
▼
┌───────────────────────────┐
│ агенты на хостах │
│ docker-compose / swarm │
└───────────────────────────┘
omnichannel-configserver-mcp — тонкий клиент. Он не выполняет команды сам: создаёт задачи
через API config_server, а те забирают агенты нод. Сервер без состояния — при
перезапуске ничего не теряется.
Модель задач
Действия жизненного цикла (deploy, restart, down, migrate,
update_front, релизные операции) асинхронны:
- Инструмент вызывает API → создаётся задача → возвращается
task_id. - Агент ноды забирает задачу, выполняет
docker-compose, публикует результат. - Клиент опрашивает
get_taskдоcompleted/failed.
Поэтому у инструментов есть параметр wait: по умолчанию он выключен (loop
ассистента последовательный — не стоит его блокировать), а при wait=true
ожидание ограничено task_poll_max_sec и не считается ошибкой, если время вышло:
вернётся текущее состояние задачи.
Слои модуля
main.go каркас lifecycle: --health, -config, stdio
internal/configserver/ домен: без зависимостей от MCP
config.go разбор/валидация конфига, ${VAR}, merge local
session.go HTTP-клиент: cookie-сессия, релогin, ретраи GET
manager.go потокобезопасный диспетчер: конфиг, сессии, семафоры
api_*.go типизированные вызовы эндпоинтов config_server
internal/tools/ MCP-слой: разбор аргументов → вызов домена → текст
registry.go toolkit.go patterns.go util.go
observe.go configure.go operate.go release.go maintain.go overview.go
Правило разделения: домен тестируется без MCP; MCP-слой не содержит бизнес-логики.
Надёжность
- Сессия: Flask-cookie хранится в cookie-jar; login ленивый, при
401выполняется один повторный вход и один повтор запроса. - Повторы: только идемпотентные GET (сеть/5xx). Мутации не повторяются.
- Ограничения: context-deadline на каждый вызов, лимит на размер ответа, обрезка вывода, семафор мутаций на сервер.
- Ошибки: доменные (4xx/5xx с текстом, ошибки валидации) возвращаются как recoverable — ассистент видит причину и может исправить; инфраструктурные (сеть) — как ошибка протокола.
- Логи: только в stderr (stdout занят JSON-RPC), с маскированием секретов.
Логи и наблюдаемость
Логи модуля пишутся в stderr; уровень задаётся --log-level или OMNI_LOG_LEVEL
(debug|info|warn|error). HTTP-сервер config_server — источник данных о
задачах и статусах.