docs: add evidence for 24 deploy ssot mismatch

This commit is contained in:
Claude 2026-03-11 19:10:56 +09:00
parent 1ad0a2c5ad
commit 2f1f9aec09
3 changed files with 23 additions and 14 deletions

View File

@ -15,10 +15,12 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
## 결정
- 이번 문제는 `rb8001` 코드가 아니라 `배포 인프라 경로` 문제로 다룬다.
- 따라서 수정 우선순위는 `workflow -> secret/variable -> SSH 검증 -> task 로그` 순서다.
- 따라서 수정 우선순위는 `workflow가 읽는 .env.deploy 복구 -> 구주소 예시 제거 -> 필요 시 secret/variable -> SSH 검증 -> task 로그` 순서다.
## 범위
- 포함:
- `rb8001/.env.deploy` 실파일 복구 또는 대체 주입 경로 확정
- `.env.deploy.example`의 구주소/구포트 제거
- 24 배포 대상 host/port/path SSOT 확인
- Gitea Actions secret/variable 교정
- `cicd.yml` 하드코딩 경로 제거 또는 SSOT 기준 교정
@ -29,10 +31,11 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
## 실행 단계
1. `rb8001/.gitea/workflows/cicd.yml`의 deploy host/port/path 참조를 확인한다.
2. Gitea의 `SSH_HOST_51124`, 포트, 배포 경로 관련 secret/variable이 `192.168.0.106` 기준과 일치하는지 확인한다.
3. 23 제어면에서 같은 값으로 24 실행면 SSH 접속이 실제 되는지 검증한다.
4. 하드코딩 값이 있으면 제거하고 `DEPLOY_PROJECT_DIR` 또는 단일 기준 변수로 맞춘다.
5. 테스트 커밋 또는 재실행으로 Actions task가 실제 실행되고, 24 서버 컨테이너가 재시작되는지 검증한다.
2. `rb8001/.env.deploy`를 다른 서비스와 같은 형식으로 복구하고 `192.168.0.106:51124` 기준으로 맞춘다.
3. `.env.deploy.example`의 구주소 `192.168.219.45:51123`를 제거한다.
4. 필요 시 Gitea Actions secret/variable 기반으로 전환하되, 값 기준은 여전히 `192.168.0.106`, `51124`, 실제 배포 경로로 고정한다.
5. 23 제어면에서 같은 값으로 24 실행면 SSH 접속이 실제 되는지 검증한다.
6. 테스트 커밋 또는 재실행으로 Actions task가 실제 실행되고, 24 서버 컨테이너가 재시작되는지 검증한다.
## 완료 기준
- `cicd.yml` task가 `0s` 종료가 아니라 실제 실행 로그를 남긴다.

View File

