ivada-infra/DOCS
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: finalize infra transition research and plans

Browse Source
This commit is contained in:
happybell80 2026-03-09 21:40:27 +09:00
parent 43aea8cdaf
commit 6781c5af6a
8 changed files with 246 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
journey/README.md
View File

@ -47,7 +47,9 @@
- [51123 구 IP 하드코딩 실행 경로와 런타임 SSOT 불일치 리서치](./research/260309_51123_구IP하드코딩_실행경로_SSOT불일치_리서치.md)
- [24서버 로빙 운영 자료 수집](./research/260309_24서버_로빙운영_자료수집.md)
- [24서버 실서비스 운영전환 리서치](./research/260309_24서버_실서비스운영전환_리서치.md)
- [23서버 워크스페이스 SSOT 구조전환 리서치](./research/260309_23서버_워크스페이스_SSOT_구조전환_리서치.md)
- [51123 구 IP 하드코딩 실행 경로 제거 계획](./plans/260309_51123_구IP하드코딩_실행경로제거_계획.md)
- [24서버 실서비스 운영전환 계획](./plans/260309_24서버_실서비스운영전환_계획.md)
- [23서버 워크스페이스 SSOT 구조전환 계획](./plans/260309_23서버_워크스페이스_SSOT_구조전환_계획.md)
- [24서버 ONNX 모델 NAS 백업 정리](./worklog/260309_24서버_onnx모델_nas백업_정리.md)
- [24서버 NAS 마운트 복원 및 ONNX 백업 실행](./worklog/260309_24서버_nas마운트복원_onnx백업실행.md)

77
journey/plans/260309_23서버_워크스페이스_SSOT_구조전환_계획.md Normal file
View File

@ -0,0 +1,77 @@
---
tags: [infra, workspace, ssot, structure, plans]
---
# 260309 23서버 워크스페이스 SSOT 구조전환 계획
## 상위 원칙
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
## 관련 문서
- [Infra Journey](../README.md)
- [23서버 워크스페이스 SSOT 구조전환 리서치](../research/260309_23서버_워크스페이스_SSOT_구조전환_리서치.md)
- [23서버 워크스페이스 인프라 구조정리 이슈](../troubleshooting/260307_23서버_워크스페이스_인프라_구조정리_이슈.md)
- [51123 구 IP 하드코딩 실행 경로 제거 계획](./260309_51123_구IP하드코딩_실행경로제거_계획.md)
- [24서버 실서비스 운영전환 계획](./260309_24서버_실서비스운영전환_계획.md)
## 문제 정의
- 현재 워크스페이스 해석 기준은 `WORKSPACE_ROOT=/home/admin`로 고정됐지만, 일부 실행 경로와 문서는 아직 `infra-config` 또는 삭제된 경로를 참조한다.
- 목표는 `23 제어면`, `24 실행면`, `workspace-config` 공용 env 구조를 실제 실행 경로까지 일치시키는 것이다.
- 이번 작업의 닫힘 기준은 `workspace-config` 단일화, 루트 중복 디렉터리 정리 유지, 삭제된 경로 참조 정리까지 포함한다.
## 구조 결정 고정
- `robeing-gateway`는 `auth-server`와 함께 23 서버 제어면에 유지한다.
- 제어면과 실행면을 가리지 않고 공용 운영값은 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`만 SSOT로 사용한다.
- 워크스페이스 정본 루트는 `TheGooseCouncil`만 남기고, 제거된 `thegoosecouncil`, `external_nas_test`, `tmp_lfs_branch_test`는 재도입하지 않는다.
## 실행 순서
### 1. 공용 env 참조를 `workspace-config`로 단일화한다
- `/home/admin/robeing-gateway/docker-compose.yml`의 `env_file`을 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`로 교체한다.
- `/home/admin/infra/scripts/README.md`의 공용 env 경로 설명도 같은 기준으로 교체한다.
- 실행 경로에서 `/home/admin/infra-config/*.env` 참조는 0건이 되게 만든다.
### 2. 23 제어면 서비스 기준을 명시적으로 고정한다
- `robeing-gateway`, `auth-server`가 모두 23 제어면 서비스라는 점을 관련 계획 문서와 리서치에서 같은 표현으로 유지한다.
- `24 전환` 계획에서도 gateway를 이전 대상이 아니라 연결 대상 제어면으로만 다루게 맞춘다.
### 3. 삭제된 루트 경로 참조를 현재 정본 경로로 교정한다
- `thegoosecouncil`를 직접 참조하는 하위 문서를 `TheGooseCouncil` 기준으로 교정한다.
- `external_nas_test`, `tmp_lfs_branch_test`를 전제하는 설명이 있으면 제거하거나 종료된 테스트 흔적으로 정리한다.
- `/home/admin/DOCS`처럼 현재 없는 루트 경로를 전제한 문서는 실제 경로 기준으로 수정 범위를 확정한다.
### 4. 실행 경로와 문서 경로를 함께 검증한다
- `rg` 기준 실행 경로에서 `infra-config/runtime.env`, `infra-config/secrets.env`가 0건인지 확인한다.
- `/home/admin` 최상위에 `TheGooseCouncil`만 남아 있는지 확인한다.
- 삭제된 경로를 참조하던 문서가 현재 정본 경로를 보도록 교정됐는지 확인한다.
## 체크리스트
- `robeing-gateway/docker-compose.yml`가 `workspace-config`만 참조한다.
- `infra/scripts/README.md`가 `workspace-config` 기준 설명만 남긴다.
- 실행 경로에서 `/home/admin/infra-config/*.env`가 0건이다.
- `/home/admin` 최상위에 `thegoosecouncil`, `external_nas_test`, `tmp_lfs_branch_test`가 없다.
- 삭제된 경로를 참조하는 문서는 현재 정본 경로 기준으로 정리된다.
## 검증 기준
- `docker compose config` 기준 `robeing-gateway`가 `workspace-config` 경로를 읽는다.
- `rg` 기준 비문서 실행 경로에서 `infra-config` 참조가 남지 않는다.
- `find /home/admin -maxdepth 1 -type d` 기준 중복/테스트 잔존 디렉터리가 재등장하지 않는다.
- 관련 문서에서 `TheGooseCouncil` 정본 경로와 `workspace-config` 용어가 일관되게 사용된다.
## 완료 조건
- 23 제어면 서비스의 공용 env 참조가 `workspace-config`로 단일화된다.
- 워크스페이스 루트 중복/테스트 디렉터리 정리가 문서와 실제 파일시스템 모두에서 일치한다.
- 삭제된 경로와 옛 SSOT 이름을 기준으로 하는 실행 경로가 0건이다.

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

