2026 年 OpenClaw 用 Docker Compose 在 Mac 云 7×24 跑稳：健康检查、资源上限、compose pull 升级与一键回滚
容器「能起」与网关「能扛一周」是两件不同的事：没有 healthcheck 与资源上限的 Compose 往往表现为夜间随机重启、构建阶段 OOM、升级后 token 对不上。本文面向已在 Mac 云或自建 macOS 上跑过 OpenClaw 镜像的读者：先用三条编号拆误区，再给出「单容器 ad-hoc」与「Compose 生产」对照表，随后给出不少于五的可复现步骤、可写进值班手册的升级/回滚与 18789 探活顺序，并链到站内 Exit 137 与卷权限排障及 生产加固：暴露面、Token 与沙箱长文。
本文要点
1. 三条误区：把 compose up -d 当完工
2026 年社区文档普遍给出「克隆后一条脚本起网关」的路径，长期跑在 Mac 云上的实际痛点却是可观测的崩溃模式，而不是首屏能否打开。没有统一约束的 Compose 往往把问题推迟到凌晨流量低谷才暴露。下面三条在值班记录里出现频率最高。
- 只盯容器状态，不盯就绪语义：进程处于
running但网关尚未在18789监听、或工作目录不可写，会在健康检查被补上之前被上层编排误判为健康，进而触发通道重连风暴。 - 用笔记本上的内存条值直接套云套餐：同一镜像的
pnpm安装或模型拉取在构建阶段会短时高于稳态；若deploy.resources.limits.memory只按「能聊天」来设，升版本时的镜像重建会首批被杀，表现为「升级必挂」。这与站内 Exit 137 与卷权限长文中的 OOM 线是同根问题在不同阶段的投影。 - 用
latest漂移换「省事」：在无人值守节点上，漂移标签让「昨晚还能跑」与「今早配置字段变更」无法对应；回滚时若没有 tar 过配置目录与版本化镜像 tag，只能全文搜索聊天记录。
要区分三类时间窗口：构建、冷启动、稳态；Compose 能分别限资源与重试，裸 docker run 难写进同一本 Runbook。
2. 对照表：单容器 ad-hoc 与 Compose 生产面
下表用于和团队对齐「我们到底在运维什么」；左侧是常见诉求，中间是只用手工命令的局限，右侧是建议的 Compose 级能力，右侧备注链到可观测与加固文章。
| 诉求 | 单容器/手工命令 | Compose + Mac 云节点 | 备注 |
|---|---|---|---|
| 可定义的「就绪」 | 靠人工 curl 与主观判断 | healthcheck 与 depends_on 条件可文档化 | 探活路径要与网关真实监听端口一致 |
| 构建/运行分档内存 | 同一条 mem 打天下 | 多阶段或分 profile 限制峰值 | 与 Exit 137 文联动限流 OOM |
| 升级可审计 | latest 与口头约定 | 显式 image:tag@digest 或发版表 | 回滚=切 tag + 恢复配置 tar |
| 安全隔离与暴露面 | 容易忘记内网与 token 范围 | 与 compose 网桥、只读卷策略一致 | 加固读 生产沙箱与网关 Token |
OPENCLAW_* 与数据卷路径写进同一台机器的「机架标签」，多节点时与 SSH 与监控主机名一一对应，排障时先定位节点再定位 compose 项目名。
3. 七步 Runbook：从基线到回滚
- 冻结基线：记录 Docker Engine/Compose 次版本、可用内存与根盘/数据盘水位；
docker info与df -h输出进附录。 - 最小
compose.yaml：为网关服务设restart: on-failure或unless-stopped；为数据卷设显式宿主机路径，权限与容器用户对齐 uid/gid。 - healthcheck：以「进程内能证明就绪」为准（如命中本地健康路由或
openclaw子命令成功），interval要大于冷启动 P95，避免未就绪时连锁重启。 - 资源条：为服务设
cpus/memory或 compose v3 等价键；为可能单独执行构建的 one-shot 服务分更高上限或分 profile。 - 升级前一次性备份：
tar czf含.env、挂载的配置目录、当前docker images --digests截图；不依赖云端「我会记得」. - 升级路径：
docker compose pull后up -d；若失败，用备份 tar 与上一 tag 在一条命令中回切；同屏对比docker compose ps与 18789 探针。 - 回滚后验收：通道级冒烟、模型列表、
doctor与 JSONL 日志中无异常循环；与《生产加固》文中的 Token 与沙箱项对照抽检。
4. 可引用：内存、重试、镜像 tag
以下数字用于评审起点，必须以实际镜像与套餐重测：① Apple Silicon 云节点上网关稳态可先按「余量 2～4GB + 单服务内存上限约 1.2～1.5×峰值 RSS」；带构建的 one-shot 宜分 profile 或 4～8GB 级上限，避免与网关同 cgroup 抢杀。② start_period 不短于冷启动 P90 的约 1.2～1.5 倍，interval 常取 20～45s，retries 与可接受宕窗一致。③ 发版保留 N 与 N-1 的**不可变** tag/digest，CI 里写死 `IMAGE_TAG`。④ 18789 经隧道时验收「回环、隧道、通道」三行。⑤ 配置目录与主干变更同节奏做增量备份，避免只回滚镜像不回密钥.
5. 常见问题
healthcheck 用 curl 18789 与官方 readiness 有冲突？
以能证明**业务进程真正就绪**的最短路径为准；仅 TCP open 会放行未初始化的状态，宁可略慢也不要健康假象。
升级后 Gateway 能启动但通道全断？
先对 token 与通道配置文件做 diff，再与加固文核对沙箱与暴露面，最后才怀疑上游模型。
能否只用 restart always 不配 health？
能「活着」但缺失败分层；长期建议二者并存。
6. 从 Docker 抽象回到可控 Mac 执行面
Docker/Compose 把依赖打进镜像，确实能缩短首装时间；但在 Mac 云 7×24 场景里，多一层抽象就意味着多一层排障面：卷、网络命名空间、镜像 tag 与宿主机时间漂移都能独立制造事故，而笔记本上被忽略的偶发现象会在云端被时间放大。若只依赖临时 docker run 与手改 env，而缺少上述 Runbook 与显式资源边界，生产稳定性往往不如在可钉死机型与长期在线电源的专用节点上把配置与算力收束。若要把 OpenClaw 与通道真正跑到「能签字验收」的级别，租赁 VPSMAC 的 M4 Mac 云主机作为固定网关与构建面，比在个人设备或超售共享环境硬扛更省心：与站内加固、可观测、Exit 137 等文章可组成闭环，而运维动作仍通过熟悉的 SSH 与卷路径完成，不必把整支团队绑在 Docker 细节里。