10단계
10단계 — Compose·Readiness·Reverse Proxy·Rollback 운영하기
0회 조회
10단계 — Compose·Readiness·Reverse Proxy·Rollback 운영하기
프로세스가 살아 있다는 것과 요청을 처리할 준비가 됐다는 것은 다릅니다. DB·Redis·Kafka·Supabase 같은 의존성의 health를 확인하고, 준비된 서비스만 공개 입구에 연결합니다.
구성 원칙
- 외부 공개 포트는 Caddy 80/443로 좁히고 내부 API·Actuator·Prometheus는 네트워크 안에 둡니다.
depends_on: service_healthy는 필수 의존성에만 쓰고, Kafka처럼 서비스가 살아 있으면 consumer가 자체 재시도하는 경계는 문서에 남깁니다.- Prometheus는 개발 기본 기동을 느리게 하지 않도록
observabilityprofile로 선택하며 loopback에만 노출합니다. - Admin이 쓰는 Codingstairs 업로드 bind mount와 공개 앱의 read-only mount를 같은 호스트 경로로 맞춥니다.
Caddy가 /actuator/prometheus를 공개 프록시로 통과시키면 내부 상태가 외부에 노출됩니다. 내부 scrape와 공개 route는 별도 계약이어야 합니다. 배포 실패는 전체 compose를 내리지 않고 대상 서비스만 교체·복원합니다.
Codingstairs의 Docker SSR과 Fly 정적 mirror도 같은 원칙을 따릅니다. SSR/Fly CMS 공개 함수 계약을 공통 타입으로 검사하고, Fly image layer의 명시적 build profile이 DB import나 동적 route를 남기면 실패시킵니다. DB seed 뒤에는 Fly snapshot을 반드시 다시 빌드해야 두 사용자가 같은 courses·notes를 보게 됩니다.
필수 readiness와 선택 capability도 분리합니다. /health/ready는 검색에 필요한 DB·임베딩만 필수로 판정하고, /health/capabilities는 서비스별 DB·텍스트/Vision 모델·push·scheduler를 독립적으로 보여줍니다. 선택 기능 장애는 degraded로 알려 무관한 요청까지 not-ready로 만들지 않습니다.