Compose readiness와 부분 롤백의 경계
컨테이너가 running이어도 DB 연결·필수 테이블·내부 의존성이 준비되지 않았을 수 있습니다. readiness는 사용자 요청을 받을 수 있는 상태를, liveness는 프로세스가 살아 있는지를 나타내야 합니다.
Compose readiness와 부분 롤백의 경계
컨테이너가 running이어도 DB 연결·필수 테이블·내부 의존성이 준비되지 않았을 수 있습니다. readiness는 사용자 요청을 받을 수 있는 상태를, liveness는 프로세스가 살아 있는지를 나타내야 합니다.
공개 경계와 readiness
운영 환경은 공개 입구를 Caddy로 좁히고 앱·DB·Kafka·Prometheus 포트는 loopback/내부 네트워크에 둡니다. Java Actuator와 Python /metrics는 내부 scrape 경로이고, Caddy의 공개 route에서는 관리 endpoint를 차단합니다. Prometheus는 observability profile에서만 시작합니다.
공유 저장소와 rollback
콘솔은 공개 콘텐츠 upload host path에 쓰고 공개 앱은 같은 path를 read-only로 마운트합니다. 이 두 프로세스가 다른 경로를 보면 업로드 성공과 공개 표시 사이에 조용한 불일치가 생깁니다.
배포 실패 때 전체 stack을 내리지 말고 대상 image만 replace/rollback합니다. 로그와 readiness 결과가 남아야 운영자가 영향 범위와 복원 여부를 판정할 수 있습니다.
이 글에서 만나는 용어
infra 카테고리의 다른 글
카테고리 전체 보기 →관련 글
필수 readiness와 선택 capability를 분리하기
프로세스가 살아 있다는 사실, 핵심 검색 요청을 처리할 준비가 됐다는 사실, 선택 기능이 모두 정상이라는 사실은 서로 다릅니다. 하나의 ready 값에 전부 넣으면 선택 모델 장애가 전체 재시작으로 이어지고, 핵심 DB 장애를 liveness가 가립니다.
Release를 Smoke와 Rollback 증거로 닫기
이미지가 만들어졌다는 사실은 사용자가 정상 경로를 사용할 수 있다는 증거가 아닙니다. 검사한 commit과 실행 image를 묶고, health 뒤에 실제 DB를 읽는 smoke를 실행해야 합니다.
Docker Compose 패턴
단일 호스트에서 여러 컨테이너 (웹 · DB · 캐시 · 큐) 를 함께 띄울 때 가장 가벼운 길이 Compose. YAML 한 파일로 의존 · 네트워크 · 볼륨 · 헬스체크를 묶음. 본격 오케스트레이터가 아니라는 점이 강점이자 한계. 이 글은 Compose 의 v1 vs v2 차이 · compose.yaml 핵심 키 ·…