Бэкенды рабочих пространств

Каждый Bot в Memoh работает внутри рабочего пространства. Рабочим пространством может быть изолированный контейнер или, в доверенных настольных и локальных сценариях, локальный каталог на хосте. Бэкенд определяет, где выполняется это рабочее пространство и какие возможности изоляции, сети, снапшотов и дисплея доступны.

Контейнерные бэкенды

Контейнерные рабочие пространства настраиваются в config.toml:

[container]
backend = "containerd" # containerd, docker или apple

Бэкенд	Для чего подходит	Примечания
containerd	Серверные развёртывания на Docker Compose, серверы Linux, разработка	Используется по умолчанию в официальном образе сервера. Поддерживает сеть CNI, снапшоты, устройства CDI, сайдкары провайдеров и самый широкий набор возможностей локальных рабочих пространств.
docker	Развёртывания на хосте или из бинарника с Docker Engine	Использует Docker API хоста. Пути bind-монтирования рантайма вроде container.runtime_dir должны существовать на хосте с Docker.
apple	Локальное тестирование на macOS	Использует socktainer и Apple Containerization. Оверлейные сайдкары провайдеров не поддерживаются.

Серверное развёртывание Docker Compose в одну команду использует containerd. Это сделано намеренно: образ сервера запускает встроенный containerd и монтирует файлы рантайма, нужные рабочим пространствам Bot. Остальные бэкенды используйте для ручных развёртываний, в которых пути рантайма на хосте контролируете вы.

Доверенные локальные рабочие пространства

В Desktop и при локальной разработке можно включить доверенные локальные рабочие пространства в дополнение к настроенному контейнерному бэкенду:

[local]
enabled = true

Доверенные локальные рабочие пространства выполняются на хосте с правами процесса сервера. Они удобны для личных настольных сценариев и локальной разработки, но не изолированы контейнером. Не включайте локальные рабочие пространства в недоверенных серверных развёртываниях.

Когда Bot использует локальное рабочее пространство, элементы интерфейса, которым нужен контейнерный рабочий стол или контейнерная сессия дисплея, могут быть скрыты или недоступны.

containerd

[container]
backend = "containerd"
default_image = "debian:bookworm-slim"
image_pull_policy = "if_not_present"
snapshotter = "overlayfs"
data_root = "/opt/memoh/data"
runtime_dir = "/opt/memoh/runtime"
cni_bin_dir = "/opt/cni/bin"
cni_conf_dir = "/etc/cni/net.d"

[containerd]
socket_path = "/run/containerd/containerd.sock"
namespace = "default"

Используйте этот бэкенд для официального стека Docker Compose и для хостов, где Memoh может обращаться к containerd напрямую.

Docker

[container]
backend = "docker"
default_image = "debian:bookworm-slim"
runtime_dir = "/opt/memoh/runtime"
data_root = "/opt/memoh/data"

[docker]
# Пустое значение означает стандартное обнаружение окружения Docker: DOCKER_HOST,
# DOCKER_TLS_VERIFY, DOCKER_CERT_PATH или сокет по умолчанию для платформы.
host = ""

Бэкенд Docker обращается к Docker Engine через стандартное окружение Docker. Он рассчитан на сервер Memoh, работающий прямо на хосте, или на окружение, где исходные пути bind-монтирования Docker указывают на реальные пути хоста.

Не переключайте стандартную установку Docker Compose с containerd на docker, если вы заодно не обеспечите валидные на хосте пути для runtime_dir и доступ к сокету Docker. Иначе контейнеры рабочих пространств могут создаваться без нужных им файлов bridge-рантайма.

Apple

[container]
backend = "apple"

[apple]
socket_path = ""
binary_path = ""

Этот бэкенд предназначен для локального тестирования на macOS через socktainer и Apple Containerization. Он экспериментальный и не поддерживает сетевые сайдкары на основе провайдеров.

Дисплей, Browser Use и Computer Use

Контейнерные рабочие пространства могут предоставлять рантайм дисплея: Xvnc/RFB для рабочего стола пространства, браузер Chrome/Chromium с графическим интерфейсом (headed) и CDP, а также сессии WebRTC для панели Desktop в приложении.

Используйте этот путь, когда сайту нужен настоящий графический браузер. Headless Playwright по-прежнему доступен как обычная команда рабочего пространства, но Browser Use и Computer Use работают с графическим (headed) рабочим столом пространства.

Локальные рабочие пространства не дают той же изоляции контейнерного рабочего стола. Модель на уровне инструментов описана в Browser / Computer Use.

Сеть и оверлеи

Сеть Bot устроена в два слоя:

• Сеть рантайма подключает рабочее пространство к базовой сети контейнера или пода.
• Оверлейные провайдеры, такие как Tailscale и NetBird, добавляют необязательную приватную сеть для отдельного Bot.

Возможности рантайма зависят от бэкенда:

Бэкенд	Сеть рантайма	Оверлейные сайдкары	Устройства CDI	Дисплей в контейнере
containerd	CNI	Да	Да	Да
docker	Подключение к контейнерной сети Docker	Ограничены возможностями рантайма Docker	Нет	Да, когда доступны файлы рантайма и пакеты в образе
apple	Базовый локальный рантайм	Нет	Нет	Ограниченно
local	Сеть хоста	Нет	Только на уровне хоста	Без контейнерного рабочего стола

Настройки оверлейного провайдера задаются для каждого Bot в приложении, а не в глобальном TOML-файле. Глобальный бэкенд всё равно важен: он определяет, какой оверлейный драйвер сможет работать.

Устройства CDI (проброс GPU)

Чтобы пробросить устройства хоста в контейнерное рабочее пространство через CDI (чаще всего это GPU), настройте их у нужного Bot в разделе Workspace (рабочее пространство) → Advanced. Заниматься этим стоит, только когда внутри рабочего пространства действительно нужны задачи CUDA/ROCm.

Настройка

1. Откройте вкладку Workspace; если контейнера ещё нет, сначала создайте его кнопкой Create.
2. Разверните Advanced, включите GPU и перечислите имена устройств в CDI devices — по одному в строке или через запятую:
   • nvidia.com/gpu=0, nvidia.com/gpu=all
   • amd.com/gpu=0, amd.com/gpu=all

Требования к хосту

Драйверы, инструменты вендора и спецификации CDI должны быть уже настроены на хосте. Обычно это означает:

• GPU уже работает на самом хосте
• Спецификации лежат в /etc/cdi или /var/run/cdi
• Имена, которые вы вводите, совпадают с тем, что видит рантайм (проверьте через nvidia-ctk cdi list для NVIDIA и amd-ctk cdi list для AMD)

Ошибка unresolvable CDI devices почти всегда означает несовпадение имён.

Примечания

• CDI вступает в силу в момент создания: после изменения конфигурации контейнер обычно нужно пересоздать — остановка и запуск не заменяют подключённые устройства.
• Образу всё равно нужны правильные библиотеки и инструменты пользовательского пространства, чтобы реально запускать софт CUDA/ROCm.
• После создания вкладка Workspace показывает список подключённых устройств — по нему удобно сверяться.
• Поддержка по бэкендам — в таблице выше: CDI поддерживает только containerd.