DOCS/journey/plans/260309_24서버_실서비스운영전환_계획.md

tags

tags
infra 24-server robeing production-transition ssot plans

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

상위 원칙

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

관련 문서

• Infra Journey
• 24서버 실서비스 운영전환 리서치
• 260304 51123 임시복구 서비스 연속성 조치내역
• 260305 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결
• 24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록

문제 정의

• 지금 상태는 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 서버 프런트엔드 디렉터리 활용 여부

실행 순서

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

• 각 실행계 저장소의 .env.deploy를 192.168.0.106:51124 기준으로 바꾼다.
• DEPLOY_PROJECT_DIR는 24 실제 경로와 일치하게 맞춘다.
  • skill_email
  • skill_news
  • 기타 실제 24 저장 경로
• 하드코딩된 원격 경로가 남아 있는 워크플로우는 DEPLOY_PROJECT_DIR 기반으로 통일한다.
• 특히 skill-embedding, skill-publish의 ivada_project 경로 기반 워크플로우를 먼저 제거한다.

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

• 24 서버에 /home/admin/infra-config/runtime.env, /home/admin/infra-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 기준만 사용한다.

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
  • infra-config와 DB 의존성 확인
• 5순위: rb8001
  • 모든 하위 서비스와 23 인프라 연결이 열린 뒤 마지막 기동

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

• 23 게이트웨이 upstream이 24 rb8001, robeing-monitor를 정확히 바라보는지 확인한다.
• 외부 실서비스 도메인에서 핵심 경로를 검증한다.
  • 메시지 핵심 경로
  • 이메일 경로
  • 일정 경로
  • 모니터/통계 경로
• 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 서버에는 임시 실행계 컨테이너가 남지 않고, 인프라/제어면 역할만 남는다.
• 실서비스 도메인 기준 핵심 사용자 경로 검증 기록이 남는다.