2026 年の OpenClaw Docker の本番環境
Compose · イメージのアップグレード · ボリュームと systemd ベースライン

OpenClaw Gateway のコンテナ分離を必要としているものの、アップグレードの夜にパスを手動で編集することを恐れるチームは、通常、Compose、名前付きボリューム、およびイメージ ダイジェストをトレードオフにします。この記事では、オンサイトの Ubuntu 24.04 + systemd + トンネル ベアメタル ガイドから明確に分離した、再現可能な Docker 運用パス (ベースライン、docker-compose.yml 形状、永続ボリューム、イメージ アップグレード、ヘルス チェック) と、一般的なコンテナ障害の症状表を示します。

01

このガイドの分割が systemd + Tunnel ベアメタル記事でどのように機能するか

ベアメタル パスにより、ホスト上のプロセス、再起動用の systemd、パブリック Ingress 用のトンネルなどの抽象化が最小限に抑えられます。 Docker パスは、アーティファクトを「ディレクトリ + ユニット ファイル」から「イメージ + Compose」に切り替えます。アップグレードのほとんどは、新しいダイジェストを取得し、コンテナーを再作成し、マウントがまだ並んでいることを確認します。どちらも、エッジで TLS を使用してゲートウェイをループバック状態に保つことができます。分かれ目は、再現性とより細かいロールバックと引き換えに、イメージのサプライチェーンとボリュームのガバナンスを受け入れるかどうかです。

レジストリ、スキャン、SBOM をすでに標準化している場合は、多くの場合、Compose が最も摩擦の少ない運用形態になります。単一の低チャーン VPS は、systemd だけを使用した紙の上ではまだ安い可能性があります。以下の 6 つの問題点は、実際のトリアージ スレッドからのものであり、コンテナの準備ができているかどうかを示します。

  1. 01

    治療中latestバージョン管理として:本番環境でダイジェストまたは不変のビルドタグをピン留めします。それ以外の場合、「昨夜は機能しました」はファイルシステム層にマッピングされません。

  2. 02

    構成をイメージにベイク処理します。env、secret、または読み取り専用マウントを使用します。そうしないと、トークンをローテーションするたびに再構築が強制され、コンテナーの配信が無効になります。

  3. 03

    ディスクを埋める匿名ボリューム:実験からの名前のないキャッシュ ボリュームは静かに消費されます/var/lib/docker;名前付きボリュームまたは外部オブジェクト ストレージを優先します。

  4. 04

    常に 200 を返すヘルスチェック:モデル/構成の準備が整っていない状態で HTTP ポートのみをプローブすると、トラフィックが変化した後に大量の 502 が発生します。

  5. 05

    構成とトンネル構成の分岐:ingress が古い公開ポートを指しているため、外部の症状はコンテナー ログとは関係ありません。

  6. 06

    macOS ワークロードを Linux コンテナに強制的に入れる:ベアメタルの記事と同じ - Xcode/シミュレータ ジョブは、「マジック サンドボックス」Linux ではなく、リモート Mac エグゼキュータに属します。

「イメージがどこから来たのか、どのボリュームが保存されているのか、誰がアップグレードを所有しているのか」に答えることができたら、ベースラインとテンプレートに進みます。そうでない場合は、本番環境に入る前にステージングで概要資料を作成します。

両方のパスを実行する場合、1 つのリッスン + トンネル トポロジ コントラクトを共有します。コンテナをホスト ループバック上の 127.0.0.1 にマップし、cloudflared または同等のもので TLS を終了します。 systemd → Compose を移行すると、セキュリティ境界ではなく、プロセス スーパーバイザのみが交換されます。

インストール スクリプトと compose リポジトリの両方を維持する場合は、信頼できる単一のソースを宣言します。compose が正規であり、まれなベアメタル ケースに対して CI が systemd スニペットをレンダリングするか、その逆のいずれかです。デュアルトラック ドリフトは通常、片側のみで変更されたポート、ボリューム名、および環境パスとして現れます。

コンテナーは依存関係の地獄を緩和しますが、シークレットのローテーションや監査の必要性を取り除くわけではありません。 env_file を許可やローテーションなしでセーフとして扱うことは、インシデントの日付が遅れるだけで、道徳的にはトークンをコミットすることと同じです。

