9.3 KiB
9.3 KiB
tags
| tags | ||||||
|---|---|---|---|---|---|---|
|
51123 구 IP 하드코딩 실행 경로와 런타임 SSOT 불일치 리서치
상위 원칙
- Infra Project Identity
- Core Infrastructure Principles
- Operational Guardrails
- 공통 작성 원칙:
0_VALUE의writing-principles.md
관련 문서
- Infra Journey
- 51123 구 IP 하드코딩과 런타임 SSOT 불일치 이슈
- 24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록
- 51123 구 IP 하드코딩 실행 경로 제거 계획
Facts
1. 현재 51123의 실주소와 SSOT는 192.168.0.100이다
- 2026-03-09 현재 23 서버 호스트는
robeing-brains다. ip -brief addr기준 물리 NICenp6s0의 IPv4는192.168.0.100/24다.ip route기준 기본 게이트웨이는192.168.0.1이다.infra-config/runtime.env에는 다음 값이 기록돼 있다.HOST_51123=192.168.0.100ROBEING_DEFAULT_HOST=192.168.0.100MONITOR_URL=http://192.168.0.100:9024
infra-config/secrets.env에는ROBEING_MONITOR_DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db가 기록돼 있다.
2. 과거 IP 192.168.219.45는 실행 경로에도 아직 남아 있다
- 문서를 제외하고 검색했을 때 과거 IP가 남은 주요 실행 경로는 다음과 같다.
auth-server/app/providers/gmail_passport.pyfluent-bit/data-prepper/pipelines.yamlrobeing/skill-email/docker-compose.ymlrobeing/skill-calendar/docker-compose.ymlrobeing/skill-calendar/services/google_calendar_service.pyrobeing/admin-dashboard/backend/services/system_service.pyivada_project/robeing-monitor/docker-compose.ymlivada_project/robeing-monitor/app/core/config.py
- 이 중
frontend-* vite.config.ts,rb8001/.env.deploy.example,skill-rag-file/scripts/test_db_page_count.py같은 파일은 현재 서버 런타임보다 개발/예시/테스트 성격이 강하다.
3. 현재 active runtime에서 과거 IP를 실제로 사용하는 서비스가 있다
docker ps기준 23 서버에서 동작 중인 관련 컨테이너는auth-server,skill-email,skill-calendar,robeing_monitor,data-prepper,opensearch다.- 컨테이너 env 확인 결과:
auth-serverDATABASE_URL=postgresql://robeings:robeings@host.docker.internal:5432/main_db
skill-emailAUTH_SERVER_URL=http://192.168.219.45:9000DATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_db
skill-calendarDATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_db
robeing_monitorHOST_51123=192.168.0.100DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_dbMONITOR_URL=http://192.168.0.100:9024
data-prepper는 env가 아니라pipelines.yaml의 sink host를 사용하며, 현재 설정값이http://192.168.219.45:9200다.
3-1. skill-email, skill-calendar의 주입 원천은 .env로 확정됐다
/home/admin/robeing/skill-email/.env에는 아래 값이 직접 기록돼 있다.AUTH_SERVER_URL=http://192.168.219.45:9000DATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_dbPOSTGRES_CONNECTION_STRING=postgresql://robeings:robeings@192.168.219.45:5432/main_db
/home/admin/robeing/skill-calendar/.env에는 아래 값이 직접 기록돼 있다.DATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_db
docker compose ... config확인 결과, 두 서비스 모두.env값이 최종 environment로 해석돼 컨테이너에 주입된다.- 따라서
skill-email,skill-calendar의 현재 과거 IP 사용 원천은 "미확정 fallback"이 아니라.env의 직접 주입으로 확정된다.
4. active runtime의 과거 IP 경로는 실제로 timeout을 낸다
- 23 서버 호스트에서 TCP 확인 결과:
192.168.219.45:9000->tcp_fail timed out192.168.0.100:9000->tcp_ok192.168.219.45:5432->tcp_fail timed out192.168.0.100:5432->tcp_ok192.168.219.45:9200->tcp_fail timed out192.168.0.100:9200->tcp_ok
skill-email컨테이너 내부에서 TCP 확인 결과:192.168.219.45:9000->tcp_fail timed out192.168.0.100:9000->tcp_ok
skill-calendar컨테이너 내부에서 TCP 확인 결과:192.168.219.45:5432->tcp_fail timed out192.168.0.100:5432->tcp_ok
data-prepper로그에는 아래 패턴이 반복 기록된다.Failed to initialize OpenSearch sink, retrying: Timeout connecting to [/192.168.219.45:9200]
5. active runtime 후보이지만 현재 직접 장애 경로로 확인되지 않은 항목도 있다
auth-server는 compose fallback에host.docker.internal:5432를 사용하고 있고, 현재 컨테이너 env도 그 값으로 주입돼 있다.- 따라서
auth-server/app/providers/gmail_passport.py의192.168.219.45기본값은 코드 fallback 잔존이지만, 현재 컨테이너에서는 그 경로가 직접 사용 중이라고 확인되지는 않았다. - 24 서버의
admin-dashboard코드에는 23 서버 fallback 구조가 존재하지만, 2026-03-09 현재 24 서버docker ps는 빈 상태였고 해당 컨테이너는 active runtime으로 확인되지 않았다. ivada_project/robeing-monitor/*는 현재 실행 중인robeing_monitor컨테이너의 compose 경로가 아니라 잔존 구 경로로 보인다.
6. active runtime의 주입 원천과 영향 범위를 구분할 수 있다
skill-email- 현재 원천:
/home/admin/robeing/skill-email/.env - 보조 잔존:
docker-compose.ymlfallback
- 현재 원천:
skill-calendar- 현재 원천:
/home/admin/robeing/skill-calendar/.env - 보조 잔존:
docker-compose.ymlfallback,services/google_calendar_service.pycode default
- 현재 원천:
data-prepper- 현재 원천:
/home/admin/fluent-bit/data-prepper/pipelines.yaml
- 현재 원천:
auth-server- 현재 active runtime 원천:
host.docker.internal:5432 - 보조 잔존:
gmail_passport.pycode default
- 현재 active runtime 원천:
Interpretation
1. 문제는 “문서 잔존”이 아니라 “실행 중 서비스가 과거 IP를 실제 사용 중”인 상태다
skill-email,skill-calendar,data-prepper는 현재도 과거 IP192.168.219.45를 런타임 값으로 사용한다.- 이 세 경로는 단순 잔존 문자열이 아니라, 실제 연결 시도와 실제 timeout 로그로 검증된 active 장애 경로다.
2. SSOT는 만들어졌지만 active runtime까지 치환되지 않았다
infra-config/runtime.env와secrets.env는 이미192.168.0.100으로 정리돼 있다.- 반면 host network 기반 compose와 개별 코드 기본값은 예전 IP를 여전히 보존하고 있어, SSOT가 “문서/공용 env”까지만 적용되고 “실행 경로”까지 내려오지 못했다.
3. 직접 원인은 host network 서비스의 fallback 구조와 개별 기본값 분산이다
skill-email,skill-calendar,data-prepper는 모두network_mode: host또는 host 직접 접근 전제를 사용한다.- 이 구조에서 서비스 discovery 대신 서버 IP literal을 직접 박았고, 성수 이전 후 새 SSOT로 교체되지 않았다.
- 따라서 문제의 직접 원인은 “과거 IP를 fallback으로 둔 compose/env/config가 active runtime에 남아 있는 것”이다.
4. 근본 원인은 인프라 기준값이 코드/compose/config마다 분산된 구조다
- 같은 51123 주소가
runtime.env, compose fallback, 코드 default, 구 디렉터리 복제본에서 각각 관리됐다. - 이 구조에서는 SSOT가 생겨도 기존 fallback을 제거하지 않으면 재배포, 개별 실행, 신규 컨테이너 생성 시 과거 값이 다시 살아난다.
- 즉 이번 이슈는 값 하나의 오타가 아니라 “주소 기준값의 관리 경로가 여러 개”인 구조 문제다.
5. 트러블슈팅 문서를 닫으려면 active runtime 0건과 fallback 0건을 함께 달성해야 한다
- active runtime만 고쳐도 코드 fallback이 남아 있으면 다음 재빌드 때 재발할 수 있다.
- 반대로 코드만 고치고 현재 돌고 있는 컨테이너 env와 pipeline이 그대로면 실제 장애는 즉시 남는다.
- 따라서 닫힘 조건은
현재 주입 원천 제거 + fallback 제거 + 재검증의 3단계여야 한다.
Unresolved
admin-dashboard의 23 서버 fallback 주소는 현재 비실행 상태이지만, 차후 24 서버에서 다시 배포될 때 SSOT를 어떤 방식으로 주입할지 결정되지 않았다.ivada_project/robeing-monitor/*가 완전히 폐기 대상인지, 비상 복구 경로로 남길지 운영 결정이 아직 없다.