2026 OpenClaw を Mac クラウドで Docker Compose 24/7:ヘルスチェック、リソース上限、compose pull アップグレードとロールバック
起動できても一週間持つのは別問題:healthcheck もメモリ上限もない Compose は夜間再起動、ビルド OOM、トークン不整合に見える。Mac クラウドで公式イメージを回しているチーム向けに、(1) 三誤解 (2) 単発コンテナと Compose 比較 (3) 七ステップ Runbook (4) 数値 (5) FAQ (6) まとめ。Exit 137・権限・DNS、本番ハードニングと分業。
1. 誤解三つ:compose up -d で完了扱い
日記レベルでは「緑のプロンプト」で十分だが、SSH を閉じたあとも動く Mac クラウドでは、壊れ方の型がドキュメントより先に来る。夜間にだけ顕在化する Three patterns を列挙する。
- コンテナ state しか見ない:プロセスは
runningだが18789が聴いていない、workspace が書けない。上流はヘルシー扱いでチャネル再試行だけが回る。 - ノートのメモリ感をそのままコピー:イメージ再ビルドや pnpm ピークはチャット定常より高い。上限が定常 RSS 合わせだと初回
compose pullで OOM。Exit 137 記事と同根でステージが違う。 - latest 任せ:無人ホストでタグ漂移は「コンビニ置き去り設定」と同じ。digest と設定 tar なしにロールバックできない。
ビルド・コールド・定常の三窓に分け、それぞれ limit と再試行を分ける。単発 docker run だと一冊の Runbook に書きにくい。
2. 比較表:ad-hoc と Compose
要件・単発・Compose+Mac クラウド・メモ。セキュリティ行は本番ハードニング文へ戻る。表は「誰が何をオンチェーンで承認できるか」を揃えるのに向く:SRE は数値、セキュリティは露出、プロダクトはチャネル安定、と列を分けてレビュー時間を短くする。
| 要件 | 単発コンテナ | Compose | 注記 |
|---|---|---|---|
| 就緒定義 | 手 curl 頼り | healthcheck と条件付き depends_on | TCP だけの健康は偽陽性になりやすい |
| ビルド/実行分離 | 一つの limit | profile か別 service | アップグレード時 OOM 回避 |
| 改ざん耐性 | latest 漂流 | 不変 tag/digest | 戻しは tag 戻し + tar |
| 露出面 | 忘れがち | Git 管理の network/volume | ハードニング参照 |
3. 七ステップ Runbook
- 凍結:Engine/Compose マイナー、空きメモリ、
dfを付録化。 - 最小 compose:
restart、絶対パス volume、uid 整合。 - healthcheck:P95 コールド超の
start_period、間隔は誤再試行しない幅。 - resource:ゲートウェイと build job を分 cgroup。
- バックアップ:.env、設定 tree、
docker image ls --digests。 - 升級:
pull後up -d、ps と 18789 を同画面。 - 戻し検証:チャネル煙、model list、JSONL ループ確認。
4. 数値目安
自トレースで必ず上書き。定常ゲートに 2~4GB 交換域を残し、limit は RSS の約 1.2~1.5× から。ビルド系は別枠 4~8G 相当。start_period は P90 コールドの 1.2~1.5 倍、interval 20~45s。N/N-1 不変タグ。トンネル時は 18789 三段チェック。設定は main と同拍で増分バックアップ。本節の数字は審議の出発点に留め、実測のない枠を予算会議に持ち込まない方が、Docker 人月税を可視化できる。運用が「呪文」止まりだと、インシデントのたびに同じ grep を買い直すことになる。補足として、週次で docker system df と未使用イメージの刈り込みを週報に残すと、根パーティション枯渇と Exit 137 の相関を早く掴める。多チームだと、compose プロジェクト名をモニタリングのラベルにコピーし、Grafana 等のダッシュで「どのプロジェクトが夜間に再起動回数を増やしたか」を追える。これは人の記憶に頼らない最小コストの可観測性投資である。
5. FAQ
18789 の TCP だけで足りる?
初期化完了を示す HTTP/CLI 推奨。偽陽性で SLO だけ壊す。
升後チャネル全断?
トークンとチャネル diff を先に。ハードニングの沙箱/露出を第二。ログに previous image digest を残すと比較が速い。
health なし always restart で十分?
生き返りはするが層分け失う。再試行ループに気づきにくい。推奨せず。
6. まとめ
Packaging としての Docker は強いが、7×24 Mac クラウドでは volume/bridge/tag が追加の SPOF になりうる。夜間 pager を減らすには可観測性と同列に扱うべきだ。ノート一発デモ向け docker run では、SLA を金銭化できない。家庭用常時稼働マシンも電源と上りと隔離で VPS 契約に及ばない。測定・段階降格・伸縮可能な枠が欲しければ、VPSMAC M4 Mac クラウドの固定枠の方が、Exit 系記事とハードニング、観測性を一直線に繋げながら SSH 体験を保てる。