@ -13,6 +13,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, plans]
## 관련 문서
- [Infra Journey](../README.md)
- [24서버 실서비스 운영전환 리서치](../research/260309_24서버_실서비스운영전환_리서치.md)
- [23서버 워크스페이스 SSOT 구조전환 계획](./260309_23서버_워크스페이스_SSOT_구조전환_계획.md)
- [260304 51123 임시복구 서비스 연속성 조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md)
- [260305 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](../troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)
- [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](../troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
@ -51,17 +52,24 @@ tags: [infra, 24-server, robeing, production-transition, ssot, plans]
- `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`
- `DEPLOY_PROJECT_DIR`는 현재 24 실제 경로와 일치하게 유지한다.
- `skill-email`
- `skill-news`
- 기타 실제 24 저장 경로
- 하드코딩된 원격 경로가 남아 있는 워크플로우는 `DEPLOY_PROJECT_DIR` 기반으로 통일한다.
- 특히 `skill-embedding`, `skill-publish`의 `ivada_project` 경로 기반 워크플로우를 먼저 제거한다.
- 이번 1차 전환 범위 밖인 `skill-publish`는 배포 기준 변경 대상에서 제외하고, active 실행 자산만 먼저 24 기준으로 전환한다.
### 2. 24 서버 런타임 SSOT를 먼저 정리한다
@ -76,6 +84,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, plans]
- 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 기준으로 다시 연다
@ -99,6 +108,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, plans]
### 5. 23 게이트웨이와 24 실행면 연결을 다시 검증한다
- 23 게이트웨이 upstream이 24 `rb8001`, `robeing-monitor`를 정확히 바라보는지 확인한다.
- `robeing-monitor` 외부 진입 경로는 gateway 경유 1개 경로만 남기고, 병행 경로가 있으면 제거한다.
- 외부 실서비스 도메인에서 핵심 경로를 검증한다.
- 메시지 핵심 경로
- 이메일 경로

21
journey/plans/260309_51123_구IP하드코딩_실행경로제거_계획.md
View File

