2026 Запуск OpenClaw в Docker Sandboxes: базовые линии, лимиты ресурсов и FAQ по сравнению с bare metal и обычным docker run (Mac-облако 7×24)

1. Границы: не берите Sandboxes ради понтов

Если вы итерируетесь в одиночку, крутите конфиг каждый час или зависите от GUI на хосте, голый npm или апстрим-установщик обычно быстрее. Если Compose уже крутится с корнями только для чтения, лимитами памяти и нормальными томами, ваша модель угроз может пока не оправдывать ещё один слой.

1. Склоняйтесь к Sandboxes, когда несколько арендаторов делят узел Mac-облака, skills и плагины по умолчанию считаются недоверенным кодом, нужны allow-list на исход или централизованная инъекция секретов через прокси, а аудиторы требуют списки доменов в записи о развёртывании.
2. Оставайтесь на bare metal или Compose, если вы в исходных сборках, монтируете огромные workspace с тяжёлым I/O или команда ещё не зафиксировала Docker и семантику sandbox на образе.
3. Особенности Mac-облака: нет локального экрана, фиксированные ступени RAM, данные Docker часто на том же томе, что и логи — закладывайте overhead Sandboxes вместе с CI-сборками на том же хосте.

Считайте Sandboxes политическим слоем поверх обычной дисциплины контейнеров, а не заменой. Когда что-то ломается, вы всё равно смотрите docker inspect, события cgroup и права томов, прежде чем переписывать сеть с нуля.

Тимлиды должны зафиксировать, кто владеет репозиторием политики sandbox относительно compose-файла приложения. Разделённая ответственность без CI снова приносит «у меня работает»: один обновляет образ OpenClaw, другой забывает расширить egress под новый endpoint модели. Шаблон pull request, требующий оба diff, или крошечный интеграционный тест, поднимающий стек и бьющий по синтетическому health, окупается с первой пятницы без инцидента.

Платформенная команда должна решить, как утверждаются изменения политики Sandboxes (тот же уровень строгости, что IaC, или мягче) и относиться к skills как к исполняемому коду: Sandboxes сужают blast radius, но не заменяют ревью или статанализ перед продом, если отрасль это требует.

Наконец, Sandboxes сияют, когда секреты не касаются записываемого слоя. Если вы всё ещё вшиваете API-ключи в кастомные образы или коммитите их «временно» в Git, вы обнуляете экономический аргумент сложности. Перенесите инъекцию на прокси, secret store или оркестратор и держите ФС контейнера одноразовой.

2. Bare metal, обычный Docker и Sandboxes

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

3. Пять шагов плюс снимок валидации

Последовательность заточена под аудит; подставьте свои теги образа и имена файлов политики.

1. Зафиксируйте тройку. Запишите в runbook версию Docker Engine/CLI, дайджест образа OpenClaw и ревизию политики sandbox; автоматизация выкатывает только эту тройку.
2. Разделите тома. Конфиг, workspace и логи на разных монтах или подпутях; не биндьте целый home. Держите выравнивание uid (часто 1000) как в статье про обычный Docker.
3. Задайте потолки ресурсов. Лимиты памяти и CPU плюс примерно двадцать процентов запаса под всплески модели; если на том же Mac-облаке крутится CI, разводите окна по времени.
4. Исходящие списки. Перечислите API моделей, вебхуки каналов, регистри и всё, что шлюзу реально нужно; по умолчанию запрещайте остальное или гоните трафик через корпоративный прокси с подстановкой учётных данных.
5. Проверки здоровья. Пробуйте 18789 (или ваш порт) внутри контейнера и с хоста; задайте достаточно длинный start_period для холодного кэша.
6. Снимок успеха. Храните редактированный вывод openclaw status, отпечаток окружения без секретов и хэш файла политики, чтобы откаты давали явный diff.

Фрагмент принципов:

4. Mac-облако 7×24

