ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
DOCS/journey/plans/260307_24서버_정상복구_초기서버_기준_계획.md

6.3 KiB
Raw Blame History

260307 24서버 정상복구 초기서버 기준 계획

작성일: 2026-03-07
상태: draft
전제: 51124는 현재 빈 초기 서버에 가깝고, 51123이 테스트 + 임시 운영 역할을 겸하고 있다.

1. 목표

  • 51124를 다시 robeing 프로덕션 실행 서버로 복구한다.
  • 51123의 임시 수용 상태를 종료하고, 원래 역할인 테스트 + 보조 + 인프라로 되돌린다.
  • 복구 후에도 IP/경로/시크릿 변경이 대량 수정으로 번지지 않도록 SSOT 구조를 함께 정착시킨다.

2. 복구 원칙

  1. 24는 처음부터 다시 쌓는다고 가정한다.
  • 과거 상태를 추측 복원하지 않는다.
  • 필요한 구성요소를 체크리스트로 다시 올린다.
  1. 서비스보다 기반을 먼저 복구한다.
  • OS/계정/권한/디렉터리/SSOT/네트워크가 먼저다.
  • 이 기반 없이 컨테이너만 올리면 재장애 가능성이 높다.
  1. 프로덕션 판정은 24에서만 확정한다.
  • 23에서 정상인 것은 사전 검증 근거일 뿐이다.
  • 최종 정상 판정은 24의 실제 헬스체크와 실경로 검증으로만 내린다.

3. 24 서버에 먼저 갖춰야 할 것

3.1 운영 기본 계층

  • 배포 사용자 계정 및 SSH 접근
  • Docker / Docker Compose
  • 기본 로그 경로
  • 시스템 시간대, 방화벽, 필수 패키지
  • 재부팅 후 자동 기동 정책(systemd 또는 compose 운영 규칙)

3.2 프로젝트 루트 구조

  • /home/admin/robeing
  • /home/admin/infra-config
  • 서비스별 배포 루트 경로
  • 로그/데이터/마운트 경로

3.3 설정 SSOT 계층

  • /home/admin/infra-config/runtime.env
  • /home/admin/infra-config/secrets.env
  • 서비스별 .env는 비워 두거나 로컬 오버라이드 전용으로 유지
  • IP/포트/내부 호스트/외부 연계 주소는 runtime.env 기준으로만 관리

3.4 네트워크/연계

  • 24 -> 23 DB 접근 확인
  • 24 -> NAS 또는 대체 스토리지 접근 확인
  • 23 gateway가 24 upstream으로 다시 붙을 수 있는지 확인
  • 헬스체크/내부 포트/UFW 정책 선반영

4. 복구 대상 서비스

4.1 우선 복구

  • rb8001
  • skill-email
  • skill-calendar
  • skill-news
  • skill-slack
  • skill-rag-file
  • skill-embedding
  • ChromaDB

4.2 조건부 복구

  • robeing-monitor
  • 기타 실험/보조 컨테이너

원칙:

  • 프로덕션 핵심 경로를 먼저 복구한다.
  • 모니터링/실험 서비스는 핵심 경로 안정화 후 붙인다.

5. 단계별 실행 계획

5.1 Phase 1: 바닥 공사

  • 24 서버 기본 패키지, Docker, 사용자 권한, SSH 키, 방화벽 구성
  • 프로젝트 루트 디렉터리 생성
  • infra-config 배치 및 권한 적용
  • Gitea Actions가 접근할 배포 경로 생성

완료 기준:

  • SSH 접속 가능
  • Docker 실행 가능
  • 배포 경로/권한 오류 없음

5.2 Phase 2: 설정 이식

  • 23 기준 운영값 중 24에 필요한 항목만 선별
  • runtime.env와 secrets.env에 반영
  • 하드코딩 IP/경로가 남아 있는 서비스는 이 단계에서 제거

완료 기준:

  • 각 서비스 compose가 24에서 동일한 SSOT 파일을 읽음
  • 서비스 내부 코드에 23 전용 하드코딩이 남아 있지 않음

5.3 Phase 3: 데이터/스토리지 연계

  • PostgreSQL 연결 확인
  • ChromaDB 볼륨 및 데이터 경로 확인
  • NAS 또는 공유 스토리지 마운트 확인
  • 로그 저장 경로 확인

완료 기준:

  • DB read/write 정상
  • 필요한 파일 마운트가 실제 경로에서 읽힘
  • 로그가 지정 경로에 기록됨

5.4 Phase 4: 서비스 기동

  • 핵심 서비스부터 docker compose down && docker compose up -d --build
  • 각 서비스별 헬스체크 확인
  • 컨테이너 포트/네트워크 실제 바인딩 확인

완료 기준:

  • docker ps 기준 핵심 컨테이너 running/healthy
  • 서비스별 health endpoint 응답 정상

5.5 Phase 5: 23과 연결 복구

  • 23 gateway upstream을 24 기준으로 재설정
  • auth / gateway / upstream 로그를 같은 요청 기준으로 대조
  • 실제 도메인 기준 요청 흐름 검증

완료 기준:

  • ro-being.com 실제 경로에서 핵심 API 응답 정상
  • gateway/nginx/upstream 로그가 한 요청 기준으로 이어짐

5.6 Phase 6: 역할 정상화

  • 24를 프로덕션으로 확정
  • 23의 임시 실행 컨테이너 정리
  • 23을 다시 테스트 + 보조 + 인프라 역할로 축소
  • 임시 예외 설정 제거 여부 확인

완료 기준:

  • 프로덕션 트래픽 기준 서버가 24로 고정됨
  • 23은 테스트/보험 역할만 수행

6. 검증 체크리스트

  1. 인프라
  • SSH, Docker, disk, memory, UFW 정상
  1. 데이터
  • 24에서 PostgreSQL 연결 정상
  • ChromaDB 경로/볼륨 정상
  • 공유 스토리지 접근 정상
  1. 서비스
  • rb8001 health 정상
  • 핵심 스킬 health 정상
  • monitor 필요 시 health 정상
  1. 요청 흐름
  • 실제 도메인에서 gateway -> upstream 응답 정상
  • 인증 경로 정상
  • 로그가 요청 단위로 추적 가능
  1. 운영
  • Actions 배포 성공
  • 재기동 후 자동 복구 가능
  • 23/24 역할 문서와 실제 구성이 일치

7. 실패 패턴 경계

  • 23의 임시값을 24 복구값으로 착각하는 것
  • .env, compose, 코드, 문서가 각각 다른 값을 갖는 것
  • 컨테이너만 살아 있고 실제 도메인 요청은 실패하는 상태를 정상으로 오판하는 것
  • 24 복구 전에 23 임시 설정을 정리해 버리는 것

8. 복구 완료 선언 조건

  • 24에서 핵심 서비스가 healthy
  • 실제 도메인 기준 핵심 경로 응답 정상
  • 23 gateway와 24 upstream 연결 정상
  • 문서, runtime.env/secrets.env, 배포 경로가 서로 일치
  • 23 임시운영 예외 항목이 후속 문서에 정리됨

9. 후속 문서 연결