# Worker node

> PentAGIメインホストから分離した専用強化サーバーで、agentコンテナを実行します。

本番環境では、信頼されていない [tool](https://pentagi.com/ja/docs/glossary/#tool) の実行は PentAGI を稼働させているマシンとは別の場所で行ってください。[Worker node](https://pentagi.com/ja/docs/glossary/#worker-node) は TLS で保護された Docker エンドポイントの背後で [agents](https://pentagi.com/ja/docs/glossary/#agent) のコンテナをホストするため、agent が実行するコマンドがメインホストに到達することはありません。

```mermaid
graph TB
  accTitle: Main node running PentAGI and a separate worker node running the tool containers
  subgraph Main node
    PA[PentAGI]
  end
  subgraph Worker node
    HD[Host Docker :2376 TLS]
    DIND[Docker-in-Docker :3376 TLS<br/>authorization policy + seccomp]
    W[Worker containers]
    N[Nested containers]
  end
  PA -->|TLS, creates workers| HD
  HD --> W
  W -->|TLS| DIND
  DIND --> N
```

## [Worker node を使用する理由](https://pentagi.com/ja/docs/deployment/worker-node/#why-a-worker-node)

* **分離。** Tool コンテナは専用のハードウェア上で実行され、独自のネットワーク境界を持ちます。
* **制御された Docker アクセス。** Docker を必要とする agents は、ホストのデーモンではなく、認可ポリシーを通じて強化された Docker-in-Docker デーモンと通信します。
* **帯域外テスト。** ワーカー上の専用ポート範囲が OOB コールバックをサポートします。

## [接続モード](https://pentagi.com/ja/docs/deployment/worker-node/#connection-modes)

* **標準（推奨）** — PentAGI はワーカーのホスト Docker に TLS 経由で接続してワーカーコンテナを作成し、ワーカーはその TLS エンドポイント経由で Docker-in-Docker にアクセスします。`DOCKER_INSIDE=true` を `DOCKER_INSIDE_HOST`、`DOCKER_INSIDE_TLS_VERIFY` および `DOCKER_INSIDE_CERT_PATH` と共に設定し、`DOCKER_SOCKET` は空のままにしてください。`.env` テンプレートの `/var/run/docker.sock` は、ワーカーノードのホスト Docker ソケットをすべての [sandbox](https://pentagi.com/ja/docs/glossary/#sandbox) にマウントします。`DOCKER_INSIDE_HOST` がなければ、agent は Docker にアクセスできません。
* **ダイレクト** — PentAGI が Docker-in-Docker と直接通信します。この場合、ホストのバインドマウントはポリシーによって拒否されるため、agents の Docker アクセスは無効にする必要があります。

## [セットアップ](https://pentagi.com/ja/docs/deployment/worker-node/#set-it-up)

両方のデーモンの TLS 証明書、強化された Docker-in-Docker の設定、ポリシーの更新と検証を含む完全な手順は、リポジトリ内の [worker node ガイド](https://github.com/vxcontrol/pentagi/blob/main/examples/guides/worker_node.md)に記載されています。