@ -8,15 +8,16 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: `0_VALUE`의 `writing-principles.md`
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
## 관련 문서
- [Infra Journey](../README.md)
- [51123 구 IP 하드코딩과 런타임 SSOT 불일치 이슈](../troubleshooting/260309_51123_구IP하드코딩_런타임SSOT불일치_이슈.md)
- [51123 구 IP 하드코딩 실행 경로와 런타임 SSOT 불일치 리서치](../research/260309_51123_구IP하드코딩_실행경로_SSOT불일치_리서치.md)
- [23서버 워크스페이스 SSOT 구조전환 계획](./260309_23서버_워크스페이스_SSOT_구조전환_계획.md)
## 목표
- 51123 주소 기준을 `/home/admin/infra-config/runtime.env`의 `HOST_51123=192.168.0.100`으로 단일화한다.
- 51123 주소 기준을 `/home/admin/workspace-config/runtime.env`의 `HOST_51123=192.168.0.100`으로 단일화한다.
- active runtime에서 `192.168.219.45`를 실제로 사용하는 경로를 제거한다.
- 코드 기본값과 compose fallback에서 과거 IP를 제거해, 재빌드와 복구 시에도 구 IP가 다시 살아나지 않게 한다.
@ -32,10 +33,11 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
- `auth-server/app/providers/gmail_passport.py`
- `robeing/skill-calendar/services/google_calendar_service.py`
- `robeing/admin-dashboard/backend/services/system_service.py`
- `robeing-gateway/docker-compose.yml`
### 3. 잔존 복제본 또는 구 경로 정리 판단 대상
- `ivada_project/robeing-monitor/docker-compose.yml`
- `ivada_project/robeing-monitor/app/core/config.py`
### 3. 같은 작업 단위에서 함께 고정할 공용 env 경로
- `workspace-config`만 공용 SSOT로 사용한다.
- `/home/admin/infra-config/*.env` 참조는 실행 경로에서 허용하지 않는다.
## 실행 원칙
- 과거 IP `192.168.219.45`를 새 값과 병행 허용하지 않는다.
@ -64,12 +66,10 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
- 코드 기본값을 SSOT 기준으로 교체하거나, env 미주입 시 즉시 실패하도록 정리한다.
- `robeing/admin-dashboard/backend/services/system_service.py`
- 51124에서 51123으로 접근할 때 과거 IP 폴백을 제거하고 현재 기준값만 사용하게 정리한다.
- `robeing-gateway/docker-compose.yml`
- `env_file` 경로를 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`만 보게 교체한다.
### 3. 잔존 복제본 처리 방향 결정
- `ivada_project/robeing-monitor/*`가 현재 운영 경로가 아니면 실행 경로에서 제외됐다는 사실을 확인한다.
- 계속 보존할 필요가 없으면 구 IP literal 제거 또는 보관 경로 분리를 결정한다.
### 4. 재배포와 재검증
### 3. 재배포와 재검증
- 변경 서비스별로 `docker compose down && docker compose up -d --build`로 재기동한다.
- 컨테이너 env, TCP 연결, 헬스체크, 로그를 다시 확인한다.
- `192.168.219.45`로 향하는 연결 시도가 남지 않았는지 재검색한다.
@ -98,6 +98,7 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
## 완료 판단 기준
- active runtime 컨테이너 `skill-email`, `skill-calendar`, `data-prepper`가 더 이상 `192.168.219.45`를 사용하지 않는다.
- code default와 compose fallback에서 과거 IP literal이 제거된다.
- 실행 경로에서 `/home/admin/infra-config/*.env` 참조가 0건이고, 공용 env는 `workspace-config`만 사용한다.
- TCP 연결, 헬스체크, 로그 재검증에서 과거 IP timeout이 재현되지 않는다.
- 51123 주소 기준은 `192.168.0.100` 하나로만 설명 가능하다.

87
journey/research/260309_23서버_워크스페이스_SSOT_구조전환_리서치.md Normal file
View File

@ -0,0 +1,87 @@
---
tags: [infra, workspace, ssot, structure, research]
---
# 260309 23서버 워크스페이스 SSOT 구조전환 리서치
## 상위 원칙
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
## 관련 문서
- [Infra Journey](../README.md)
- [23서버 워크스페이스 인프라 구조정리 이슈](../troubleshooting/260307_23서버_워크스페이스_인프라_구조정리_이슈.md)
- [24서버 실서비스 운영전환 리서치](./260309_24서버_실서비스운영전환_리서치.md)
- [51123 구 IP 하드코딩 실행 경로와 런타임 SSOT 불일치 리서치](./260309_51123_구IP하드코딩_실행경로_SSOT불일치_리서치.md)
## 목적
- `WORKSPACE_ROOT=/home/admin`를 넣는 것만으로 구조 SSOT가 닫히는지 확인합니다.
- `infra-config -> workspace-config` 전환이 실제 실행 경로, 스크립트, 문서에서 어디까지 끝났는지 분리해서 봅니다.
- 워크스페이스 구조 문제를 `이름 변경 완료`가 아니라 `실행 경로 정합성 완료` 기준으로 다시 정의합니다.
## Facts
### 1. 공용 운영값 SSOT 경로는 이미 `workspace-config`로 바뀌었다
- `/home/admin/workspace-config/runtime.env`가 존재하고 `WORKSPACE_ROOT=/home/admin`를 포함한다.
- `/home/admin/workspace-config/secrets.env`가 존재한다.
- `/home/admin/infra-config` 경로는 현재 존재하지 않는다.
### 2. 일부 실행 경로는 이미 새 SSOT를 사용한다
- `/home/admin/robeing/robeing-monitor/docker-compose.yml`은 `env_file`로 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`를 사용한다.
- `/home/admin/infra/scripts/bin/companyx_external_nas_sync_probe.sh`도 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`를 읽는다.
- 따라서 `workspace-config`는 문서 용어가 아니라 실제 실행 경로에서 이미 사용 중이다.
### 3. 일부 실행 경로와 설명 문서는 아직 옛 SSOT 이름을 참조한다
- `/home/admin/robeing-gateway/docker-compose.yml`은 아직 `env_file`로 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`를 참조한다.
- `/home/admin/infra/scripts/README.md`도 비민감 운영값과 민감값 경로를 `/home/admin/infra-config/*.env`로 설명한다.
- 즉 `workspace-config` 전환은 일부 실행 자산에서 끝났지만, 전체 실행 경로 0건 상태는 아니다.
### 3-1. `robeing-gateway`의 역할과 SSOT 방향은 고정됐다
- `robeing-gateway`는 24 실행면으로 옮기지 않고, `auth-server`와 함께 23 서버 제어면에 유지한다.
- 따라서 공용 env 단일화의 기준은 `gateway를 옮길지`가 아니라, `23 제어면 서비스도 /home/admin/workspace-config/*.env만 읽게 맞출지`다.
- 이 결정으로 `robeing-gateway`는 워크스페이스 구조 SSOT의 예외가 아니라, 같은 SSOT를 따르는 23 제어면 서비스로 정리된다.
### 4. 상위 문서가 가정한 워크스페이스 구조와 현재 파일시스템은 아직 완전히 맞지 않는다
- `/home/admin/DOCS` 경로는 현재 존재하지 않는다.
- 그런데 일부 기존 문서와 기억된 구조 설명은 `/home/admin/DOCS`를 전제한다.
- 따라서 워크스페이스 구조 SSOT는 실제 디렉터리 기준으로 다시 정리돼야 한다.
### 5. 워크스페이스 루트의 중복/테스트 디렉터리 정리는 진행됐다
- 현재 `/home/admin` 최상위에는 `TheGooseCouncil`만 남아 있다.
- `thegoosecouncil`는 공통 하위 저장소 기준 원격에서 더 멀어진 복제본으로 판단돼 제거됐다.
- `external_nas_test`, `tmp_lfs_branch_test`는 각각 `Thumbs.db` 1건만 있던 테스트 잔존물과 빈 디렉터리로 확인돼 제거됐다.
## Interpretation
### 1. `WORKSPACE_ROOT` 고정은 구조 SSOT의 시작이지 완료가 아니다
- `WORKSPACE_ROOT=/home/admin`가 들어간 것은 해석 기준을 고정한 1단계다.
- 그러나 실행 경로가 아직 `workspace-config`와 `infra-config`를 함께 참조하면, 구조 SSOT는 닫히지 않는다.
### 2. 이 문제의 본질은 이름이 아니라 실행 경로의 단일화다
- `infra-config`라는 이름을 문서에서 `workspace-config`로 바꾸는 것만으로는 충분하지 않다.
- 실제 compose, 스크립트, 운영 README가 같은 경로를 보게 정리돼야 구조 SSOT가 완성된다.
### 3. 워크스페이스 구조 SSOT는 루트 디렉터리 정합성까지 포함해야 한다
- `/home/admin/DOCS`처럼 실제 없는 경로를 전제한 문서가 남아 있으면, 운영자가 구조를 잘못 해석할 수 있다.
- 중복 프로젝트 루트와 테스트 잔존 디렉터리는 정리됐지만, 이를 참조하는 하위 문서 경로까지 함께 교정돼야 구조 SSOT가 닫힌다.
## Unresolved
- `robeing-gateway/docker-compose.yml`와 `/home/admin/infra/scripts/README.md`를 언제 같은 작업 단위로 `workspace-config` 기준으로 교정할지 실행 시점만 남아 있다.
- 삭제된 `thegoosecouncil`, `external_nas_test`, `tmp_lfs_branch_test`를 참조하는 하위 문서를 어디까지 현재 경로로 교정할지 범위 결정이 아직 없다.
## 한 줄 결론
- 워크스페이스 구조 SSOT는 `WORKSPACE_ROOT` 고정, 루트 중복 제거, `gateway는 23 제어면 유지` 결정까지는 끝났고, 남은 일은 `workspace-config` 실행 반영과 하위 문서 경로 교정이다.

17
journey/research/260309_24서버_로빙운영_자료수집.md
View File

@ -63,18 +63,17 @@ tags: [infra, 24-server, robeing, operations, ssot, research]
- Compose 파일 확인 경로:
- `robeing/rb8001/docker-compose.yml`
- `robeing/robeing-monitor/docker-compose.yml`
- `robeing/skill_email/docker-compose.yml`
- `robeing/skill_news/docker-compose.yml`
- `robeing/skill-email/docker-compose.yml`
- `robeing/skill-news/docker-compose.yml`
- `robeing/skill-slack/docker-compose.yml`
- `robeing/skill-rag-file/docker-compose.yml`
- `robeing/skill-calendar/docker-compose.yml`
- `robeing/skill-embedding/docker-compose.yml`
- `robeing/skill-publish/docker-compose.yml`
- 자동배포 흔적 확인 경로:
- `robeing/rb8001/.gitea/`
- `robeing/robeing-monitor/.gitea/`
- `robeing/skill_email/.gitea/`
- `robeing/skill_news/.gitea/`
- `robeing/skill-email/.gitea/`
- `robeing/skill-news/.gitea/`
- `robeing/skill-slack/.gitea/`
- `robeing/skill-rag-file/.gitea/`
- `robeing/frontend-customer/.gitea/`
@ -84,8 +83,8 @@ tags: [infra, 24-server, robeing, operations, ssot, research]
- `robeing/rb8001/docker-compose.yml`: `http://localhost:8001/health`
- `robeing/robeing-monitor/docker-compose.yml`: `http://localhost:9024/healthz`
- `robeing/skill_email/docker-compose.yml`: `http://localhost:8501/health`
- `robeing/skill_news/docker-compose.yml`: `http://localhost:8505/health`
- `robeing/skill-email/docker-compose.yml`: `http://localhost:8501/health`
- `robeing/skill-news/docker-compose.yml`: `http://localhost:8505/health`
- `robeing/skill-calendar/docker-compose.yml`: `http://localhost:8512/health`
- `robeing/skill-embedding/docker-compose.yml`: `http://localhost:8515/healthz`
@ -93,7 +92,8 @@ tags: [infra, 24-server, robeing, operations, ssot, research]
- `robeing/AGENTS.md`는 아직 `192.168.219.52`, `192.168.219.45`, `/home/admin/ivada_project/...`를 기준으로 설명합니다.
- `robeing/DOCS/book/300_architecture/310_전체_시스템_구조_컨테이너와_마이크로서비스.md`와 `325_robeing_monitor_모니터링_아키텍처.md`도 과거 IP 기준 설명을 유지합니다.
- `/home/admin/workspace-config/runtime.env`는 현재 이 24 서버 워크스페이스에 존재하지 않았고, 당시에는 `secrets.env`만 먼저 생성된 상태였습니다.
- 현재 공용 운영값 파일은 `/home/admin/workspace-config/runtime.env`, 민감값 파일은 `/home/admin/workspace-config/secrets.env`로 24 서버에도 존재합니다.
- 다만 이 문서는 자료 위치를 모으는 문서일 뿐이고, 실제 차단 요인은 [24서버 실서비스 운영전환 리서치](./260309_24서버_실서비스운영전환_리서치.md)에서 따로 확정해야 합니다.
## Interpretation
@ -131,7 +131,6 @@ tags: [infra, 24-server, robeing, operations, ssot, research]
## Unresolved
- 24 서버 주소의 SSOT 파일이 `workspace-config` 기준으로 모두 채워졌는지는 이 문서 시점에 확정하지 못했습니다.
- `robeing/AGENTS.md`와 `robeing` 아키텍처 문서가 새 주소/경로 기준으로 갱신되지 않아, 현재는 참고 문서이되 최신 SSOT는 아닙니다.
- 자동배포 레포와 수동배포 레포 구분은 `robeing/AGENTS.md`에 있으나, 실제 `.gitea/workflows`와 완전히 일치하는지 서비스별 대조는 아직 하지 않았습니다.

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

@ -13,6 +13,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, research]
## 관련 문서
- [Infra Journey](../README.md)
- [24서버 로빙 운영 자료 수집](./260309_24서버_로빙운영_자료수집.md)
- [24서버 실서비스 운영전환 계획](../plans/260309_24서버_실서비스운영전환_계획.md)
- [260304 51123 임시복구 서비스 연속성 조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md)
- [260305 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](../troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)
- [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](../troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
@ -41,7 +42,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, research]
### 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/skill-publish`, `robeing/frontend-customer`, `robeing/frontend-ir-valuation`.
- 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 서버는 "코드가 없어서 못 띄우는 상태"가 아니라 "실행 전환이 아직 적용되지 않은 상태"다.
@ -54,38 +55,41 @@ tags: [infra, 24-server, robeing, production-transition, ssot, research]
- `260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md`도 `51124 복구 시 코드 수정 없이 각 레포 .env.deploy의 배포 대상 값만 24 서버 값으로 전환하면 된다`고 기록한다.
- 따라서 지금 자동배포가 24로 가지 않는 직접 이유 중 하나는 `.env.deploy`가 아직 23 기준이라는 점이다.
### 5. 24 서버의 실제 프로젝트 경로와 23 배포 기준 경로가 일부 다르다
### 5. 24 서버의 실제 프로젝트 경로와 23 배포 기준 경로가 현재는 일치한다
- 23 서버 소스 저장소는 `skill-email`, `skill-news` 디렉터리를 사용한다.
- 24 서버 실제 디렉터리는 `skill_email`, `skill_news`다.
- 그런데 24 서버에 있는 `skill_email/.env.deploy`, `skill_news/.env.deploy`도 각각 `DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-email`, `DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-news`로 적혀 있다.
- 즉 24 복귀 시 단순히 SSH 대상만 바꾸면 끝나는 것이 아니라, 배포 대상 디렉터리도 실제 24 경로와 맞춰야 한다.
- 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 서버 주소와 삭제된 경로가 남아 있다
### 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-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-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`
- `skill-embedding/docker-compose.yml`: ONNX 모델 마운트가 `/home/admin/ivada_project/onnx_models`
- 24 서버 `skill-embedding/.gitea/workflows/deploy.yml`: `/home/admin/ivada_project/skill-embedding`
- 24 서버 `skill-publish/.gitea/workflows/deploy.yml`: `/home/admin/ivada_project/skill-publish`
- `ivada_project`는 이미 운영 경로에서 제거된 상태이므로, 위 경로는 24 실서비스 전환에 그대로 사용하면 안 된다.
- `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` 기준 파일이 아직 완성되지 않았다
### 7. 24 서버의 `workspace-config` 기준 파일은 존재하지만, 전체 실행 경로가 아직 이를 따르지 않는다
- 24 서버에서 다음 경로 확인 결과:
- `MISSING:/home/admin/workspace-config/runtime.env`
- `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`를 함께 요구한다.
- 따라서 24 전환 전에는 `workspace-config/runtime.env`를 먼저 채워야 한다.
- 반면 `robeing-gateway/docker-compose.yml`은 아직 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`를 가리킨다.
- 따라서 `workspace-config` 파일 부재 이슈는 해소됐지만, 실행 경로 전체가 새 SSOT를 사용하도록 정리된 것은 아니다.
### 8. 24에서 23으로 향하는 의존 포트는 일부만 열려 있다
@ -104,25 +108,31 @@ tags: [infra, 24-server, robeing, production-transition, ssot, research]
- 24 서버에 `robeing/onnx_models`, `/mnt/51123data`, `/mnt/51123logs`가 존재한다.
- 따라서 `skill-rag-file`의 문서 경로와 `skill-embedding`의 모델 경로는 자산 자체가 없어서 막히는 상황은 아니다.
- 다만 `skill-embedding` compose가 실제 존재 경로가 아니라 삭제된 `ivada_project` 경로를 보고 있어, 구성값 교정이 필요하다.
### 10. 현재 리서치 문서 `24서버 로빙 운영 자료 수집`은 실행 전환 문제를 직접 닫는 문서가 아니다
### 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`, `24 missing workspace-config/runtime.env`, `23 UFW/Neo4j 미개방`, `24 경로 불일치`를 실행 순서로 고정하지는 않는다.
- 실제 차단 요인인 `23 대상 자동배포`, `24 런타임의 과거 IP`, `23 ingress/운영코드의 구 24 IP`, `23 UFW/Neo4j 미개방`, `workspace-config 비적용 경로`를 실행 순서로 고정하지는 않는다.
- 따라서 이번 문제를 닫는 기준 리서치는 별도로 필요하다.
## Interpretation
- 지금 풀고 있는 정확한 문제는 `24 서버를 켤 수 있느냐`가 아니라, `23 임시운영 중에 굳어진 배포/런타임/방화벽 기준을 24 프로덕션 구조로 다시 맞추는 것`이다.
- 현재 전환이 안 되는 이유는 단일 원인이 아니다. `배포 대상이 아직 23`, `24 런타임은 구 23 IP를 참조`, `24 workspace-config/runtime.env 부재`, `23 인프라 의존 포트가 새 24 IP에 열려 있지 않음`, `일부 워크플로우는 삭제된 ivada_project 경로를 사용`이 동시에 겹쳐 있다.
- 따라서 이번 계획 문서는 `24에 docker compose를 한 번 올리는 절차`가 아니라, `배포 SSOT -> 24 런타임 SSOT -> 23 인프라 허용 규칙 -> 서비스별 기동 순서 -> 23 임시 컨테이너 해제`를 한 묶음으로 다뤄야 한다.
- 현재 전환이 안 되는 이유는 단일 원인이 아니다. `배포 대상이 아직 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`를 이번 1차 전환 범위에 포함할지, 실행계 서비스 1차군(`rb8001`, `robeing-monitor`, `skill-email`, `skill-calendar`, `skill-news`, `skill-slack`, `skill-rag-file`, `skill-embedding`) 이후 2차군으로 둘지는 운영 우선순위 확인이 필요하다.
- 23 게이트웨이에서 24의 `rb8001`과 `robeing-monitor`로 향하는 upstream 최종값이 현재 어떤 파일에서 관리되는지 이번 리서치에서는 다시 열어보지 않았다. 다만 `260304` 문서상 원복 시 재점검 대상임은 확인된다.
- `skill-publish`와 `robeing-monitor` 외부 진입 계약은 [24서버 실서비스 운영전환 계획](../plans/260309_24서버_실서비스운영전환_계획.md)에서 각각 `1차 범위 제외`, `23 gateway 경유 단일 경로`로 넘겨졌다.
- 따라서 이 문서에 남은 미확정은 사실 부족보다 실행 검증 부족이며, 다음 단계는 결정 보강이 아니라 계획 실행 후 실경로 검증이다.
## 한 줄 결론
- 이번 문제는 `24 서버 복구`가 아니라 `23 임시 프로덕션을 끝내고 24 실서비스 운영 기준을 다시 세우는 전환`이며, 이를 막는 차단 요인은 이미 `배포 대상`, `런타임 구 IP`, `missing workspace-config/runtime.env`, `23 인프라 포트`, `ivada_project 잔존 경로`로 좁혀졌다.
- 이번 문제는 `24 서버 복구`가 아니라 `23 임시 프로덕션을 끝내고 24 실서비스 운영 기준을 다시 세우는 전환`이며, 이를 막는 차단 요인은 이미 `배포 대상`, `24 런타임 구 IP`, `23 ingress/운영코드의 구 24 IP`, `23 인프라 포트`, `workspace-config 미적용 실행 경로`로 좁혀졌다.

22
journey/research/260309_51123_구IP하드코딩_실행경로_SSOT불일치_리서치.md
View File

@ -8,7 +8,7 @@ tags: [infra, 51123, ip, ssot, runtime, research]
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: `0_VALUE`의 `writing-principles.md`
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
## 관련 문서
- [Infra Journey](../README.md)
@ -22,11 +22,11 @@ tags: [infra, 51123, ip, ssot, runtime, research]
- 2026-03-09 현재 23 서버 호스트는 `robeing-brains`다.
- `ip -brief addr` 기준 물리 NIC `enp6s0`의 IPv4는 `192.168.0.100/24`다.
- `ip route` 기준 기본 게이트웨이는 `192.168.0.1`이다.
- `infra-config/runtime.env`에는 다음 값이 기록돼 있다.
- `/home/admin/workspace-config/runtime.env`에는 다음 값이 기록돼 있다.
- `HOST_51123=192.168.0.100`
- `ROBEING_DEFAULT_HOST=192.168.0.100`
- `MONITOR_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`가 기록돼 있다.
- `/home/admin/workspace-config/secrets.env`에는 `ROBEING_MONITOR_DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`가 기록돼 있다.
### 2. 과거 IP `192.168.219.45`는 실행 경로에도 아직 남아 있다
- 문서를 제외하고 검색했을 때 과거 IP가 남은 주요 실행 경로는 다음과 같다.
@ -36,8 +36,6 @@ tags: [infra, 51123, ip, ssot, runtime, research]
- `robeing/skill-calendar/docker-compose.yml`
- `robeing/skill-calendar/services/google_calendar_service.py`
- `robeing/admin-dashboard/backend/services/system_service.py`
- `ivada_project/robeing-monitor/docker-compose.yml`
- `ivada_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를 실제로 사용하는 서비스가 있다
@ -87,7 +85,7 @@ tags: [infra, 51123, ip, ssot, runtime, research]
- `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 경로가 아니라 잔존 구 경로로 보인다.
- 과거 `ivada_project` 경로는 현재 워크스페이스에서 이미 제거돼, 이번 리서치 범위에서는 active 실행 경로 후보에서 제외한다.
### 6. active runtime의 주입 원천과 영향 범위를 구분할 수 있다
- `skill-email`
@ -102,6 +100,12 @@ tags: [infra, 51123, ip, ssot, runtime, research]
- 현재 active runtime 원천: `host.docker.internal:5432`
- 보조 잔존: `gmail_passport.py` code default
### 7. 공용 SSOT 이름은 바뀌었지만 일부 실행 경로는 아직 옛 경로를 참조한다
- `/home/admin/robeing-gateway/docker-compose.yml`은 아직 `env_file`로 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`를 사용한다.
- 현재 `/home/admin/infra-config`는 존재하지 않으므로, 이 compose는 지금 상태 그대로는 공용 SSOT를 읽을 수 없다.
- 다만 `robeing-gateway` 자체는 24로 옮기는 대상이 아니라 23 서버 제어면에 유지하는 것으로 방향이 고정됐다.
- 따라서 51123 구 IP 문제는 값 치환 문제이면서 동시에 `workspace-config` 단일화가 아직 끝나지 않은 구조 문제이기도 하다.
## Interpretation
### 1. 문제는 “문서 잔존”이 아니라 “실행 중 서비스가 과거 IP를 실제 사용 중”인 상태다
@ -109,7 +113,7 @@ tags: [infra, 51123, ip, ssot, runtime, research]
- 이 세 경로는 단순 잔존 문자열이 아니라, 실제 연결 시도와 실제 timeout 로그로 검증된 active 장애 경로다.
### 2. SSOT는 만들어졌지만 active runtime까지 치환되지 않았다
- `infra-config/runtime.env`와 `secrets.env`는 이미 `192.168.0.100`으로 정리돼 있다.
- `/home/admin/workspace-config/runtime.env`와 `secrets.env`는 이미 `192.168.0.100`으로 정리돼 있다.
- 반면 host network 기반 compose와 개별 코드 기본값은 예전 IP를 여전히 보존하고 있어, SSOT가 “문서/공용 env”까지만 적용되고 “실행 경로”까지 내려오지 못했다.
### 3. 직접 원인은 host network 서비스의 fallback 구조와 개별 기본값 분산이다
@ -128,8 +132,8 @@ tags: [infra, 51123, ip, ssot, runtime, research]
- 따라서 닫힘 조건은 `현재 주입 원천 제거 + fallback 제거 + 재검증`의 3단계여야 한다.
## Unresolved
- `admin-dashboard`의 23 서버 fallback 주소는 현재 비실행 상태이지만, 차후 24 서버에서 다시 배포될 때 SSOT를 어떤 방식으로 주입할지 결정되지 않았다.
- `ivada_project/robeing-monitor/*`가 완전히 폐기 대상인지, 비상 복구 경로로 남길지 운영 결정이 아직 없다.
- `robeing-gateway/docker-compose.yml`의 `workspace-config` 전환은 [51123 구 IP 하드코딩 실행 경로 제거 계획](../plans/260309_51123_구IP하드코딩_실행경로제거_계획.md)에 포함돼 더 이상 결정 미확정이 아니다.
- 현재 남은 미확정은 `admin-dashboard`를 24에서 다시 활성화할 때 SSOT를 어떤 env 경로로 주입할지의 구현 방식이며, 이 항목은 active runtime 문제보다 후순위다.
## 상위 원칙/근거 문서 연결
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)