# Rollback과 연결 중단 대응

- `current` 링크만 바꾸면 실행 컨테이너는 바뀌지 않습니다.
- rollback은 이전 Compose/image를 실제 적용하고 health 확인 후 active 기록을 바꿉니다.
- DB·Event·Artifact·영상·secret은 되돌리거나 삭제하지 않습니다.
- 실패 즉시 자동 rollback하지 않습니다. 실제 상태 확인과 승인 뒤 진행합니다.

## 1. 유지보수 정지

기존 Runtime 운영 도구로 각 채널 Stop → cleanup/child_reaped/writer 해제 확인 → 관리 서비스 정지를 수행합니다.
확인되지 않은 child에 `kill -9`, `docker down -v`를 사용하지 않습니다.
이 Kit는 그 lifecycle 절차를 새로 구현하지 않습니다. 아직 컨테이너가 running이면 `MAINTENANCE_REQUIRED`로 차단합니다.

## 2. 이전 정상 버전 선택

```bash
CTL=/opt/contextra/deployctl
sudo "$CTL" status
# history에 나온 검토된 transaction ID 사용
sudo "$CTL" rollback deploy-실제_transaction_ID
sudo "$CTL" rollback deploy-실제_transaction_ID --apply
sudo "$CTL" doctor
```

이전 image/model/config와 compatibility_id가 맞아야 합니다. 변경된 private env나 회전된 인증값을 과거 snapshot으로 덮지 않습니다.
그 경우 `CONFIG_CHANGED`로 중단하고 담당자가 현재 보안정보에 맞춘 **새 release**를 준비합니다.

## 3. 연결이 끊긴 경우

```bash
sudo /opt/contextra/deployctl recover
```

`INTENT/FAILED`, stage, transaction을 확인합니다. Docker CLI timeout은 Docker 작업이 취소됐다는 증거가 아닙니다.
새 컨테이너가 일부 실행됐을 수 있으므로 실제 서비스 상태를 확인합니다.
원인 확인·컨테이너 정지 후에만 출력된 inflight SHA256로 검토 완료를 표시합니다.

```bash
sudo /opt/contextra/deployctl recover --expected 검토한_inflight_SHA256 --apply
```

이는 재배포가 아니라 REVIEWED 기록입니다. 부분 산출물을 지우지 않으며 새 release ID로 재개합니다.

## 4. current/active 불일치

전원/연결 중단이 두 파일 전환 사이에 일어나면 자동 판단하지 않습니다.
transaction의 `activation-proposal.json`, `compose.json`, 실제 container/image ID를 담당자가 대조합니다.
사용자가 링크를 임의로 바꾸거나 active 파일을 빈 값으로 덮지 않습니다. 이 경우 수동 복구 검토가 필요합니다.

## 5. 정리

v1은 release/image를 자동 삭제하지 않습니다. 최소 현재+직전2개를 보관합니다.
공간 부족 시 담당자가 참조 중인 모델/이미지/transaction을 확인하고 필요한 배포 자료만 정리합니다.
`docker system prune`, volume 삭제는 이 절차에 없습니다.