MCP для доступа, Docker для запуска: разбор

MCP подключает приложение к данным и действиям, Docker упаковывает программную среду для запуска. В офисе это часто два слоя одного решения, а не конкуренты. Покажу, где провести границу, как ограничить доступ и что проверить до запуска.

MCP и Docker решают разные задачи

Сравнивать MCP и Docker как два способа сделать одно и то же — ошибка уже в постановке вопроса. Model Context Protocol задаёт, как приложение получает данные и вызывает инструменты; Docker упаковывает программу с её зависимостями и запускает её в контейнере. Один отвечает за связь, другой — за среду выполнения. Поэтому в офисной схеме я обычно сначала выясняю, какие источники должны быть доступны приложению, а уже потом решаю, где и как запускать его компоненты. Для повторяемого запуска внутренних сервисов я бы рассмотрел внедрение open-source решений, но название технологии само по себе архитектуру не выбирает.

В MCP есть три роли. Хост — приложение, которым пользуется сотрудник; клиент MCP внутри него устанавливает связь; сервер MCP предоставляет конкретные данные или действия. Один хост может подключать несколько серверов, например отдельно к файловому источнику и внутреннему API. Значит, обязательного универсального «шлюза ко всему офису» протокол не создаёт: каждый сервер надо установить, настроить и проверить отдельно. Я предпочитаю такую схему, потому что её проще обсуждать с владельцем данных: вот источник, вот разрешённое действие, вот ответственный за интеграцию.

Для Docker вопрос другой: где собирать образ, где хранить конфигурацию и какие каталоги передавать приложению. Можно запустить процесс на рабочей станции, можно вынести его на отдельный узел; из наличия контейнера второй вариант автоматически не следует. Я не обещаю, что одна кнопка сразу соединит все программы и документы. Сначала фиксирую границы решения, иначе к обсуждению доступа быстро прирастает ещё и лишняя инфраструктура.

• MCP описывает обмен данными и вызов инструментов
• Docker упаковывает программную среду
• Обе технологии можно использовать вместе

Что именно открывает MCP-сервер

В спецификации MCP сервер может предоставлять три разных вида возможностей: Resources — данные для чтения, Prompts — подготовленные шаблоны, Tools — вызываемые функции. Это не три названия одной кнопки. Например, список файлов как ресурс и операция, которая меняет файл, должны иметь разные правила. Я отдельно проверяю, что именно объявляет конкретный сервер, потому что слово «MCP» в названии ничего не говорит о наборе доступных действий и их последствиях.

Транспорт тоже влияет на схему. Для локального подключения стандартный stdio передаёт сообщения через stdin и stdout: клиент запускает сервер как отдельный процесс и общается с ним через стандартные потоки. Для отдельного сервиса спецификация предусматривает Streamable HTTP. Это два способа связи, а не гарантия безопасных прав: HTTP-серверу нужны проверка происхождения запросов и аутентификация, а локальному процессу — аккуратно выданные права ОС. Я выбираю транспорт по тому, где должен работать клиент и кому нужен доступ.

Для GitHub и Docker уже встречаются готовые MCP-интеграции, поэтому я сначала проверяю решение поставщика, а не пишу соединитель с нуля. Это ускоряет старт, но не отменяет проверки исходного кода, списка разрешений и поведения при ошибке. Я начинаю с чтения и тестовых данных; изменение, удаление или отправка информации требуют отдельного согласования. Универсального режима «подключили сервер — безопасно открыли все источники» здесь нет.

• Resources — данные
• Prompts — шаблоны
• Tools — действия

Что контейнеризация сохраняет, а что нет

Docker-образ включает приложение и нужные ему программные зависимости. За счёт этого проще повторить конфигурацию на совместимых узлах и не смешивать библиотеки разных сервисов. Но обещание «на любой машине заработает одинаково» слишком широкое: контейнеры используют ядро хоста, а драйверы, архитектура процессора и доступное оборудование могут различаться. Контейнер изолирует процесс в заданных пределах, но не превращает его в отдельную виртуальную машину.

Для нескольких компонентов Docker Compose хранит описание сервисов, сетей, томов и параметров запуска в одном файле. Portainer может дать графический интерфейс для части операций, однако он не является обязательным слоем Docker и не заменяет понимание конфигурации. Я держу образ, настройки и пользовательские данные раздельно: так изменение приложения не должно случайно стать изменением архива документов. Если сервису нужны ограничения CPU или памяти, их надо задать явно; по умолчанию Docker не ограничивает потребление ресурсов контейнером.

Том Docker переживает удаление контейнера, который его использовал. Это полезно при пересоздании сервиса, но сам том не делает резервную копию, не хранит вторую копию на другом носителе и не проверяет восстановление. «Бэкап на том же томе» — билет обратно в ту же проблему. Для данных я задаю отдельное расписание копирования, место хранения и пробное восстановление. Подробный пример хранения состояния есть в разборе тома PostgreSQL в Docker.

