Compose readiness와 부분 롤백의 경계
컨테이너가 running이어도 DB 연결·필수 테이블·내부 의존성이 준비되지 않았을 수 있습니다. readiness는 사용자 요청을 받을 수 있는 상태를, liveness는 프로세스가 살아 있는지를 나타내야 합니다.
컨테이너가 running이어도 DB 연결·필수 테이블·내부 의존성이 준비되지 않았을 수 있습니다. readiness는 사용자 요청을 받을 수 있는 상태를, liveness는 프로세스가 살아 있는지를 나타내야 합니다.
안전한 이미지 교체
변경 Git SHA로 불변 이미지를 만듭니다.
대상 서비스만 새 이미지로 재생성합니다.
프로세스뿐 아니라 DB·필수 의존성과 공개 smoke를 확인합니다.
모두 통과하면 유지하고 하나라도 실패하면 이전 이미지로 되돌립니다.
공개 경계와 readiness
운영 환경은 공개 입구를 Caddy로 좁히고 앱·DB·Kafka·Prometheus 포트는 loopback/내부 네트워크에 둡니다. Java Actuator와 Python /metrics는 내부 scrape 경로이고, Caddy의 공개 route에서는 관리 endpoint를 차단합니다. Prometheus는 observability profile에서만 시작합니다.
공유 저장소와 rollback
| 신호 | 의미 | 트래픽 판단 |
|---|---|---|
| 프로세스 실행 | liveness | 아직 전달하지 않음 |
| DB·필수 의존성 준비 | readiness | 전달 가능 |
| 새 이미지 readiness 실패 | 배포 실패 | 이전 이미지를 유지 |
콘솔은 공개 콘텐츠 upload host path에 쓰고 공개 앱은 같은 path를 read-only로 마운트합니다. 이 두 프로세스가 다른 경로를 보면 업로드 성공과 공개 표시 사이에 조용한 불일치가 생깁니다.
배포 실패 때 전체 stack을 내리지 말고 대상 image만 replace/rollback합니다. 로그와 readiness 결과가 남아야 운영자가 영향 범위와 복원 여부를 판정할 수 있습니다.
관련 강좌: Compose·Readiness·Reverse Proxy·Rollback
검증은 컨테이너 상태뿐 아니라 공개 health 응답, 내부 의존성 단절 시 비정상 판정, 이전 이미지 복귀 후 정상 응답까지 포함합니다.