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本番ハードニングと分業。

Mac クラウド上で Docker Compose による OpenClaw ゲートウェイ

目次

1. 誤解三つ:compose up -d で完了扱い

日記レベルでは「緑のプロンプト」で十分だが、SSH を閉じたあとも動く Mac クラウドでは、壊れ方の型がドキュメントより先に来る。夜間にだけ顕在化する Three patterns を列挙する。

  1. コンテナ state しか見ない:プロセスは running だが 18789 が聴いていない、workspace が書けない。上流はヘルシー扱いでチャネル再試行だけが回る。
  2. ノートのメモリ感をそのままコピー:イメージ再ビルドや pnpm ピークはチャット定常より高い。上限が定常 RSS 合わせだと初回 compose pull で OOM。Exit 137 記事と同根でステージが違う。
  3. latest 任せ:無人ホストでタグ漂移は「コンビニ置き去り設定」と同じ。digest と設定 tar なしにロールバックできない。

ビルド・コールド・定常の三窓に分け、それぞれ limit と再試行を分ける。単発 docker run だと一冊の Runbook に書きにくい。

2. 比較表:ad-hoc と Compose

要件・単発・Compose+Mac クラウド・メモ。セキュリティ行は本番ハードニング文へ戻る。表は「誰が何をオンチェーンで承認できるか」を揃えるのに向く:SRE は数値、セキュリティは露出、プロダクトはチャネル安定、と列を分けてレビュー時間を短くする。

要件単発コンテナCompose注記
就緒定義curl 頼りhealthcheck と条件付き depends_onTCP だけの健康は偽陽性になりやすい
ビルド/実行分離一つの limitprofile か別 serviceアップグレード時 OOM 回避
改ざん耐性latest 漂流不変 tag/digest戻しは tag 戻し + tar
露出面忘れがちGit 管理の network/volumeハードニング参照
ヒント:台帳に compose 名・データパス・公開ポートを一行で残し、多ホスト時は先に機名を確定。

3. 七ステップ Runbook

  1. 凍結:Engine/Compose マイナー、空きメモリ、df を付録化。
  2. 最小 composerestart、絶対パス volume、uid 整合。
  3. healthcheck:P95 コールド超の start_period、間隔は誤再試行しない幅。
  4. resource:ゲートウェイと build job を分 cgroup。
  5. バックアップ:.env、設定 tree、docker image ls --digests
  6. 升級pullup -d、ps と 18789 を同画面。
  7. 戻し検証:チャネル煙、model list、JSONL ループ確認。
# 例: healthcheck は公式 readiness に合わせ改変 docker compose up -d # 戻し: 前タグへ compose 上書き

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 体験を保てる。