--- url: /ru/self-hosted/workspace-backends.md --- # Бэкенды рабочих пространств Каждый Bot в Memoh работает внутри рабочего пространства. Рабочим пространством может быть изолированный контейнер или, в доверенных настольных и локальных сценариях, локальный каталог на хосте. Бэкенд определяет, где выполняется это рабочее пространство и какие возможности изоляции, сети, снапшотов и дисплея доступны. ## Контейнерные бэкенды Контейнерные рабочие пространства настраиваются в `config.toml`: ```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 и при локальной разработке можно включить доверенные локальные рабочие пространства в дополнение к настроенному контейнерному бэкенду: ```toml [local] enabled = true ``` Доверенные локальные рабочие пространства выполняются на хосте с правами процесса сервера. Они удобны для личных настольных сценариев и локальной разработки, но **не изолированы контейнером**. Не включайте локальные рабочие пространства в недоверенных серверных развёртываниях. Когда Bot использует локальное рабочее пространство, элементы интерфейса, которым нужен контейнерный рабочий стол или контейнерная сессия дисплея, могут быть скрыты или недоступны. ## containerd ```toml [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 ```toml [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 ```toml [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](../guides/browser-computer-use.md). ## Сеть и оверлеи Сеть 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`.