# 현장 최초 Bootstrap

## 이미지 식별

기존 Docker image ID는 config digest이고 containerd 저장소는 OCI manifest digest를 표시할 수 있다.
`image_identity.resolve`는 manifest 원문 hash와 config.digest를 대조한 뒤 실제 실행 ID를 사용한다.
release manifest의 원래 승인 ID를 수정하지 않으며 두 ID는 transaction의 image-identities.json에 기록한다.
이미 로드된 이미지가 검증되면 image load를 반복하지 않는다. 조회 실패나 다른 config는 우회하지 않는다.
config ID로 주소 지정할 수 없는 경우에만 최대64개 로컬 이미지 목록에서 동일 증거를 찾는다.

## 최초 현장 설정

- 기존 FULL은 보존하고 수정된 host 도구는 별도 deploy-tools snapshot으로 준비한다.
- 검증된 후보의 model install을 사용해 Medium만 active repository에 배치한다. engine 재변환은 없다.
- 실제 mount/UUID와 physical 경로를 확인하고 source/image/CA/secret/런타임 상태를 구분한다.
- Redis reader와 publisher/internal/health 계정은 분리한다. 관제의 정확한 출발IP에만 공개포트 접근을 허용한다.
- 방화벽은 exact 목적IP/port와 전용 체인만 사용하며, Docker 재시작 후 재적용되도록 systemd 순서를 둔다.
- 비밀번호/키/token은 private 경로만 사용한다. 루트 관리자 입력과 관제 로그인 입력은 별개다.
- 인증서·session 파일은 컨테이너 UID가 읽을 수 있는 최소권한으로 준비한다.

## 인증과 기동

승인된 CA 지문 확인 -> 키/CSR 준비 -> 로그인 -> CSR 발급 -> key/SAN/기간/용도 검증 -> 서비스 기동.
초기 login observer가 아직 열리지 않은 WSS에 먼저 접속할 수 있다. 로그인 성공과 WSS 준비를 분리한다.
기동 후 재연결이 필요하면 원장과 session/token 상태를 확인한 통제된 재로그인만 한다.
기존 token이 폐기될 수 있으므로 host 파일 갱신만으로 실행 중 Sidecar 메모리가 바뀐다고 가정하지 않는다.

## 완료 범위

모델/내부 API readiness, 인증 로그인/발급, WSS bootstrap/heartbeat, Redis reader 접속을 각각 기록한다.
카메라 등록0/Start0이면 실제 영상·bbox 소비·Event/Artifact GET/POST 성공은 아직 아니다.
관제의 Redis 소비가 없으면 주소·계정 준비 완료와 실제 소비 미확인을 분리한다.
실패 시 자기 project만 정상 정지하고 원본/실패원장을 보존한다. 자동 rollback/카메라 재Start는 없다.
sudo 임시파일은 필요 기간만 유지하고 완료 시 삭제한다. 서비스 private credential은 삭제 대상이 아니다.