• Образ хранит среду запуска
• Том хранит состояние отдельно
• Резервную копию настраивают отдельно

Скорость: почему проценты из черновика удалены

В исходной версии были «десятки миллисекунд», прирост 5–10 процентов и разница 8 процентов в неназванном тесте. Ни условий замера, ни модели оборудования, ни кода теста нет; база знаний эти цифры не подтверждает. Поэтому я удалил их, а вместе с ними и вывод, будто MCP обычно быстрее Docker. Такие проценты без воспроизводимого замера — не ориентир для закупки, а декорация с точностью до знака.

Сам протокол не даёт оснований приписывать ему фиксированную задержку. Локальный stdio и HTTP по сети создают разные условия; на итоговое время влияют клиент, сервер, объём данных, состояние диска и работа самого приложения. В Docker тома и файловая система контейнера тоже не одно и то же: документация Docker указывает, что тома подходят для сохраняемых данных и в ряде случаев работают быстрее записываемого слоя контейнера. Отсюда нельзя выводить, что любой том всегда быстрее или что любой контейнер замедляет чтение.

Если производительность действительно важна, я сравниваю два одинаковых сценария на том же оборудовании: один источник данных, одинаковый объём, одинаковая операция и несколько повторов. Отдельно фиксирую время ответа, загрузку CPU и память; затем повторяю замер после прогрева. Нельзя менять одновременно транспорт, контейнер, настройки и набор данных, а потом выдавать разницу за эффект одной технологии. Если приложение в основном ждёт внешний API, спор о накладных расходах файловой системы вообще может быть не главным.

• Не переносите проценты из чужого замера
• Сравнивайте одинаковые операции
• Записывайте оборудование и настройки

Доступ и изоляция: где остаются риски

MCP стандартизирует обмен сообщениями и описывает правила согласия, но сам по себе не назначает сотрудникам права на корпоративные папки. Хост и сервер должны показывать пользователю, какие данные передаются и какое действие запрашивается; у самого процесса должны быть только необходимые права. Журналирование тоже надо настроить в конкретной реализации: наличие протокола не означает, что у вас уже есть аудит, роли и готовый отчёт для проверки.

Контейнер отделяет процессы и файловые пространства, но не является полной границей безопасности. Контейнеры на одном Linux-хосте используют его ядро. Смонтированная папка даёт приложению доступ к указанному содержимому, а доступ к Docker daemon способен открыть гораздо более широкие возможности. Флаг read_only ограничивает запись в файловую систему контейнера, но не отменяет доступ к записываемым томам, сети или другим выданным полномочиям. Я проверяю каждое монтирование и не выдаю полный доступ к файловой системе «на всякий случай».

В условном сценарии для «Орион-М» я бы собрал минимальный стенд: один разрешённый каталог, один сервер MCP, чтение без изменения файлов и отдельный контейнер для приложения, если его зависимости надо зафиксировать. Затем проверил бы, что запрос к закрытой папке отклоняется, а чтение разрешённого тестового файла проходит; после этого — журнал, перезапуск и восстановление данных. Это проект проверки, а не рассказ о якобы выполненном внедрении: размер данных и требуемые действия компания должна определить сама.

• Выдавайте права на конкретный источник
• Разделяйте чтение и изменение
• Проверяйте журналы и восстановление

Обновление и выбор для «Орион-М»

Обновление MCP зависит от того, что меняется: приложение-хост, его настройки или сам сервер интеграции. При stdio клиент запускает сервер как дочерний процесс; при Streamable HTTP это отдельный сервис. Поэтому совет «замените бинарник и перезапустите клиента» не универсален: он может не обновить образ, настройки или другой процесс. Я сначала записываю версии компонентов и способ отката, затем меняю один компонент за раз и проверяю чтение, ошибки и выданные права.

В Docker новый образ обычно требует пересоздать контейнер. Параметр restart: unless-stopped управляет автоматическим запуском контейнера после остановки; он не обновляет образ и не гарантирует непрерывную работу при замене сервиса. Compose описывает сервисы и условия перезапуска, но сам факт такой настройки не превращает замену контейнера в rolling update. «Перезапустили — значит обновили» звучит бодро, пока не спросили, что именно поменялось. План переключения, проверка готовности и откат нужны отдельно; пример работы с несколькими экземплярами разобран в статье про реплики в Docker Compose.

Для «Орион-М» я бы выбирал комбинацию, если одновременно нужны контролируемый доступ к источнику и одинаковая среда запуска. Если нужен только доступ приложения к данным, отдельный Docker-слой может ничего не добавить; если важнее упаковать сервис, MCP не обязателен. Сначала опишу источники, операции и ответственных за них, затем проверю интеграции и план возврата. Общий материал о том, как подготовить среду для проверки, пригодится, когда вопрос уже не только в протоколе.

• MCP — доступ и вызов возможностей
• Docker — повторяемая среда
• Комбинация — если нужны оба слоя

Частые вопросы