2026 OpenClaw Docker Compose 운영 기준선: mem_limit, 헬스체크, 재시작 정책, json-file 로그 로테이션 재현 사례(VPS 24/7)

mem_limit · healthcheck·start_period · restart 백오프 · json-file 로테이션과 디스크 점검

2026 OpenClaw Docker Compose 운영 기준선

VPS 24/7 에서 OpenClaw 를 돌리는 팀은 세 가지 충격에 자주 맞습니다. 너무 짧은 healthcheck콜드 스타트 Gateway 를 죽이는 일, WASM 피크보다 낮은 mem_limit 으로 발생하는 Exit 137, 그리고 기본 json-file 로그가 디스크를 채우는 문제입니다. 개발용 compose 와 운영용 compose 의 최소 차이 집합, 여섯 단계 재현 기준선, 재시작 지터 시 사람이 개입해야 하는 조건을 정리하고 Exit 137·allowedOrigins 조사 글이미지 핀과 롤백 과 상호 링크합니다.

01

노트북에서 되던 compose 가 셋째 주쯤 스스로를 망가뜨리는 이유

개발 환경은 자원 상한을 끄고 헬스 간격을 짧게 하며 로그를 콘솔로 보냅니다. 무인 운영 에서는 이것이 재시작 폭풍 으로 겹칩니다. Gateway 가 아직 18789 를 열기 전에 unhealthy 가 되고 restart: always 가 초 단위로 올라오며 백오프보다 로그와 inode 가 먼저 고갈됩니다.

OpenClaw 는 첫 컴파일과 모델 로드 로 RSS 가 튑니다. mem_limit 을 정상 상태 평균만으로 잡으면 새벽에 OOM killer 가 조용히 프로세스를 종료합니다. 여기서는 각 설정이 docker inspect 나 호스트 지표에 매핑되게 합니다.

  1. 01

    start_period 가 너무 짧음: 프로브가 먼저 실패하고 UI 는 끊임없는 재시작처럼 보입니다.

  2. 02

    mem_limit 과 피크 불일치: 첫 WASM·의존성 스파이크가 cgroup 을 넘어 137 로 끝나고 애플리케이션 로그는 얇습니다.

  3. 03

    json-file 무한 증가: 콜백과 디버그 로그가 바쁜 PR 검증기에 루트 파티션을 읽기 전용으로 만듭니다.

  4. 04

    백오프 없는 restart: 설정 오류와 오탐이 겹쳐 CPU·IO 를 동시에 고갈시킵니다.

  5. 05

    개발 바인드 마운트를 운영에: 핫 리로드와 느슨한 권한이 비밀 표면을 넓힙니다.

02

개발 compose 대 운영 compose: 자원과 로그의 최소 차이 표

동일 저장소의 두 override 를 전제로 합니다. docker-compose.yml 에 공통 정의를 두고 docker-compose.prod.yml 에는 운영 차이만 추가해 복붙 드리프트를 막습니다.

차원개발 기본값운영 기준선
메모리상한 없음 또는 호스트 전체명시적 mem_limit 과 콜드 여유. Exit 137 글과 교차 검증
헬스체크짧은 interval, start_period 없음start_period 로 콜드 커버. retries·timeout 은 SLA 언어에 맞출 것
재시작unless-stopped 또는 없음on-failure 또는 상한이 있는 always 와 호스트 알림
로그 드라이버json-file 기본 등max-size + max-file. 수동 truncate 에 의존하지 않음
볼륨·비밀소스 트리 바인드설정은 읽기 전용 마운트. 비밀은 env_file 또는 secret. 이미지 레이어에 넣지 않음

운영 전용 줄은 Grafana 나 티켓 필드에 반드시 대응해야 하며 소원 목록으로 끝내지 마십시오.

03

여섯 단계 기준선: mem_limit 보정에서 Gateway 준비에 맞춘 프로브까지

이미지가 핀 전략 을 따른다고 가정합니다. :latest 라면 staging 에서 전체 콜드를 샘플링한 뒤 운영 override 로 옮기십시오.

  1. 01

    피크 샘플링: staging 에서 docker stats --no-stream 과 컨테이너 내부 ps 로 첫 Ready 전후 10분 RSS 를 기록합니다.

  2. 02

    mem_limit 기입: 피크에 합의된 안전 계수를 곱해 compose 에 반영하고 호스트 swap 정책도 문서화합니다.

  3. 03

    준비 프로브 정의: Gateway 가 바인딩하는 루프백과 동일한 HTTP 또는 CMD 경로를 사용합니다.

  4. 04

    start_period 설정: 첫 의존성 설치와 WASM 컴파일 창을 덮습니다. 값은 평균이 아니라 콜드 p95 를 기준으로 합니다.

  5. 05

    json-file 조이기: 서비스마다 logging 블록에 max-sizemax-file 을 두고 로그 디렉터리 증가율을 점검합니다.

  6. 06

    재시작 훈련: 실패 프로브를 한 번 주입해 간격·백오프·알림이 런북과 맞는지 확인합니다.

