DOCS/journey/research/260309_24서버_실서비스운영전환_리서치.md

tags

tags
infra 24-server robeing production-transition ssot research

260309 24서버 실서비스 운영전환 리서치

상위 원칙

• Infra Project Identity
• Core Infrastructure Principles
• Operational Guardrails
• 공통 작성 원칙: 0_VALUE Writing Principles

관련 문서

• Infra Journey
• 24서버 로빙 운영 자료 수집
• 24서버 실서비스 운영전환 계획
• 260304 51123 임시복구 서비스 연속성 조치내역
• 260305 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결
• 24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록
• 51123 DB 5432 차단사고 복구 및 의존 포트 점검

목적

• 지금 풀어야 하는 문제를 24 서버 자료 찾기가 아니라 23 임시 프로덕션을 24 실서비스 운영으로 다시 승격하는 문제로 정확히 고정합니다.
• 24 서버 전환을 막는 실제 차단 요인이 문서, 배포, 런타임, 네트워크 중 어디에 있는지 확인합니다.
• 이후 계획 문서가 구현 판단 없이 바로 실행될 수 있도록, 차단 요인을 사실 기준으로 좁힙니다.

Facts

1. 현재 운영 상태는 23 임시 프로덕션 / 24 실행 자산만 존재 상태다

• 2026-03-09 23 서버 docker ps 기준 실행 중 컨테이너는 rb8001, robeing_monitor, skill-email, skill-calendar, skill-embedding, skill-rag-file, skill-slack, robeing-skill-news, auth-server, opensearch, data-prepper, robeing-gateway다.
• 같은 시각 24 서버 docker ps 결과는 빈 목록이다.
• 24 서버 systemctl is-active docker nginx 결과는 docker=active, nginx=inactive다.
• 24 서버 ss -tlnp 결과 외부에서 확인되는 리슨 포트는 51124만 있다.

2. 이번 문제의 범위는 23의 인프라를 옮기는 것이 아니라 24의 실행면을 되살리는 것이다

• 260304_51123_임시복구_서비스연속성_조치내역.md는 23 단독 복구를 핵심 연속성 확보 기준의 임시 안정화로 규정한다.
• 같은 문서의 24 서버 인계 메모는 24 복구 후 우선순위를 rb8001/skill/chromadb 원복 배치 -> gateway upstream 재점검 -> 임시 성능 플래그 해제 여부 판단 순으로 적고 있다.
• robeing/DOCS/journey/plans/260303_23테스트보조_24프로덕션_운영전환_계획.md는 역할을 23=테스트+보조, 24=프로덕션으로 고정한다.

3. 24 서버에는 실행 자산이 이미 존재하고 Git 상태도 깨지지 않았다

• 24 서버에 다음 디렉터리가 존재한다: robeing/rb8001, robeing/robeing-monitor, robeing/skill-email, robeing/skill-news, robeing/skill-slack, robeing/skill-rag-file, robeing/skill-calendar, robeing/skill-embedding, robeing/frontend-customer, robeing/admin-dashboard, robeing/onnx_models.
• 24 서버 각 저장소의 git status --short --branch 결과는 모두 ## main...origin/main으로 깨끗하다.
• 즉 24 서버는 "코드가 없어서 못 띄우는 상태"가 아니라 "실행 전환이 아직 적용되지 않은 상태"다.

4. 현재 자동배포 기준값은 여전히 23 서버를 가리킨다

• 23 서버 저장소의 .env.deploy 값은 다음과 같이 남아 있다.
  • DEPLOY_SSH_HOST=192.168.219.45
  • DEPLOY_SSH_PORT=51123
• 확인 대상: rb8001, robeing-monitor, skill-email, skill-news, skill-slack, skill-rag-file, skill-calendar, skill-embedding-repo.
• 260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md도 51124 복구 시 코드 수정 없이 각 레포 .env.deploy의 배포 대상 값만 24 서버 값으로 전환하면 된다고 기록한다.
• 따라서 지금 자동배포가 24로 가지 않는 직접 이유 중 하나는 .env.deploy가 아직 23 기준이라는 점이다.

