# Worker node

> 메인 PentAGI 호스트와 분리된 전용 강화 서버에서 agent 컨테이너를 실행합니다.

프로덕션 환경에서는 신뢰할 수 없는 [tool](https://pentagi.com/ko/docs/glossary/#tool) 실행을 PentAGI가 동작하는 머신에서 분리하세요. [Worker node](https://pentagi.com/ko/docs/glossary/#worker-node)는 TLS로 보호되는 Docker 엔드포인트 뒤에서 [agents](https://pentagi.com/ko/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/ko/docs/deployment/worker-node/#why-a-worker-node)

* **격리.** Tool 컨테이너는 자체 네트워크 경계를 갖춘 전용 하드웨어에서 실행됩니다.
* **제어된 Docker 접근.** Docker가 필요한 agents는 호스트 데몬 대신 인가 정책을 통해 강화된 Docker-in-Docker 데몬과 통신합니다.
* **대역 외 테스트.** 워커의 전용 포트 범위가 OOB 콜백을 지원합니다.

## [연결 모드](https://pentagi.com/ko/docs/deployment/worker-node/#connection-modes)

* **표준(권장)** — PentAGI가 TLS를 통해 워커의 호스트 Docker에 연결하여 워커 컨테이너를 생성하고, 워커는 해당 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`이 모든 [sandbox](https://pentagi.com/ko/docs/glossary/#sandbox)에 워커 노드의 호스트 Docker 소켓을 마운트합니다. `DOCKER_INSIDE_HOST`이 없으면 agent는 Docker에 접근할 수 없습니다.
* **직접** — PentAGI가 Docker-in-Docker와 직접 통신합니다. 이 경우 정책에 의해 호스트 바인드 마운트가 거부되므로 agents의 Docker 접근을 비활성화해야 합니다.

## [설정 방법](https://pentagi.com/ko/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)에 나와 있습니다.