yaml
services:
  openclaw:
    mem_limit: "2g"
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "5"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1:18789/health"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 180s
    restart: on-failure:5

안내: 실제 헬스 경로는 이미지에 맞춥니다. TCP 만 가능하면 CMD-SHELLnc 를 쓸 수 있으나 HTTP 대비 오탐 면을 티켓에 남깁니다.

04

restart 지터와 json-file: 자동화를 멈춰야 할 때

docker events 가 5분 안에 런북 임계를 넘기면 먼저 설정 오류와 잘못된 unhealthy 를 의심합니다. RAM 부족만 의심하고 재시작을 계속하면 로그 쓰기 증폭이 커집니다.

루트가 읽기 전용이면 트래픽을 먼저 빼거나 리버스 프록시를 멈추고 Exit 137 글 순서로 공간을 확보합니다. 디스크 건전성 확인 전에 compose up -d 로 데이터 볼륨을 덮어쓰지 마십시오.

주의: max-file 을 낮추면 핫 로그가 더 빨리 사라집니다. 더 긴 보존이 필요하면 객체 스토리지나 별도 로그 호스트로 보내고 단일 파일을 무한 확장하지 마십시오.

  1. A

    배포 동결: 임계를 넘는 연속 재시작이면 파이프라인 입구를 막습니다.

  2. B

    현장 확보: inspect 의 Health·OOM 관련 부분과 최근 200줄 로그를보냅니다.

  3. C

    설정 롤백: 이전 compose override 로 되돌리고 재현 패키지를 사후 분석용으로 보관합니다.

05

참조 파라미터와 용량 검토 출발점

아래 수치는 착수와 온콜 런북의 출발점 입니다. 실제 콜드 히스토그램과 디스크 성장 곡선으로 바꾸고 고객 SLA 로 팔지 마십시오.

같은 VPS 에 리버스 프록시나 작은 DB 가 함께 있으면 mem_limit 과 로그 IO 가 이웃과 경쟁합니다. 검토 시 컨테이너 RSS·호스트 가용 메모리·디스크 쓰기 지연 세 곡선을 한 대시보드에 요구하십시오.

  • start_period 바닥: 한 번의 전체 콜드 p95 를 최소 덮습니다. 이주 연속 무타임아웃이면 조이되 롤백 창을 남깁니다.
  • json-file 성장률: 단일 서비스 일일 로그가 디스크 예산 비율을 넘기면 채널 로그 레벨을 나누거나 중앙 로그로 보냅니다.
  • 재시작 빈도 임계: 15분에 N회 초과를 알림과 사람 개입 조건에 적어 자동화가 설정 결함을 가리지 않게 합니다.
호스트 형태로그 전략 출발이미지 핀과의 관계
2 vCPU / 4 GB더 작은 max-size, 짧은 보존, 적극적 외부 전송digest 고정으로 콜드 길이의 깜짝 업그레이드 방지
4 vCPU / 8 GBmax-file 은 약간 완화 가능하나 로테는 필수staging 과 prod 는 다른 태그라도 동일 digest 로 검증
혼합 부하데이터 디스크나 로그 전용 볼륨으로 DB 파티션과 분리업그레이드 창은 핀 글과 맞춤

임시 소형 VPS 에 OpenClaw 를 얹으면 메모리·디스크·비밀 순환을 동시에 빚집니다. 자체 베어메탈은 전력과 회선 SLA 리스크와 맞바꿉니다.

계약된 연산력·선택 가능 리전·감사 가능 대역 이 필요하고 24/7 에서 Gateway 와 채널을 관측 가능하게 유지하려는 팀에는 클라우드 Mac Mini 임대가 현실적입니다. VpsMesh Mac Mini 클라우드 임대 는 compose 기준선과 리버스 프록시·백업을 한 용량 내러티브로 받아들이기 쉽습니다.

FAQ

자주 묻는 질문

프로브 사용자·PATH·start_period 가 콜드를 덮는지 확인하고, 필요하면 allowedOrigins·리버스 프록시 글 과 루프백 경로를 대조합니다.

호스트 dmesg·종료 코드 후 피크를 다시 샘플링해 limit 를 조정합니다. 세부는 Exit 137 글. 플랜 비교는 가격 페이지 입니다.

로컬 핫 보존 기간이 짧아집니다. 더 긴 보관은 중앙 저장소로 보냅니다. 정책은 고객 센터 를 확인하십시오.