2026 OpenClaw в Docker Compose на Mac-облаке 24/7: healthcheck, лимиты ресурсов, compose pull и откат

Запущенный контейнер — не то же самое, что шлюз, который переживёт неделю: Compose без healthcheck и лимитов памяти часто проявляется случайными ночными перезапусками, OOM на этапе сборки и токенами, которые после обновления «не сходятся». Текст для команд, которые уже крутят официальный образ OpenClaw на Mac-облаке или своём macOS-узле: три операционных заблуждения, сравнение разовых контейнеров с продакшен-Compose, семишаговый runbook для дежурной инструкции, ссылки на материал про Exit 137, права томов и DNS и длинное чтение про production hardening: экспозиция, токены, песочницы.

Шлюз OpenClaw под Docker Compose на хосте Mac-облака

На странице

1. Три заблуждения: считать compose up -d финалом

Быстрые старты сфокусированы на зелёном терминале в первый день. Продакшен на Mac-облаке заботится о повторяемых сценариях отказа, которые видны только когда SSH-сессия закрыта, а машина продолжает работать. В инцидентах 2026 года чаще всего встречаются три паттерна.

  1. Смотреть на состояние контейнера, игнорируя readiness: running без слушателя на 18789 или без записываемого workspace — оркестраторы и reverse proxy помечают стек здоровым слишком рано и забивают логику переподключения каналов.
  2. Копировать цифры памяти с ноутбука в облачные SKU: пересборка образа, установка зависимостей и разовые задачи pnpm дают больший пик, чем стабильный чат. Если limit памяти подогнан только под RSS шлюза в простое, первый же compose pull, запускающий rebuild, закончится OOM. История та же, что в гайде Exit 137, но на этапе апгрейда, а не первого запуска.
  3. Использовать latest, чтобы не печатать теги: на безлюдных хостах «плавающий» тег — не удобство, а недокументированная миграция конфигурации. Откат без tar дерева настроек и закреплённого digest — угадайка.

Разделяйте окна по времени для сборки, холодного старта и стабильного прокси-трафика. В Compose разным сервисам можно задать разные «конверты» ресурсов и политики перезапуска, что трудно описать, когда всё живёт в истории разовых docker run.

Часто упускают из виду, что сам демон Docker потребляет память и диск I/O, а на арендованных Mac корневой SSD кажется меньше, когда лежит несколько крупных образов. Короткого smoke после up -d мало: заложите пики на установку зависимостей и зафиксируйте, какие compose-профили активны ночью, чтобы следующий сервис тайно не опустошал тот же пул памяти.

2. Таблица: разовый контейнер и Compose на Mac-облаке

Матрица выравнивает ожидания стейкхолдеров по реальным операционным возможностям и показывает, когда переходить к статье о hardening, если риск — токены и сеть, а не CPU.

НужноОдин ad hoc контейнерCompose + Mac-облакоЗаметки
Документированная readinessРучные curl и надеждаhealthcheck и упорядоченный depends_onПроба должна проверять готовность приложения, а не голый TCP
Разделить память сборки и рантаймаОдин limit на всёПрофили или отдельные сервисы с большим лимитом на buildСнижает Exit 137 при апгрейде
Аудируемые обновленияПлавающий latestНеизменяемый tag@digest и changelogОткат: сменить тег и восстановить tar
Поверхность безопасностиЛегко забыть bind-mount и область bridgeСеть и read-only в GitВ паре с hardening токенов и песочниц
Практика: на каждый хост — одна строка с именем compose-проекта, каталогом данных и портом для SSH-туннеля. Разбор начинается с идентичности хоста, а не с grep по ноутбукам.

Таблица намеренно короткая, чтобы продукт и безопасность могли подписать одну страницу. Пустая строка означает либо отсутствие настоящего Compose, либо то, что критические контроли живут только в личных заметках — оба варианта предсказуемо рискованнее честного «сделаем позже» в бэклоге, потому что «позже» обычно наступает следующий релизный напряг.

3. Семь шагов: от baseline до отката

  1. Заморозить baseline: минорные версии Docker Engine и Compose, запас RAM, где лежат слои относительно корневого тома; df -h в приложение к внутренней wiki.
  2. Минимальный compose.yaml: политика restart, явные host-пути для томов, выравнивание uid, чтобы пользователь шлюза не боролся с Permission denied.
  3. Написать healthcheck: проба должна доказывать готовность шлюза, а не только открытый TCP. interval больше P95 холодного старта, start_period щедрый при первом замере нового major-образа.
  4. Лимиты ресурсов: CPU и память по сервисам; сборка или миграция не в одной cgroup с долгоживущим шлюзом.
  5. Бэкап перед апгрейдом: tar для env и смонтированного конфига, docker image ls --digests в тот же тикет. Автоматизация побеждает память человека.
  6. Путь апгрейда: docker compose pull, затем up -d с открытым тикетом; если smoke падает — вернуть предыдущий неизменяемый тег одним change set и восстановить tar. Рядом держать docker compose ps и curl/CLI на 18789.
  7. Проверка после отката: smoke каналов, список моделей, JSONL на циклы переподключения, затем оставшиеся пункты hardening по scope токенов и песочницам.
