6.7 KiB
6.7 KiB
tags
| tags | ||||||
|---|---|---|---|---|---|---|
|
260310 51123 포트 진입점 프로젝트 경계 리서치
상위 원칙
- Infra Project Identity
- Runtime Principles
- Operational Guardrails
- 공통 작성 원칙: 0_VALUE Writing Principles
관련 문서
- Infra Journey
- 23서버 워크스페이스 SSOT 구조전환 리서치
- 24서버 실서비스 운영전환 리서치
- 23 gateway MONITOR_URL 구주소 잔존으로 24 monitor 프록시 실패 복구
Facts
1. 51123 공개 진입 포트는 현재 80, 443, 51123, 3000, 9000 축이 보인다
ss -tlnp기준 공개 리슨 포트는80,443,51123,3000,5432,7687,8000,8100,8200,8505,9000,9200,9600이다.- 이 중 외부 웹 진입면은
80/443의 nginx다. 3000은 Gitea,9000은 auth-server,51123은 SSH다.5432,7687,8000,8100,8200,8505,9200,9600은 운영상 직접 접근 가능한 상태지만, 모두 공용 진입면으로 설계된 것은 아니다.sudo ufw status numbered기준 전체 허용은 아니다.80/443,51123은 광범위 허용5432,7687은 일부 출발지 대역만 허용- 반면
8000,8100,8200,8505,9000,9200,9600은 현재 UFW 규칙상 별도 제한이 보이지 않는다
2. ro-being.com의 공용 API 진입은 대부분 8100 gateway로 모인다
/api/는localhost:8100으로 프록시된다./admin/api/도localhost:8100으로 프록시된다./gateway/도localhost:8100으로 프록시된다.- 따라서
ro-being.com기준 공용 API 입구의 중심은 현재robeing-gateway:8100이다.
3. robeing-gateway는 멀티 프로젝트 공용 게이트웨이가 아니라 사실상 robeing 전용 게이트웨이다
- 게이트웨이 코드의 핵심 엔드포인트는
/api/chat,/api/stats/{robeing_id},/api/preferences/{path},/slack/events,/slack/interactive,/api/workspace/*,/api/config,/api/history,/api/auth/logout,/api/cache/clear다. /api/chat은 사용자 workspace 또는 기본 robeing을 조회한 뒤 최종적으로robeing의/api/message로 프록시한다./api/stats/*,/api/preferences/*는MONITOR_URL, 즉robeing-monitor계열을 본다.- 즉
8100은 현재robeing 채팅 + robeing-monitor 보조 API + Slack 연동을 묶는 제어면이다.
4. 다른 서브 프로젝트는 현재 robeing-gateway를 공용으로 쓰지 않는다
goosefarminvesting는/goosefarm/api/ -> localhost:8200/api/로 nginx가 직접 프록시한다.starsandi는ro-being.com아래에서 더 이상 내부 프록시를 쓰지 않고https://starsandi.com으로 리다이렉트된다.git.ro-being.com은localhost:3000Gitea로 직접 간다.auth.ro-being.com은localhost:9000auth-server로 직접 간다.- 실도메인 확인 결과도 일치한다.
https://ro-being.com/ -> 200https://ro-being.com/api/healthz -> 405(/api/*가 실제 gateway로 전달됨을 보여줌)https://git.ro-being.com/ -> 200https://starsandi.com/ -> 307 /kohttps://auth.ro-being.com/ -> 404(서브도메인 프록시는 존재하지만 루트 엔드포인트 자체는 미구현)
5. robeing 경로 안에서도 ingress 기준이 둘로 나뉜다
ro-being.com/api/*는8100 gateway를 거친다.- 반면
ro-being.com/rb8001/*는192.168.0.106:8001로 직접 프록시된다. - 즉
robeing내부에서도채팅/monitor 보조 API는 gateway,rb8001 직접 호출은 24 실행면 직결구조다.
6. 현재 51123에서 확인되는 프로젝트별 주요 런타임 포트는 아래와 같다
8000:admin-dashboard-backend8100:robeing-gateway8200:goosefarm-app8505:robeing-skill-news9000:auth-server9200,9600:opensearch3010:starsandi-web(127.0.0.1)8509:starsandi-api-py(127.0.0.1)
7. 현재 운영 판단에 필요한 핵심 경계는 프로젝트 수보다 진입 방식이다
robeing:nginx -> gateway(8100) -> 24 robeing/monitor와nginx -> 24 rb8001 직접이 같이 존재한다.goosefarminvesting:nginx -> 8200 직접starsandi:starsandi.com -> 3010/8509,ro-being.com에서는 리다이렉트만 담당gitea/auth: 각각 독립 서브도메인 direct proxy
Interpretation
1. 지금 필요한 문서는 “포트 목록”보다 “진입점-책임-프로젝트 경계표”다
- 같은 포트라도
공용 ingress,프로젝트 내부 제어면,직접 접근 허용,외부 직접 노출 비권장이 다르다. - 운영 실수는 숫자 자체보다 “이 포트가 누구 책임이고 어떤 경로에서 타야 하는가”가 문서에 안 고정될 때 생긴다.
2. 8100을 공용 API 게이트웨이처럼 보면 오판이 생긴다
- 현재
8100은 여러 프로젝트를 묶는 공용 게이트웨이가 아니라robeing전용 제어면에 가깝다. - 따라서
goosefarminvesting,starsandi,gitea,auth까지 한 줄로 같은 등급의 gateway 뒤에 있다고 보면 구조를 잘못 읽게 된다.
3. 포트 정리는 프로젝트별, 서버별, ingress별 3축으로 해야 한다
프로젝트별: 누가 쓰는가서버별: 51123/51124 중 어디에 있는가ingress별: nginx 경유인지, 서브도메인 direct proxy인지, 내부 전용인지- 이 세 축이 같이 있어야 “직접 포트 접근을 허용해도 되는지”, “gateway를 거쳐야 하는지”가 닫힌다.
Unresolved
8000,8100,8200,8505,9000,9200,9600의 외부 직접 접근을 계속 허용할지, UFW와 nginx 기준으로 더 줄일지는 이번 문서 범위에서 결정하지 않았다.admin-dashboard의/admin/api/ -> 8100구조를 계속 유지할지, 프로젝트 경계를 더 선명하게 분리할지는 별도 계획이 필요하다.