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

View File

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