Без человека за столом оборачивайте контейнеры политиками перезапуска с backoff или circuit breaker, чтобы плохой файл политики не устроил шторм рестартов. Отправляйте логи в ротируемые файлы или центральное хранилище; коррелируйте логи прокси sandbox и шлюза общим идентификатором запроса.

Группы безопасности должны пропускать SSH, опубликованные порты шлюза и исходящий HTTPS к разрешённым доменам. Если curl на хосте проходит, а в контейнере нет, сначала подозревайте сеть Docker, а не ключи API.

На арендованных Mac размещайте агенты мониторинга с тем же сетевым видом, что у контейнера шлюза. Если сборщик метрик слушает только loopback хоста, а sandbox сидит на пользовательском мосту, дашборды зелёные, а пользователи видят таймауты. Лёгкая black-box-проба в эфемерном контейнере той же семьи сетевых namespace ловит такой дрейф рано.

Резервное копирование и аварийное восстановление: снимайте том, где лежат openclaw.json и токены каналов, а не только образ диска ВМ. Восстановление золотого образа без конфигурационных томов — худший сценарий: здоровые контейнеры с пустым состоянием.

5. Опорные baseline

Эти цифры — старт для обзоров ёмкости; всегда меряйте свою p95 задержку и RSS после недели прод-трафика.

• Память: многие начинают с лимита около 4 ГБ для шлюза и лёгких каналов; поднимайте к 8 ГБ и выше, если на узле делят место skills или локальные модели.
• Диск: держите слои образа, scratch sandbox и логи вне тесного системного тома; ставьте апгрейды на паузу ниже примерно 10 ГБ свободных.
• CPU: выделяйте минимум два vCPU с гарантированными долями, если рядом соседи xcodebuild.
• Экспозиция: не публикуйте 18789 широко без усиления пары/аутентификации; для внутренних команд предпочтительны SSH-туннели.
• Файловые дескрипторы: нагруженные каналы могут исчерпать мягкие лимиты; поднимайте ulimit согласованно на хосте и в entrypoint контейнера, чтобы избежать тонких циклов отключений.

Для FinOps смоделируйте overhead Sandboxes как дополнительные минуты vCPU на инстанс шлюза и сравните с ожидаемой экономией на централизованных секретах и часах инцидентов. Если баланс положительный — архитектура держится; если нет — проверьте, не хватает ли обычного Docker с жёсткими capabilities.

Аудиторы часто спрашивают, «кто какие данные видит». У Sandboxes простая история: с прокси говорит только процесс шлюза в контейнере; файлы хоста и другие контейнеры снаружи. Зафиксируйте эту границу в вики архитектуры.

6. FAQ

При инцидентах раскладывайте строки логов по четырём слоям: процесс шлюза, сеть контейнера, прокси sandbox, внешние SaaS. Общий correlation ID по слоям экономит часы на интермиттирующих задержках, которые в чате звучат как «иногда медленно».

Мгновенный краш с правами? Сначала uid томов и записываемые пути, затем запреты записи sandbox — тот же порядок, что в playbook Exit 137.

Процесс жив, каналы мертвы? DNS и egress-списки до разделов каналов openclaw doctor.

Политика сломалась после апгрейда? Сверьте release notes по путям и сети; держите предыдущий тег политики в Git.

Sandboxes на ноутбуках страдают от сна, VPN и потребительских антивирусов. Чисто Windows-лабы добавляют длинный хвост путей и прав. Docker даёт гибкость, но и цену абстракции, и более сложные рассуждения о производительности. Когда OpenClaw — прод-шлюз, а не выходные, команды обычно выбирают выделенную ёмкость Mac-облака на реальном железе Apple: SSH ощущается как Linux-операции при сохранении совместимости toolchain. Сочетайте эту статью с гайдом VPSMAC по отладке Docker, чтобы связать правки cgroup, проверки DNS, шаги openclaw doctor и политику sandbox в единый runbook — Sandboxes остаются слоем, который нужно мерить, версионировать и аудировать, а не лозунгом.