2026 OpenClaw Docker: тома и права
Персистентная конфигурация, записываемые Skills и состояние после перезапуска

Около 21 мин чтения · MACCOME

Команды, которые запускают OpenClaw Gateway в Docker / Compose, редко тратят больше всего времени на pull образов — чаще на перезапуски, обновления или docker compose down, которые стирают сопряжение и конфиг, или на каталоги Skills только для чтения с потоком Permission denied, не совпадающим с сетевыми пунктами официального troubleshooting. Статья дополняет сетевую триажу Docker, триажу doctor после установки, прод-ранбук Docker и Gateway и безнадзорную эксплуатацию удалённых Mac: шесть ловушек томов/прав, две таблицы «что персистить» против антипаттернов, матрица симптом→команда→исправление, готовые фрагменты inspect, шестишаговый ранбук и три метрики для дашбордов. Порядок триажа: сначала тома и UID/GID, затем сеть и обратные прокси.

Превратить «после перезапуска всё сбросилось» в шесть причин по томам, готовых для RCA

Образы — неизменяемые шаблоны; исчезает только состояние, записанное в записываемый слой, анонимные тома или неперсистентные пути. Фиксируйте сигналы ниже в тикетах изменений и проверяйте их на одной линии с правками Compose и тегами образов.

  1. Анонимные или безымянные монтирования: Compose объявляет пути в контейнере без bind на хост; down -v или скрипты очистки удаляют кэши сопряжения, даже если «в git ничего не менялось».
  2. Сдвиг путей bind на удалённых Mac: домашние каталоги, папки синхронизации или временные точки монтирования смещаются; bind указывает на пустые каталоги или устаревшие снимки, пока Gateway всё равно стартует.
  3. Расхождение UID/GID: пользователь процесса в контейнере не совпадает с владельцем на хосте; горячая перезагрузка Skills или запись логов падает. Docker Desktop на macOS и Linux-хосты расходятся — копировать Compose без настройки user — типичный провал.
  4. Неверное использование read-only: пометить конфиг или Skills :ro «ради безопасности» блокирует кэши токенов или локальное состояние, которое ожидает апстрим; сбои могут быть незаметны до перезапуска.
  5. Состояние только в записываемом слое: docker commit заманчив, но обновления или смена тега всё равно отбрасывают этот слой — в проде избегайте.
  6. Параллельные писатели без координации: два экспериментальных Compose-проекта монтируют один каталог, портят JSON или дописывают конфиг наполовину.

Если сетевая триажа всё ещё показывает прерывистый успех CLI и гарантированный сбой после перезапуска, вернитесь сюда и проверьте, что именованные тома лежат на ожидаемом диске и пользователь процесса может писать в Skills, прежде чем трогать network_mode или прокси.

Таблица 1: что OpenClaw должен персистить в Docker — и типичные антипаттерны

Точные подпути следуют вашему образу и документации; таблица задаёт три инженерных вопроса: переживает ли жизненный цикл контейнера, нужен ли бэкап, общий только для чтения? Фиксируйте ответы в README и онколл-плейбуках.

КлассТипичное персистируемое содержимоеРекомендуемый шаблонАнтипаттерн
Конфиг и секретыЭндпоинты Gateway, выбор провайдера, пути к токенам каналовBind на хост или именованный том; права под пользователя рантаймаЗапекать в образ; хранить там, где синхронизация чистит каталоги
Рантайм и сопряжениеСостояние сопряжения устройств и восстановления сессииВыделенное поддерево bind; tar перед обновлениямиАнонимные тома без описания в Compose; один prune удаляет всё
Skills / расширенияСкиллы и скрипты командыBind рядом с репозиторием; одинаковые пути в CI и проде:ro, хотя кэши рантайма должны быть записываемыми; UID не может писать
Логи и буферыБольшие логи, выгрузкиОтдельный том или путь на хосте с ротациейЗаполнить записываемый слой до OOM или неожиданной read-only ФС

Таблица 2: симптомы → проверки → исправления (тома раньше сети)

Во время проверок логируйте ID образов, имена проектов Compose и томов в одной shell-сессии, чтобы упростить откаты; переиспользуйте страницу чеклиста релиза из прод-ранбука.

СимптомСначала проверитьТипичное исправлениеЕсли всё ещё падает
После каждого docker compose up ощущение чистой установкиdocker inspect Mounts против ожидаемых путей хоста; недавняя очистка -vЯвные bind или именованные тома; задокументировать, может ли down использовать -vУбедиться, что вы в правильном каталоге проекта Compose
Skills игнорируются или запись не удаётсяid в контейнере против владения на хосте ls -lnПодстроить user, chmod или выровнять UID в Dockerfile/entrypointПроверить, что монтирования не :ro
Поток ошибок правSELinux/AppArmor на Linux; общий доступ к файлам Docker Desktop на macOSLinux: оценить метки или :z относительно базовой линии безопасности; macOS: добавить пути в File SharingИсключить read-only на уровне диска до возврата к сетевой триаже
После bump образа работает наполовинуСмена схемы конфига; старый каталог данных всё ещё смонтированСледовать release notes; бэкап перед обновлениемЗапустить openclaw doctor против задокументированных breaking changes
bash
# 1) Попадают ли монтирования на ожидаемые пути хоста? (заменить контейнер)
docker inspect -f '{{ json .Mounts }}' <container> | jq .

