# test Contextra 컨테이너 자동기동 정책

- 완료: 2026-10-12 13:08 KST, profile ltb1021 / test.
- 범위: test Contextra 5개 컨테이너의 재부팅 후 자동기동. SSIMS와 원격 서버 설정은 변경하지 않았다.
- 검증 상태: 지속 설정/현재 컨테이너 정합과 비중단 검증 완료. 실제 재부팅은 하지 않았다.

## 적용 결과

| 서비스 | 이전 | 적용 후 |
| --- | --- | --- |
| Analytics | on-failure:3 | unless-stopped |
| Gateway | no | unless-stopped |
| Sidecar | no | unless-stopped |
| PostgreSQL / Redis | unless-stopped | 유지 |

실행 중 호스트/Docker가 재기동되면 컨테이너를 자동 기동한다. 사용자가 `ct stop` 또는
Docker Stop으로 명시적으로 정지한 컨테이너는 재부팅 후에도 정지를 유지한다. 다시 사용할 때는
기존 `ct start`를 사용한다. 별도의 systemd Runtime 기동자를 중복 추가하지 않았다.

채널 자동 Start/Stop은 추가하지 않았다. 기존 `load_and_autostart`는 설정만 읽고 명시적인
Start 전에는 분석 Pipeline을 기동하지 않는다. Web이 독립적으로 보내는 요청을 차단하는 설정은 아니다.

## ct 지속 설정과 보존 경계

- active pointer: `/workspace/contextra-runtime-config/ct/runtime/state/active.json`.
- 새 transaction: `autostart-20261012T130646`.
- 새 transaction의 `compose.json`, `approved.json`, `compose.physical.json`과 semantic hash를 정합화했다.
- 이전 `storage-20261007T112447` transaction은 원문 그대로 보존했다.
- 기존 ct 설정/자료 작업 lock을 사용했다. 미완료 apply/network/enrollment 작업 없음과 actual 값을 재확인했다.
- Runtime 반영은 기존 컨테이너3개에 `docker update --restart unless-stopped`만 실행했다.
- image/env/인증/mount/network/자원/카메라 설정, 원래 Compose 입력과 input-baseline은 변경하지 않았다.
- 이후 ct의 환경 변경 준비도 active Compose를 기준으로 하므로 이 정책을 상속한다.
- Docker restart policy는 현재 컨테이너에 즉시 반영되지만 기존 Compose config-hash label은
  재생성 없이 바뀌지 않는다. Compose `--dry-run up` returncode0에서 다음 명시적 `ct start`는
  Analytics/Gateway/Sidecar3개를1회 Recreate할 계획임을 확인했다. 실제 실행은 하지 않았다.
  호스트 재부팅의 Docker 자동기동은 기존 컨테이너를 시작하는 경로라 이 재생성과는 다르다.
  채널 사용 중 불필요하게 `ct start`를 재실행하지 말고 기존처럼 정상 Stop 뒤 사용한다.

## 검증

- Compose normalize/구문 검사, pinned image 검사, ct drift 검사와 `ct status` returncode0.
- 5개 실제 restart policy와 persistent policy 일치.
- 컨테이너 ID/image/PID/StartedAt, restart 이외 HostConfig/Config/mount/network 전후 일치.
- 채널36개 stopped/error0 및 run/상태 전후 일치.
- Analytics readiness: Triton/PostgreSQL/Redis 정상. WSS connected=true/auth error 없음.
- 재부팅, service restart/recreate, 채널 API Start/Stop, GPU/CDI 복원, 원격 설정 변경 모두0회.
- 첫 pre-apply 검사에서 Docker mount 배열의 표시 순서 변화가 탐지돼 변경 전에 멈췄다.
  동일 mount 내용임을 확인한 뒤 destination 기준 정렬 비교로 보완했다. 첫 계획은
  `plan-order-sensitive.json`으로 보존했으며 실제 적용은 새 `plan.json` 기준1회다.
- 결과와 정합성 검증은 `receipt.json`, 전후 비교 기준은 `plan.json`, 승인 범위 helper는
  `policy_change.py`다. 성공 helper는 반복 실행하지 않는다.

## 다른 서버 확인

- AI 서버2: 2026-10-12 SSH 읽기 전용 확인. `contextra-ai2-runtime.service`가 enabled이며
  storage/mount/Docker 준비 후 `/usr/local/bin/ct start`를 실행한다. 컨테이너5개는 running이고
  restart policy는 모두 no다. systemd가 자동기동을 소유하므로 test와 구현 방식은 다르다.
  조회 당시 unit 자체는 inactive였으며, 설정 enabled 확인을 실제 재부팅 성공으로 표현하지 않는다.
- 청계산: SSH1023 연결이 No route to host여서 현재 설정은 재확인하지 못했다.
  기존 2026-09-30 기록에는 systemd enabled와 회사망 재부팅 후5서비스 기동 검증이 있다.
  현재 현장 상태를 과거 기록만으로 확정하지 않는다.

## 복귀와 다음 재부팅

설정 복귀는 별도 승인 후 진행한다. `receipt.json`의 after pointer와 현재 active가 같고,
새 transaction/컨테이너에 후속 변경이 없는지 먼저 확인한다. 그 뒤 before pointer와 위 이전
정책3개만 복귀할 수 있다. 이전 image로 rollback하거나 컨테이너/채널을 재시작하는 작업은 아니다.
ct의 `config restore`는 과거 별도 배포 journal을 대상으로 할 수 있으므로 이번 정책의 복귀로 사용하지 않는다.

다음 실제 재부팅 시 5개 기동, GPU/CDI, 모델/API/WSS 준비와 채널의 명시 Start 대기를 확인하면 된다.
현재 정상 동작 중이므로 이번 검증을 위해 재부팅하거나 채널을 재시험할 필요는 없다.

수정 범위는 비저장소 runtime 설정과 이 전용 evidence뿐이다. 다른 세션의 Git 문서는 변경하지 않았다.