ivada-infra/DOCS
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
DOCS/journey/plans/260309_24서버_실서비스운영전환_계획.md

8.0 KiB
Raw Blame History

tags
tags
infra
24-server
robeing
production-transition
ssot
plans

260309 24서버 실서비스 운영전환 계획

상태: 완료 (2026-03-10 기준)

상위 원칙

관련 문서

문제 정의

  • 지금 상태는 23 서버가 임시 프로덕션 역할을 계속 수행하고 있고, 24 서버는 실행 자산만 존재하며 실제 서비스는 0개인 상태다.
  • 목표는 23=진입/제어/보조, 24=로빙 실행면 역할을 다시 맞추는 것이다.
  • 이번 작업의 닫힘 기준은 24 서버에서 실행계 서비스가 정상 기동하고, 23 서버는 인프라와 게이트웨이 역할만 유지하며, 이후 자동배포도 다시 24로 향하게 만드는 것이다.

범위 고정

1차 전환 대상

  • rb8001
  • robeing-monitor
  • skill-email
  • skill-calendar
  • skill-news
  • skill-slack
  • skill-rag-file
  • skill-embedding

23 서버에 유지할 대상

  • robeing-gateway
  • auth-server
  • postgresql
  • opensearch
  • data-prepper
  • gitea
  • 기타 23 제어면/운영면 자산

2차 검토 대상

  • skill-publish
  • 24 서버 프런트엔드 디렉터리 활용 여부

운영 결정 고정

  • skill-publish는 현재 /home/admin/robeing 실행 자산에 없으므로 1차 전환 범위에서 제외합니다.
  • robeing-monitor 외부 진입은 23 gateway -> 24 robeing-monitor 단일 경로로만 고정하고, 직접 포트 노출이나 병행 경로를 두지 않습니다.
  • robeing-gateway는 23 서버에 유지하되, 공용 env 참조는 /home/admin/workspace-config/runtime.env, /home/admin/workspace-config/secrets.env만 사용하게 고정합니다.
  • auth-server도 같은 23 제어면에 유지하고, gateway와 동일한 공용 env 기준을 사용합니다.

실행 순서

1. 배포 기준값을 먼저 24 기준으로 고정한다

  • 각 실행계 저장소의 .env.deploy를 192.168.0.106:51124 기준으로 바꾼다.
  • DEPLOY_PROJECT_DIR는 현재 24 실제 경로와 일치하게 유지한다.
    • skill-email
    • skill-news
    • 기타 실제 24 저장 경로
  • 하드코딩된 원격 경로가 남아 있는 워크플로우는 DEPLOY_PROJECT_DIR 기반으로 통일한다.
  • 이번 1차 전환 범위 밖인 skill-publish는 배포 기준 변경 대상에서 제외하고, active 실행 자산만 먼저 24 기준으로 전환한다.

2. 24 서버 런타임 SSOT를 먼저 정리한다

  • 24 서버에 /home/admin/workspace-config/runtime.env, /home/admin/workspace-config/secrets.env를 배치한다.
  • 24 서버 .env, docker-compose.yml, workflow에서 다음 잔존값을 제거한다.
    • 192.168.219.52
    • 192.168.219.45
    • /home/admin/ivada_project/...
  • 23 인프라를 바라보는 값은 현재 기준으로 통일한다.
    • DB: 192.168.0.100:5432
    • auth-server: 192.168.0.100:9000
    • gateway: 192.168.0.100:8100
    • OpenSearch: 192.168.0.100:9200
  • 24 내부 자기참조는 서비스 간 localhost 기준만 사용한다.
  • admin-dashboard의 24 대상 URL 목록도 192.168.0.106 기준으로 함께 교정한다.

