DOCS/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md

tags

tags
infra gitea-actions deploy 24-server runtime research

24 자동배포 0초 종료와 runtime SSOT 불일치 리서치

관련 문서

• 24 자동배포 0초 종료와 runtime SSOT 불일치 이슈
• 24서버 robeing runtime workspace-config 단일화
• 24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록
• 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결

목적

• 이번 자동 배포 0s 종료를 애플리케이션 문제가 아니라 인프라 배포 경로 SSOT 불일치 관점에서 닫기 위한 확인 포인트를 정리한다.

확인된 SSOT

• 24 실행 서버 기준 주소: 192.168.0.106
• 과거 24 주소: 192.168.219.52 사용 금지
• 24 실행면 공통 런타임 값 기준: /home/admin/workspace-config/runtime.env, /home/admin/workspace-config/secrets.env
• 배포 경로 기준: 서비스별 하드코딩이 아니라 workflow 변수/secret의 단일 기준 사용

이번 문제에 가장 가까운 원인 후보

1. SSH_HOST_51124 또는 대응 secret/variable이 아직 구 IP를 가리킨다.
2. SSH 포트가 현재 실제 접속 규칙과 어긋난다.
3. workflow가 DEPLOY_PROJECT_DIR 대신 오래된 절대경로를 사용한다.
4. runner는 뜨지만 실제 task가 시작 조건을 못 맞춰 즉시 종료된다.

이번 이슈에서 중요한 해석

• 수동 배포가 같은 서버에서 정상 성공했기 때문에 rb8001 코드, Dockerfile, compose 자체가 주원인일 가능성은 낮다.
• 따라서 우선순위는 workflow 정의, Actions secret/variable, 23 -> 24 SSH 대상값 검증이다.
• 기존 인프라 문서와도 일치하게, 이런 배포 실패는 대개 애플리케이션보다 경로/권한/런타임 값의 단일 기준 붕괴에서 발생한다.

닫힘에 필요한 최소 확인

• cicd.yml의 실제 deploy host/port/path 참조값
• Gitea Actions secret/variable의 현재값이 24 SSOT와 일치하는지
• 23 제어면에서 24 실행면으로 SSH가 실제 성공하는지
• task가 왜 0s로 끝났는지 runner/task 로그 확인

결론

• 현재 가장 강한 가설은 24 runtime SSOT는 192.168.0.106으로 정리됐지만, 자동 배포 경로 일부는 아직 그 기준으로 완전히 수렴하지 않았다는 것이다.