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
以下數字為評審起點，須以實際映象重測：① 穩態可按「餘量 2～4GB + 單服務上限約 1.2～1.5×峰值 RSS」；帶構建 one-shot 宜分 profile。② start_period ≥ 冷啟動 P90 的約 1.2～1.5 倍；interval 常 20～45s。③ 發版保留 N 與 N-1 的**不可變** tag/digest。④ 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 細節裡。