# Набросок — подставьте пути и endpoint # healthcheck: test: ["CMD", "curl", "-fsS", "http://127.0.0.1:18789/ready"] docker compose up -d # откат: закрепить PREVIOUS_TAG, затем docker compose up -d

4. Ориентиры: память, повторы, теги

Эти якоря запускают ревью; всегда перемеряйте на своих образах и плане Mac-облака. Во-первых, для узлов класса Apple Silicon с одним долгоживущим шлюзом разумно оставить два–четыре гигабайта буфера ниже потолка тарифа и задать лимит памяти сервиса примерно в 1,2–1,5 раза от измеренного стабильного RSS, а отдельным build/install job — свой лимит или профиль. Во-вторых, healthcheck.start_period не меньше 1,2–1,5× вашего P90 холодного старта на этом диске и CPU, interval обычно 20–45 с, retries согласовать с минутами «миганий», которые допускает гайд дежурства. В-третьих, хранить текущий и предыдущий релиз как неизменяемые теги или digest, CI проставляет IMAGE_TAG со ссылкой на changelog для аудиторов. В-четвёртых, если 18789 достигается через SSH-туннель, таблица приёмки должна отметить loopback, туннель и живой канал за один проход. В-пятых, бэкапить каталог конфигурации в том же ритме, что и merge в default по конфигу шлюза, чтобы не откатить образ без секретов. Команды без числовых baseline часто лишены и бюджетной строки, а сложность Docker тихо превращается в скрытую налоговую ставку на людей.

Шестой пункт: задокументируйте timeout для health-проб, чтобы медленный диск не считался падением, и седьмой — держите короткий скрипт после каждого апгрейда (compose ps, пробы на 18789, быстрый пинг канала), чтобы дежурный любого уровня шёл по одной последовательности. Если этих шагов нет в тикете, каждый откат становится «искусством» и тянет MTTR без технической необходимости.

5. Вопросы и ответы

Достаточно ли TCP-проверки на 18789 как health?

Только если вы сознательно принимаете ложные срабатывания. Лучше HTTP или CLI, доказывающие завершение инициализации.

После апгрейда шлюз поднят, все каналы красные?

Сначала diff файлов токенов и конфигов каналов, затем чеклист песочницы и экспозиции из hardening, прежде чем винить upstream API моделей.

Хватает ли restart: always без healthcheck?

Перезапускает процессы, не ясность. Нужны слоистые сигналы сбоя, иначе возможны бесконечные циклы краша, которые выглядят здоровыми для мониторов uptime.

6. От абстракции Docker к управляемой Mac-плоскости

Контейнеры отлично упаковывают, но на Mac-облаке 24/7 добавляются поверхности томов, сети и тегов образа, которых нет в быстрой демо на ноутбуке. Каждая лишняя абстракция — ещё один класс ночных алертов, если её не версионировать, не ограничивать и не бэкапить как код приложения. Ad hoc кажется быстрым, пока автор команд офлайн, а хост всё ещё должен держать SLA. Домашняя «арендованная» машина без ЦОД-питания, uplink и изоляции не заменяет операционный контракт. Если нужен OpenClaw и каналы в форме, которую может подписать руководство, аренда ёмкости VPSMAC M4 Mac-облака под закреплённый шлюз и build-плоскость обычно предсказуемее, чем башня контейнеров на слабом личном железе. SSH тот же, линейки моделей остаются аудируемыми, те же плейбуки hardening, наблюдаемости и Exit 137 выстраиваются в линию с тем, что уже на сайте, без бесконечной археологии docker ps.

В долгую важнее не вопрос «крутится ли Docker?», а «может ли коллега за десять минут восстановить, какой compose-файл, какой digest и какой бэкап относятся к этому хосту?». Если нет — у вас не инфраструктурный репозиторий, а коллекция личных экспериментов. Применяйте к compose-файлам те же правила ревью, что и к коду приложения: pull request, вторые глаза на mount-пути и ежемесячный учебный откат без паники в проде.