# 2) Пользователь рантайма внутри контейнера (сравнить с владельцем на хосте)
docker exec -it <container> id

# 3) Проекты Compose и тома (избежать дрейфа анонимных)
docker compose ls
docker volume ls | grep <project>

# 4) Пример бэкапа bind перед обновлением (путь по договорённости команды)
tar czf openclaw-state-$(date +%Y%m%d).tgz ./openclaw-data/
info

Заметка: Docker Desktop на удалённых Mac обычно держит bind внутри домашних каталогов пользователей; на Linux в облаке часто нужны другие строки user и модели прав. «Работает на моём ноутбуке» не равно «работает на пуле хостов».

Шестишаговый ранбук: от «контейнер запущен» до «состояние переживает перезапуск/обновление»

  1. Нарисовать плоскость данных: подписать конфиг, рантайм, Skills и bind логов на архитектурной схеме; слить с диаграммой сервисов из прод-ранбука.
  2. Запретить неявные анонимные тома: в Compose назвать каждый путь, который должен пережить перезапуски; в README указать, что уничтожает down -v.
  3. Заморозить политику UID/GID: выбрать пользователя в контейнере, отразить владение или ACL на хосте и закодировать в Ansible или cloud-init для пулов.
  4. Бэкапить перед обновлениями: tarball с меткой времени для корней bind; записать старые дайджесты образов и ревизии Compose.
  5. Здоровье томов до doctor: когда Mounts выглядят верно, запускать openclaw doctor и пробы каналов, чтобы избежать ложных отрицаний.
  6. Встроить в онколл: шаг один открывает эту таблицу плюс таблицу 1 из сетевой статьи — не править сеть и хранилище параллельно.

Три жёсткие метрики для дашбордов и постмортемов

  1. Покрытие томами: доля обязательных персистентных путей с явными bind или именованными томами; стейджинг ниже 100% не готов к продакшену.
  2. Частота отказов по правам: фильтровать логи контейнера на Permission denied / EACCES; корреляция с обновлениями Gateway чаще указывает на монтирования, а не провайдеров.
  3. Ритм бэкапов состояния: фиксировать, был ли архив при каждом обновлении; частый сбой 2026 года — «обновление прошло, но никто не помнил, что bind жил на другом хосте». Храните копии вне диска Gateway, чтобы соблюдать устные RPO.

Стройте графики рядом с метриками диска и логов из статьи про удалённые Mac — проблемы томов часто видны как рост диска или read-only монтирования до скачков CPU.

Многие команды в 2025–2026 совмещают Gateway и Skills в одном дереве хоста; без квот на чисто логовые поддеревья логи могут заполнить bind и заблокировать запись конфига. Сначала ротация или разделение томов, а не бесконечное пересоздание контейнеров.

Различайте docker compose restart и down/up: первый обычно сохраняет объявленные тома; второй с флагами очистки меняет судьбу данных — держите шпаргалку глаголов в ранбуках.

Почему docker-эксперименты «только на ноутбуке» редко масштабируются до безнадзорных Gateway

Права однопользовательского ноутбука отличаются от пулов удалённых хостов с автоматическими логинами; сон, утилиты синхронизации и ручные правки bind делают «вчера работало» невоспроизводимым. OpenClaw как плоскость управления 24/7 требует контрактных путей, откатываемых обновлений и аудируемых прав.

Циклы обучения на личном железе нормальны, но цена в проде — шум пейджеров и мёртвые каналы. Эфемерные scratch-контейнеры без стабильных монтирований умножают области отказа при обновлениях. Командам, которым нужны всегда доступные, удобные для бэкапа и переносимые Gateway, чаще быстрее подходят профессиональные облачные Mac с bare metal Apple Silicon и выбором региона, чем бесконечная настройка личного Docker. MACCOME сдаёт в аренду Mac mini M4 / M4 Pro в нескольких регионах и даёт публичную справку — начните с центра помощи и цен аренды, затем оформляйте региональный заказ.

Совет по раскатке: прогоните проверки таблицы 2 на том же классе хостов, что и в проде (Docker Desktop vs Linux), до подключения каналов и моделей — избегайте дрейфа UID и путей «локально ок, в облаке нет».

Если у вас ещё Kubernetes, поды пересоздаются чаще стеков Compose: всё без PVC исчезает при rolling updates — то же правило явной персистентности, проверяйте через kubectl describe pvc и манифесты монтирования.

FAQ

Чем это отличается от статьи по сетевой триаже Docker?

Сеть — про связность и пространства имён; здесь — про данные на диске и возможность записи. Точки входа установки — гайд по трём платформам. Доступ и цены: центр помощи и цены аренды.

Сначала doctor или тома?

Сначала тома и права, затем doctor, чтобы не получать ложные срабатывания из-за постоянно пересоздаваемых контейнеров. Детали WSL2 — в статье doctor после установки.

Как это сочетается с эксплуатацией удалённых Mac?

Там — launchd/systemd, логи и триаж зависаний; здесь — персистентность Docker и запись. Обе статьи включайте в один обзор изменений и индекс онколла.