02

意思決定表: Compose プロダクション、systemd ベアメタル、パブリック バインディング

「四半期ごとのアップグレードあたりのコスト」の隣にある「インストールにかかる時間」を確認してください。コンテナの場合、初期費用は高くなりますが、繰り返しのコストは高くなります。プレースホルダー名/ポートを実際の値に置き換えます。

寸法パブリックIP上のゲートウェイsystemd + ループバック + トンネル (ベアメタル)Docker Compose の制作
配送単位手巻きのディレクトリ/スクリプトユニット + 設定ファイル画像ダイジェスト + 合成ファイル
アップグレードパス高ドリフトバイナリ/構成を置き換え、systemctlをロールしますイメージのプル、コンテナの再作成、ボリュームの検証
分離弱い中 (ユーザー/権限)より強力 (名前空間/cgroup - 完全な VM ではない)
可観測性DIYジャーナルはクリアですDocker ログまたはサイドカー エージェントを統合する
一般的なコスト最も高いセキュリティリスク適度なスクリプト画像サプライチェーン + ボリュームオペレーション

Compose はランタイム + 永続性 + 依存関係エッジを宣言します。ボリュームとタグに名前を付けることを拒否した場合、ディスク アラートが発生するまで混乱が延期されるだけです。

03

前提条件: Docker エンジン、Compose v2、およびサイジング

Ubuntu 24.04 LTS などでは、サポートされている Docker エンジンと Compose v2 プラグイン ( docker compose ) をインストールし、CI を本番環境から分岐させる従来のスタンドアロンの docker-compose バイナリを回避します。ログ、アンパック一時、同時接続用にゲートウェイを超えた RAM を確保します。 /var/lib/docker の成長を個別に監視します。

セキュリティはベアメタルの記事と一致します。アプリ ポートのパブリック リスナーなし、SSH キーのみ、デフォルト拒否ファイアウォールです。コンテナは名前空間を追加します。コンテナは魔法のように TLS やアクセス ポリシーを実装するわけではありません。

  1. 01

    ピンのバージョン:捕獲docker versionそしてdocker compose version運用手順書の中で。ステージング/本番マイナーを調整します。

  2. 02

    ログドライバー + ローテーション:デフォルトのjsonファイルセットを使用max-size/max-fileしたがって、1 つのおしゃべりなコンテナーがディスクを埋めることはできません。

  3. 03

    専用ネットワーク:Compose でカスタム ブリッジを宣言し、デフォルトでゲートウェイとトンネル サイドカーのみが通信できるようにします。

  4. 04

    レジストリの規律:ドキュメントレジストリ、イメージ名、ダイジェスト。本番環境のプルでは、​​テストしたのと同じレジストリを使用する必要があります。開発環境では docker.io を使用し、追跡せずに本番環境ではプライベート レジストリを使用することは避けてください。

  5. 05

    ボリューム/バインド戦略:読み取り専用構成マウント、ランタイム/キャッシュのみの書き込み可能ボリューム、モード 400 ファイルまたは Docker シークレットとしてのシークレット。

  6. 06

    ダウン/アップのリハーサル:ステージング実行中docker compose downそれからup -d; confirm volumes survive and tunnel upstream still targets the right loopback port.

info

注記:実際の OpenClaw イメージ名、環境キー、および CLI フラグはアップストリームのドキュメントに従います。以下の YAML は例示です。プレースホルダーを置き換えて、prod の前に未使用のキーを削除します。

04

スケルトンの構成: ポート、ボリューム、ヘルスチェック、アップグレードコマンド

ホスト ループバックがトンネルにフィードするように、127.0.0.1:host:container で公開します。これは、ベアメタル ガイドの「バインド ループバックのみ」と同じ規約です。ヘルスチェックは HTTP の準備が整っていることを証明する必要があります。アップストリームが config validate コマンドを出荷する場合は、起動中に新しいコンテナが強制終了されないように start_period を広げます。

docker-compose.yml
services:
  openclaw-gateway:
    image: ghcr.io/example/openclaw-gateway@sha256:<DIGEST>
    restart: unless-stopped
    env_file:
      - ./gateway.env
    volumes:
      - openclaw_data:/var/lib/openclaw
      - ./gateway.yaml:/etc/openclaw/gateway.yaml:ro
    ports:
      - "127.0.0.1:8787:8787"
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8787/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 40s

