Эксплуатация

Настройка через ИИ (MCP)

Сервер MCP: помощник заводит серверы, хранилища и задания через тот же проверенный API.

В Unruin встроен сервер MCP — чтобы помощник с искусственным интеллектом (Claude Desktop, Cursor, любой клиент MCP) мог его настроить и вести: заводить серверы, хранилища и задания, класть секреты, запускать копирование, показывать точки восстановления и разворачивать их. Обычными словами.

Сервер MCP — тонкий мост к собственному HTTP API Unruin, поэтому всё, что делает помощник, проходит ту же проверку, ту же атомарную запись конфигурации и тот же вход, что и панель. Своей привилегированной логики у него нет.

Как это устроено

клиент ИИ  ──stdio(MCP)──▶  unruin mcp  ──HTTP+ключ──▶  unruin serve  ──▶  jobs.yaml

unruin mcp говорит на MCP (JSON-RPC 2.0) через стандартный ввод-вывод и зовёт работающий unruin serve по HTTP. Значит, serve должен быть поднят, а процесс MCP — до него дотягиваться.

Настроить

Направьте клиента MCP на бинарник unruin и задайте две переменные:

UNRUIN_API_URL — где слушает serve (по умолчанию http://127.0.0.1:8080).
UNRUIN_API_TOKEN — ключ API (обязателен, если serve не на loopback без входа). Значение то же, что у сервера.

Пример конфигурации клиента (Claude Desktop, claude_desktop_config.json):

json

{
  "mcpServers": {
    "unruin": {
      "command": "/usr/local/bin/unruin",
      "args": ["mcp"],
      "env": {
        "UNRUIN_API_URL": "http://127.0.0.1:8080",
        "UNRUIN_API_TOKEN": "ваш-ключ"
      }
    }
  }
}

Работаете в Docker? Направьте клиента на docker exec -i <контейнер> unruin mcp (-i держит стандартный ввод открытым) или запустите бинарник на хосте против опубликованного адреса API.

Что помощник получает в руки

Инструмент	Что делает
`unruin_health`	сколько заданий, сколько сбоев, состояние хранилища секретов, какие есть серверы и хранилища
`list_jobs` / `list_servers` / `list_destinations`	прочитать текущую конфигурацию
`set_secret`	положить ключ SSH или ключ хранилища (только на запись), ссылка вида `kr://<имя>`
`add_server` / `test_server`	добавить цель для копий (SSH); сначала проверить связь
`add_storage` / `test_storage`	добавить хранилище (папка / s3 / sftp); проверить доступность
`create_job`	завести задание (источник + хранилища + расписание + сколько хранить)
`trigger_run`	запустить задание сейчас
`list_snapshots`	точки восстановления задания и готовый лист восстановления
`restore`	развернуть точку восстановления на нужном хосте (на стороне сервера, без скачивания)

Как выглядит разговор «настрой мне»

Помощник по порядку:

set_secret — закрытый ключ SSH → kr://ssh/vps1.
test_server, затем add_server (адрес, пользователь, ssh_key: kr://ssh/vps1).
set_secret — ключ хранилища → kr://repo/backups.
test_storage, затем add_storage (например, хранилище по sftp со ссылками repo_password и ssh_key).
create_job (источник docker_volume/files/postgres, хранилище как dest, расписание schedule в формате cron).
trigger_run, чтобы убедиться, что работает; дальше list_snapshots и restore, когда понадобится.

Про безопасность

Сервер MCP умеет всё, что умеет ключ API, — относитесь к ключу как к паролю. Держите serve на loopback за обратным прокси с TLS или в закрытой сети.
Значения секретов ходят только в одну сторону: set_secret кладёт их в шифрованное хранилище, обратно не читает никто — ни один инструмент не возвращает значение секрета.
Восстановление никогда не льёт данные клиенту: restore раскладывает их по пути на нужном хосте и возвращает только этот путь (см. RESTORE.md).