5. 24 서버의 실제 프로젝트 경로와 23 배포 기준 경로가 현재는 일치한다

• 23 서버 소스 저장소는 skill-email, skill-news 디렉터리를 사용한다.
• 24 서버 실제 디렉터리도 skill-email, skill-news다.
• 23 서버의 .env.deploy 역시 각각 DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-email, DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-news로 적혀 있다.
• 따라서 현재 배포 차단 요인은 경로 불일치가 아니라, DEPLOY_SSH_HOST=192.168.219.45, DEPLOY_SSH_PORT=51123처럼 배포 대상이 아직 23 기준이라는 점이다.

6. 24 서버 런타임 값에는 아직 과거 23 서버 주소가 남아 있다

• 24 서버 .env 확인 결과, 아래 서비스들이 아직 192.168.219.45를 직접 사용한다.
  • rb8001: DATABASE_URL, TEST_DATABASE_URL, METRICS_DATABASE_URL, POSTGRES_CONNECTION_STRING, GATEWAY_URL, AUTH_SERVER_URL
  • robeing-monitor: DATABASE_URL
  • skill-email: DATABASE_URL, POSTGRES_CONNECTION_STRING, TEST_DATABASE_URL
  • skill-news: DATABASE_URL, TEST_DATABASE_URL
  • skill-slack: DATABASE_URL
  • skill-rag-file: DATABASE_URL
  • skill-calendar: DATABASE_URL
• 24 서버 compose/workflow에도 과거값이 남아 있다.
  • skill-email/docker-compose.yml: AUTH_SERVER_URL fallback이 http://192.168.219.45:9000
  • skill-calendar/docker-compose.yml: DATABASE_URL fallback이 postgresql://...@192.168.219.45:5432/main_db
  • admin-dashboard/backend/services/system_service.py: rb8001, skill-email, skill-news, robeing-monitor, skill-publish URL이 http://192.168.219.52:*
  • admin-dashboard/backend/routers/system.py: RB8001_URL = "http://192.168.219.52:8001"
  • admin-dashboard/backend/admin_routes.py: RB8001_URL = "http://192.168.219.52:8001"
• 반면 현재 skill-embedding/docker-compose.yml의 ONNX 모델 경로는 /home/admin/robeing/onnx_models로 이미 교정돼 있다.
• 현재 /home/admin/robeing 아래에는 skill-publish 디렉터리나 배포 워크플로우가 존재하지 않으므로, admin-dashboard의 skill-publish 표기는 잔존 운영 목록으로 봐야 한다.

7. 24 서버의 workspace-config 기준 파일은 존재하지만, 전체 실행 경로가 아직 이를 따르지 않는다

• 24 서버에서 다음 경로 확인 결과:
  • EXISTS:/home/admin/workspace-config/runtime.env
  • EXISTS:/home/admin/workspace-config/secrets.env
• runtime.env에는 WORKSPACE_ROOT=/home/admin, HOST_51123=192.168.0.100, ROBEING_DEFAULT_HOST=192.168.0.100, MONITOR_URL=http://192.168.0.100:9024가 들어 있다.
• 그런데 robeing-monitor/docker-compose.yml은 env_file로 /home/admin/workspace-config/runtime.env, /home/admin/workspace-config/secrets.env, .env를 함께 요구한다.
• 반면 robeing-gateway/docker-compose.yml은 아직 /home/admin/infra-config/runtime.env, /home/admin/infra-config/secrets.env를 가리킨다.
• 따라서 workspace-config 파일 부재 이슈는 해소됐지만, 실행 경로 전체가 새 SSOT를 사용하도록 정리된 것은 아니다.

8. 24에서 23으로 향하는 의존 포트는 일부만 열려 있다

• 24 서버에서 23 서버 192.168.0.100으로 TCP 확인 결과:
  • 9000 ok
  • 9200 ok
  • 8100 ok
  • 5432 fail
  • 7687 fail