@ -20,21 +20,22 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
- 배포 경로 기준: 서비스별 하드코딩이 아니라 workflow 변수/secret의 단일 기준 사용
## 이번 문제에 가장 가까운 원인 후보
1. `SSH_HOST_51124` 또는 대응 secret/variable이 아직 구 IP를 가리킨다.
2. SSH 포트가 현재 실제 접속 규칙과 어긋난다.
3. workflow가 `DEPLOY_PROJECT_DIR` 대신 오래된 절대경로를 사용한다.
4. runner는 뜨지만 실제 task가 시작 조건을 못 맞춰 즉시 종료된다.
1. `rb8001` 저장소에 `.env.deploy` 실파일이 없어 workflow가 시작 직후 필수 파일 검증에서 실패한다.
2. `.env.deploy.example`가 아직 `192.168.219.45:51123`를 가리켜 복원하더라도 잘못된 값을 주입할 위험이 있다.
3. repo-level Actions secrets/variables가 비어 있어, 현재 workflow를 대체할 다른 배포값 주입 경로도 없다.
4. workflow가 `DEPLOY_PROJECT_DIR` 대신 오래된 절대경로를 사용한다.
## 이번 이슈에서 중요한 해석
- 수동 배포가 같은 서버에서 정상 성공했기 때문에 `rb8001` 코드, Dockerfile, compose 자체가 주원인일 가능성은 낮다.
- 따라서 우선순위는 `workflow 정의`, `Actions secret/variable`, `23 -> 24 SSH 대상값` 검증이다.
- 따라서 우선순위는 `workflow가 읽는 실제 배포값 파일(.env.deploy)`, `예시 파일의 구주소`, `보완용 secret/variable 부재` 확인이다.
- 기존 인프라 문서와도 일치하게, 이런 배포 실패는 대개 애플리케이션보다 `경로/권한/런타임 값`의 단일 기준 붕괴에서 발생한다.
## 닫힘에 필요한 최소 확인
- `cicd.yml`의 실제 deploy host/port/path 참조값
- Gitea Actions secret/variable의 현재값이 24 SSOT와 일치하는지
- 23 제어면에서 24 실행면으로 SSH가 실제 성공하는지
- `rb8001/.env.deploy` 실파일 존재 여부
- `.env.deploy.example`의 구주소 제거 여부
- Gitea Actions secret/variable 부재를 유지할지, 변수 기반으로 바꿀지 결정
- task가 왜 `0s`로 끝났는지 runner/task 로그 확인
## 결론
- 현재 가장 강한 가설은 `24 runtime SSOT는 192.168.0.106으로 정리됐지만, 자동 배포 경로 일부는 아직 그 기준으로 완전히 수렴하지 않았다`는 것이다.
- 현재는 가설 수준을 넘어서, `rb8001` 자동 배포 경로가 `.env.deploy` 부재와 구주소 예시 파일 때문에 실제 SSOT에 수렴하지 않았음`이 실증된 상태다.

View File

@ -19,10 +19,15 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
- 24 실행면의 공용 런타임 값은 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`가 SSOT다.
- 기존 인프라 문서상 배포 실패의 대표 원인은 `DEPLOY_PROJECT_DIR` 같은 단일 기준을 안 쓰고 서비스별 하드코딩 경로/값을 남긴 경우였다.
- 이번 건은 자동 배포가 실행되지 않았지만, 같은 서버에서 수동 배포는 정상 성공했다.
- `rb8001/.gitea/workflows/cicd.yml``secrets.*``vars.*`가 아니라 저장소 루트 `.env.deploy`를 직접 읽도록 작성돼 있다.
- 현재 `rb8001` 저장소에는 `.env.deploy`가 없고 `.env.deploy.example`만 존재한다.
- `rb8001/.env.deploy.example`에는 아직 `DEPLOY_SSH_HOST=192.168.219.45`, `DEPLOY_SSH_PORT=51123`가 남아 있다.
- 반면 `skill_email`, `robeing-monitor`, `skill-rag-file`의 실제 `.env.deploy`는 모두 `DEPLOY_SSH_HOST=192.168.0.106`, `DEPLOY_SSH_PORT=51124`로 맞춰져 있다.
- Gitea API 기준 `rb8001` 저장소의 Actions secrets/variables 목록은 현재 빈 배열(`[]`)이다.
## 현재 해석
- 애플리케이션 코드 자체 문제보다는 `Gitea Actions -> 24 배포 경로`의 SSOT 불일치 가능성이 높다.
- 특히 `workflow secret/host/port/path` 중 하나 이상이 현재 24 runtime SSOT(`192.168.0.106`, 올바른 SSH 포트, 실제 배포 경로)와 어긋났을 가능성이 크다.
- 특히 `rb8001`은 다른 서비스와 달리 `.env.deploy` 실파일이 없고, 예시 파일도 구주소를 가리켜 자동 배포 경로가 SSOT에 수렴하지 않은 상태다.
## 직접 영향
- `git push origin main`이 배포 완료를 의미하지 않게 된다.