Files

83 lines
5.0 KiB
Markdown

# Эксплуатация
`omnichannel-configserver-mcp` работает в **плоскости управления**: он видит статусы,
конфигурацию, задачи и историю, но не заглядывает внутрь контейнеров. Это
разделение осознанное — так сервер остаётся безопасным и предсказуемым.
## Что можно, а что нет
| Задача | Инструменты этого сервера | Вне него |
|---|---|---|
| Статусы сервисов и хостов | `overview`, `list_applications`, `service_map` | — |
| Аудит и разбор задач | `list_tasks`, `get_task`, `deployment_tasks` | — |
| Конфигурация compose/env, версии, откат | `get_application`, `get_config`, `env_files`, `compose_version`, `env_versions`, `restore_compose`, `restore_env_version` | — |
| Жизненный цикл сервиса | `deploy`, `restart`, `down`, `migrate` | — |
| Развёртывание релиза | `save_deployment_files`, `seed_hosts`, `fill_vars`, `download_release`, `release_job`, `start_services` | — |
| **Логи контейнеров** | — | отдельный MCP-сервер SSH/`docker logs` |
| **Ресурсы (CPU/RAM/диск)** | — | мониторинг (SSH, Zabbix, Prometheus) |
| **Данные в БД** | — | отдельный MCP-сервер для БД |
| **HTTP-проверки сервисов** | — | отдельный MCP-сервер для HTTP/веб |
Иными словами: этим сервером удобно отвечать на «что и с какой конфигурацией
развёрнуто и что сломалось при деплое», а диагностику рантайма подключайте
дополнительными MCP-серверами.
## Типовые сценарии
### «Что сейчас на стенде?»
> «Покажи сводку по стенду prod.»
`overview` вернёт health, статистику, сервисы не в статусе OK и последние
упавшие задачи — это самый быстрый «снимок».
### «Почему упал деплой?»
1. `list_tasks {status:"failed", limit:20}` — найти задачу.
2. `get_task {task_id}` — прочитать `output` (stdout/stderr). По умолчанию
оставляется **хвост** вывода, где обычно и причина; при необходимости
увеличить `output_bytes`.
3. При необходимости сравнить конфиг: `get_application {app_id}`.
### «Сервис не поднялся / зависает»
1. `get_application {app_id}` — статус, текущий compose/env, журнал миграций.
2. `list_tasks {host_ip, task_type}` — история операций по хосту.
3. Повторить контролируемо: `restart {app_id, wait:true}` и снова `get_task`.
4. Если внутри сервиса — переключиться на SSH-инструменты (логи).
### «Нужно поправить конфигурацию»
1. `get_config {app_id}` / `get_application {app_id}` — текущее.
2. `set_env` / `set_compose` — изменить (создаётся версия).
3. `deploy` или `restart` — применить на хосте.
4. Проверить `get_task`/`overview`. При неудаче — откат (`restore_*`).
### «Проверить релиз»
- `release_job` — статус фоновой выгрузки (фаза, прогресс образов).
- `deployment_tasks` — последние sync/start-задачи.
- `ip_match` — корректно ли сопоставлены хосты и агенты.
### «Обслуживание»
- `stats` — сколько версий и логов накопилось.
- `cleanup_old_versions {days:180, confirm:true}` — удалить устаревшие версии
(текущие не трогаются).
## Полезные фильтры
- `list_tasks` ограничивает выборку (`limit` ≤ 500) и фильтрует по `host_ip`,
`status`, `task_type`.
- `list_applications {include_presence:true}` включает служебные записи хостов
(хост без развёрнутых сервисов).
## Ограничения и защита
- Длинные выводы обрезаются (`max_output_bytes`), чтобы не переполнить контекст
ассистента.
- Ожидание задач (`wait`) ограничено `task_poll_max_sec`; если задача не успела —
вернётся её текущее состояние, а не ошибка.
- Мутации сериализуются на сервер (`max_concurrent_mutations`) — параллельные
`restart` не наложатся друг на друга.