3. 23 서버 인프라 의존 포트를 24 현재 IP 기준으로 다시 연다

  • 23 UFW 5432/tcp 허용 대상을 192.168.0.106 기준으로 교체한다.
  • 24에서 Neo4j가 필요하면 23의 7687을 192.168.0.106에서 접근 가능하게 바꾸고, Neo4j 리슨 주소도 localhost 전용 상태를 해제한다.
  • 기존 192.168.219.52, 192.168.219.0/24에 묶인 허용 규칙은 새 24 기준이 검증된 뒤 제거한다.

4. 서비스는 의존 순서대로 24에서 기동한다

  • 1순위: skill-embedding
    • ONNX 모델 마운트와 헬스체크 먼저 확인
  • 2순위: skill-rag-file
    • /mnt/51123data 문서 경로와 임베딩 연계를 확인
  • 3순위: skill-email, skill-calendar, skill-news, skill-slack
    • DB/auth 의존성이 있는 스킬군을 기동
  • 4순위: robeing-monitor
    • workspace-config와 DB 의존성 확인
  • 5순위: rb8001
    • 모든 하위 서비스와 23 인프라 연결이 열린 뒤 마지막 기동

5. 23 게이트웨이와 24 실행면 연결을 다시 검증한다

  • 23 게이트웨이 upstream이 24 rb8001, robeing-monitor를 정확히 바라보는지 확인한다.
  • robeing-monitor 외부 진입 경로는 gateway 경유 1개 경로만 남기고, 병행 경로가 있으면 제거한다.
  • 외부 실서비스 도메인에서 핵심 경로를 검증한다.
    • 메시지 핵심 경로
    • 이메일 경로
    • 일정 경로
    • 모니터/통계 경로
  • 24 로컬 헬스체크가 아니라, 23 게이트웨이를 거친 실서비스 경로 기준으로 최종 판정한다.

6. 24가 검증된 뒤 23 임시 실행 컨테이너를 해제한다

  • 24 동일 서비스가 모두 정상인 것을 확인한 뒤, 23의 실행계 컨테이너를 순차적으로 내린다.
  • 23에는 게이트웨이/인증/DB/OpenSearch 등 인프라성 컨테이너만 남긴다.
  • 이 단계 이전에는 23 실행계를 섣불리 내리지 않는다.

서비스별 체크리스트

공통

  • .env.deploy가 192.168.0.106:51124를 가리킨다.
  • 24 실제 DEPLOY_PROJECT_DIR와 일치한다.
  • .env, compose fallback, workflow에 192.168.219.45, 192.168.219.52, /home/admin/ivada_project가 없다.
  • docker compose down && docker compose up -d --build 후 헬스체크가 통과한다.

인프라 의존성

  • 24 -> 23 TCP 확인:
    • 5432
    • 7687 필요 시
    • 9000
    • 9200
    • 8100
  • 실패 시 서비스 재기동보다 먼저 네트워크/리스닝/UFW를 다시 맞춘다.

검증 기준

24 서버 내부

  • docker ps에 1차 전환 대상 컨테이너가 모두 Up으로 표시된다.
  • 각 서비스 헬스체크가 로컬에서 통과한다.
  • 24에서 23 인프라 포트가 모두 의도대로 연결된다.

실서비스 경로

  • 23 게이트웨이를 거친 핵심 API가 정상 응답한다.
  • 외부 도메인에서 메시지/이메일/일정/모니터 핵심 경로가 정상 동작한다.
  • 24 서비스 로그에서 구 IP 재접속, ivada_project 경로, DB 타임아웃, Neo4j 연결 실패가 재현되지 않는다.

완료 조건

  • 자동배포 기준이 다시 24 서버를 향한다.
  • 24 런타임 파일 기준 192.168.219.45, 192.168.219.52, /home/admin/ivada_project 실행 경로가 0건이다.
  • 24 1차 전환 대상 컨테이너가 모두 정상 기동한다.
  • 23 서버에는 임시 실행계 컨테이너가 남지 않고, 인프라/제어면 역할만 남는다.
  • 실서비스 도메인 기준 핵심 사용자 경로 검증 기록이 남는다.