• 23 서버 현재 UFW 규칙은 5432/tcp를 192.168.219.52와 172.16.0.0/12에만 허용한다.
• 23 서버 현재 UFW 규칙은 7687을 192.168.219.0/24, 172.19.0.0/16, 172.17.0.0/16에만 허용한다.
• 23 서버 ss -tlnp 결과 5432는 0.0.0.0에 열려 있지만, 7687은 127.0.0.1에서만 리슨 중이다.
• 즉 24가 현재 IP 192.168.0.106로 돌아온 뒤에는, DB와 Neo4j 의존성에 대해 기존 허용 규칙이 더 이상 맞지 않는다.

9. 24 서버의 저장 자산과 SSHFS 마운트는 존재한다

• 24 서버에 robeing/onnx_models, /mnt/51123data, /mnt/51123logs가 존재한다.
• 따라서 skill-rag-file의 문서 경로와 skill-embedding의 모델 경로는 자산 자체가 없어서 막히는 상황은 아니다.

10. 23 서버의 ingress와 운영 보조 코드에도 과거 24 서버 주소가 남아 있다

• /etc/nginx/sites-enabled/default의 /rb8001/ upstream은 proxy_pass http://192.168.219.52:8001/;다.
• /home/admin/nginx-infra/server-nginx-default도 같은 upstream을 192.168.219.52:8001로 유지한다.
• admin-dashboard/backend/services/system_service.py, routers/system.py, admin_routes.py도 모두 192.168.219.52 기준 URL을 사용한다.
• 따라서 24 서버 실행계를 올리기 전에, 23 서버 ingress와 운영 보조 코드도 새 24 IP 192.168.0.106 기준으로 함께 교정돼야 한다.

11. 현재 리서치 문서 24서버 로빙 운영 자료 수집은 실행 전환 문제를 직접 닫는 문서가 아니다

• 해당 문서는 문서/자산/참고 순서를 모은 자료 수집 문서다.
• 실제 차단 요인인 23 대상 자동배포, 24 런타임의 과거 IP, 23 ingress/운영코드의 구 24 IP, 23 UFW/Neo4j 미개방, workspace-config 비적용 경로를 실행 순서로 고정하지는 않는다.
• 따라서 이번 문제를 닫는 기준 리서치는 별도로 필요하다.

Interpretation

• 지금 풀고 있는 정확한 문제는 24 서버를 켤 수 있느냐가 아니라, 23 임시운영 중에 굳어진 배포/런타임/방화벽 기준을 24 프로덕션 구조로 다시 맞추는 것이다.
• 현재 전환이 안 되는 이유는 단일 원인이 아니다. 배포 대상이 아직 23, 24 런타임은 구 23 IP를 참조, 23 ingress와 운영 보조 코드가 구 24 IP를 참조, 23 인프라 의존 포트가 새 24 IP에 열려 있지 않음, 일부 실행 경로는 아직 workspace-config를 쓰지 않음이 동시에 겹쳐 있다.
• 따라서 이번 계획 문서는 24에 docker compose를 한 번 올리는 절차가 아니라, 배포 SSOT -> 24 런타임 SSOT -> 23 ingress/운영코드 교정 -> 23 인프라 허용 규칙 -> 서비스별 기동 순서 -> 23 임시 컨테이너 해제를 한 묶음으로 다뤄야 한다.

Unresolved

• skill-publish와 robeing-monitor 외부 진입 계약은 24서버 실서비스 운영전환 계획에서 각각 1차 범위 제외, 23 gateway 경유 단일 경로로 넘겨졌다.
• 따라서 이 문서에 남은 미확정은 사실 부족보다 실행 검증 부족이며, 다음 단계는 결정 보강이 아니라 계획 실행 후 실경로 검증이다.

한 줄 결론

• 이번 문제는 24 서버 복구가 아니라 23 임시 프로덕션을 끝내고 24 실서비스 운영 기준을 다시 세우는 전환이며, 이를 막는 차단 요인은 이미 배포 대상, 24 런타임 구 IP, 23 ingress/운영코드의 구 24 IP, 23 인프라 포트, workspace-config 미적용 실행 경로로 좁혀졌다.