전환 후 프론트 경유 검증 추가 - /health 127.0.0.1 한정 개방

[m-a-king]

Situation

• 블록 소비 전환(슬롯 판정·전환을 infra 공용 블록 소비로 전환 #926) 후에도 core 와 extractor 의 배포에는 한 가지 비대칭이 남았다: extractor 는 슬롯 전환 직후 소비자 경로(프론트 → nginx → 새 슬롯)를 통째로 검증하는데 core 는 안 한다. 원칙적 이유가 아니라 역사적 우연 + 공개 프론트의 444 화이트리스트에 /health 가 없어 생긴 비대칭이다.
• 이 검증이 잡는 실패는 "앱은 건강한데 배달 경로가 끊김" 부류다. extractor 이행 배포의 Host 헤더/444 사고가 정확히 그 실례였고, TLS·레이트리밋·경로 화이트리스트·SSE 특례까지 낀 core 의 공개 프론트가 오히려 끊길 지점이 더 많다.

Task

• core 도 전환 직후 프론트 경유 검증을 하도록 통일하되, /health 의 외부 차단(화이트리스트에서 /health 제거 - 외부 소비자 없음 실측 #833)은 그대로 유지한다.

Action

• nginx conf (dev·prod 동일 반영): location = /health 를 신설해 박스 자신(127.0.0.1)에게만 프록시하고, 그 외 출처는 종전 catch-all 과 같은 444 로 닫는다. 화이트리스트에서 /health 제거 - 외부 소비자 없음 실측 #833 의 "외부 uptime 모니터 도입 시 재개방" 조건과는 별개다 - 이건 외부 개방이 아니다. 두 conf 에 함께 넣어야 promote 때 prod 배포의 검증도 성립한다.
• deploy: slot_switch 호출에 --verify-cmd 를 추가한다. 블록이 verify 를 원복 경계 안에서 이미 지원하므로(infra#39) 인자 하나로 끝난다 - 블록 추출의 이득이 회수되는 지점.
• 검증 배선도 블록으로: 처음엔 raw curl 로 배선하려 했으나, TLS 프론트를 IP 로 두드리는 데 필요한 -k·Host 헤더를 healthcheck 블록에 옵션으로 올려(infra#40) verify-cmd 가 extractor 와 같은 "healthcheck 블록 호출" 한 줄이 되게 했다. 폴링·재시도·종료코드 배선의 정본은 블록 한 곳이고 호출부는 값(URL·간격·도메인)만 준다.

구분	종전 core	이 PR 후
전환 직후 검증	없음 (앱 포트 직결 헬스만)	프론트 443 경유 /health 200 확인
검증 실패 시	-	이전 upstream 원복 + 새 슬롯 정리 (블록 원복 경계)
/health 외부 노출	444	444 그대로 (127.0.0.1 만 예외)

• 접근 세부: --insecure 는 cert 가 도메인 앞이라 IP(127.0.0.1) 접속의 hostname 검증만 끄는 것이고, SNI 미전송이어도 박스당 서버 블록이 하나뿐이라 default 매칭으로 닿는다. 짧은 재시도(2s x 5)는 reload 직후 워커 교체의 순간 흔들림 흡수.

Result

• dev 머지 시 자동 배포가 이 검증을 처음 실행한다. prod 는 conf·deploy 가 한 PR 로 같이 가므로 다음 promote 에서 그대로 성립한다.
• 검증: 스텝 스크립트 bash -n·shellcheck 클린. conf 문법은 CI nginx-validate(런타임 의존 더미 우회)가 게이트다 (로컬 Docker 데몬이 안 올라와 같은 스크립트를 CI 에 위임).

---

연관 이슈

• blue-green 슬롯 판정·전환을 공용 블록으로 추출 infra#37

[github-actions]

Discord 스레드 연동용 메타데이터입니다. discord-pr-bot 워크플로가 자동 생성하며, 수정·삭제하면 PR 과 Discord 알림 연동이 끊깁니다.

[coderabbitai]

Warning

Review limit reached

@m-a-king, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0f23ee4c-dd97-4dc9-89fb-f38e3d482c3a

📥 Commits

Reviewing files that changed from the base of the PR and between 672c094 and 022e6b0.

📒 Files selected for processing (3)

• .github/workflows/deploy.yml
• infra/nginx/api.piki.day.conf
• infra/nginx/dev.api.piki.day.conf

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}