volumes:
  openclaw_data:

アップグレードの順序: ① docker compose ステージングをプルインしてダイジェストを検証します。 ② 名前付きボリュームのデータをバックアップするか、構成をエクスポートします。 ③ prod docker compose up -d --no-deps --build (未使用の場合は --build をドロップ) と状態を監視します。 ④ ホストからトンネルを通ってカールします。 ⑤ その後にのみ、docker image prune を検討してください (まだロールバック層が必要な場合は危険です)。

問題切り分けスタック: 構成/権限のコンテナー ログ。ループバック バインドの場合は host ss -tlnp。正しいポートのトンネル入口。インターネットで 502 が認識されるが、curl 127.0.0.1 が機能する場合は、最初にイメージではなく、ルーティングを疑ってください。

青/緑の場合は、2 つの構成プロジェクト (異なるプロジェクト名とループバック ポート) を短時間実行し、トンネルまたは内部 LB で重みをシフトします。その後、 docker compose -p old_project down を実行するか、古いコンテナーがボリューム ロックとバックグラウンド作業を維持します。

ゲートウェイがホストの Unix ソケットまたはローカル モデルのサイドカーに到達する必要がある場合は、network_mode: host を精査します。これにより、ポート マップの分離の一部がバイパスされ、変更は 2 人でレビューする必要があります。

warning

警告:決してコミットしないgateway.envAPI キーを使用します。 CI は、レンダリングされた構成環境を出力してはなりません。間違ったボリューム UID/GID は、多くの場合、即座にクラッシュするのではなく、不安定なヘルス チェックとして表示されます。

05

オンコールドキュメントの具体的な数字とトポロジに関するメモ

これらを使用して、「コンテナはフリーランチではない」に関するプラットフォームに合わせます。 P95 メトリクスとディスク カーブに置き換えます。

CPU だけではなく、再起動回数、異常な期間、ボリュームの使用状況についてアラートを出します。ゲートウェイ スタイルのサービスは、多くの場合、ディスクまたはファイル記述子が使い果たされた後にのみ雪崩を起こします。

  • Layers and disk: frequent pulls of large bases can add tens of GB per month under /var/lib/docker; pair alerts with volume backup policy.
  • Health intervals: too tight amplifies jitter, too loose slows traffic cutover; 30s interval + sane start_period is a common starting point.
  • Rollback window: keep at least one known-good digest and annotate compose with the change ticket—avoid “rollback == latest”.

Linux コンテナは OpenClaw ゲートウェイ、キュー、軽いオーケストレーションには適合しますが、Xcode、シミュレータ、Apple Silicon 機能は困難な壁にぶつかります。互換性シムに永遠にお金を払ったり、専用の Mac に実行を移したりする必要があります。ラップトップや、スリープ、アップデート、プロンプトによって自動化が中断される「一時的な」ホストでゲートウェイを実行する場合と比較して、契約した専用リモート Mac は長期間存続する Apple ワークロードを調整し、一方で Linux はコントロール プレーンとして Docker または systemd を維持し、障害ドメインがクリーンな状態を保ちます。安定したエージェントとビルド パイプラインの場合は、通常、NodeMini クラウド Mac Mini のレンタルがより良い答えです。ゲートウェイを VPS コンテナ内に保持し、間違ったレイヤーにパッチを適用する代わりに、重い作業を注文可能な実行ノードに送信します。

FAQ

FAQ

はい - 環境 (ステージング Compose、prod systemd) またはサービスごとに分割します。 listen+tunnel コントラクトを共有することで、2 つのゲートウェイが同じループバック ポートをめぐって競合することがなくなります。 OpenClaw のその他の投稿:カテゴリフィルター

チェックdocker logsそして、health コマンドがまだ新しいイメージ パスと一致するかどうか。ボリュームの権限と環境を確認します。さらに多くのコンピューティングについては、レビューを参照してくださいレンタル料金リモート Mac ノードの場合。

を検索してくださいヘルプセンターSSH/VNC およびネットワーク用。コンテナー ネットワークの場合は、ホストのファイアウォール ルールも確認し、docker network