DOCS/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md

tags

tags
infra gitea-actions deploy 24-server runtime troubleshooting

24 자동배포 0초 종료와 runtime SSOT 불일치 이슈

관련 문서

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

문제

• rb8001 최신 커밋 푸시 후 Gitea Actions cicd.yml이 0s로 종료되고 자동 배포가 실제로 수행되지 않았다.
• 같은 시점에 24 실행 서버 rb8001 컨테이너는 재시작되지 않았고, 수동 docker compose down && docker compose up -d --build 후에만 코드가 반영됐다.
• 2026-03-11 c7bca94 fix: restore deploy ssot for rb8001 반영 뒤에도 최신 run #677은 여전히 0s로 끝나 workflow 본문 실행 증거가 없다.

확인된 사실

• 현재 24 실행 서버의 runtime SSOT는 192.168.0.106이다.
• 과거 24 주소 192.168.219.52는 런타임과 영구 설정 모두에서 제거돼야 하는 대상으로 이미 정리돼 있다.
• 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를 직접 읽도록 작성돼 있다.
• 2026-03-11 git -C /home/admin/robeing/rb8001 pull 결과 0313313..c7bca94로 갱신됐고, 현재 저장소에는 .env.deploy 실파일이 존재한다.
• 현재 rb8001/.env.deploy, .env.deploy.example 모두 DEPLOY_SSH_HOST=192.168.0.106, DEPLOY_SSH_PORT=51124, DEPLOY_PROJECT_DIR=/home/admin/robeing/rb8001로 정렬돼 있다.
• 반면 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 목록은 현재 빈 배열([])이다.
• 2026-03-11 51123 서버에서 ps -ef | rg 'act_runner|start-act-runner' 기준 실행 중인 runner 프로세스가 없었다.
• 2026-03-11 51123 서버에서 systemctl is-active act_runner는 inactive, systemctl status act_runner는 Unit act_runner.service could not be found.를 반환했다.
• /home/admin/scripts/start-act-runner.sh는 systemd 유닛이 아니라 cd /etc/act_runner && nohup act_runner daemon --config .runner > /mnt/hdd/logs/act_runner/act_runner.log 2>&1 & 방식으로 runner를 띄우도록 작성돼 있다.
• /etc/act_runner/.runner에는 runner id 4, name org-shared-runner, address http://localhost:3000, label self-hosted:host가 등록돼 있다.
• /mnt/hdd/logs/act_runner/act_runner.log의 마지막 성공 실행 흔적은 2026-03-05 robeing-monitor 배포이고, 마지막 오류는 2026-03-06 failed to fetch task ... dial tcp 127.0.0.1:5432: connect: connection refused다.
• 반면 2026-03-11 현재 51123에서 curl http://localhost:3000/api/healthz는 status: pass, ss -tlnp 기준 3000, 5432는 모두 listen 상태다.
• Gitea DB action_runner 기준 runner id 4의 last_online은 2026-03-06 08:11:27+09, last_active는 2026-03-05 16:38:37+09에서 멈춰 있다.
• Gitea DB action_run 기준 rb8001 최신 run #677은 status=5, started=0, stopped=0 상태로 남아 있다.
• Gitea DB action_run_job 기준 #677의 deploy job은 task_id=0, started=0, stopped=0이라 runner에 task가 할당되기 전 단계에서 멈췄다.
• Gitea DB action_task 기준 rb8001의 마지막 task 생성 시각은 2026-03-05 16:23:25+09이고, 2026-03-06 이후 새 task는 생성되지 않았다.
• 2026-03-11 21:24 KST sudo /home/admin/scripts/start-act-runner.sh 실행 후 act_runner daemon --config .runner 프로세스가 다시 생성됐다.
• 재기동 직후 /mnt/hdd/logs/act_runner/act_runner.log에는 Starting runner daemon, runner: org-shared-runner ... declare successfully가 기록됐고, 이어서 새 task 2109, 2110이 실제로 생성·실행되기 시작했다.
• Gitea DB action_runner 기준 runner id 4의 last_online, last_active는 2026-03-11 21:25:15+09로 갱신됐다.
• 2026-03-11 21:25 KST 기준 pending run/job은 총 8건이며, skill-slack, skill-email, auth-server, skill-calendar, robeing-monitor, admin-dashboard, rb8001, nginx-infra 순으로 backlog가 남아 있다.
• 따라서 현재 rb8001 #677은 runner가 죽어서 영구 정지 상태는 벗어났지만, 아직 자기 차례 task를 받기 전인 queue 대기 상태다.
• 이후 rb8001 workflow 로그를 재확인하니 Setup SSH는 통과했지만 Test SSH Connection 단계에서 약 57초 정체 후 더 진행되지 않았다.
• 현재 rb8001/.env.deploy의 DEPLOY_SSH_KEY_PATH는 /home/admin/.ssh/github_deploy다.
• 2026-03-11 51123에서 ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 수동 테스트는 Permission denied (publickey,password)로 실패했다.
• 같은 시각 24 서버 ~/.ssh/authorized_keys에는 기존 51123-to-51124-deploy RSA 키는 있었지만, github_deploy에 대응하는 ssh-ed25519 공개키는 없었다.
• 2026-03-11 ssh-keygen -y -f /home/admin/.ssh/github_deploy로 산출한 github_deploy 공개키를 24 서버 admin ~/.ssh/authorized_keys에 추가했다.
• 추가 후 51123에서 ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 'echo SSH_OK'가 성공해 23 runner -> 24 SSH 인증 경로가 실증적으로 복구됐다.

현재 해석

• rb8001 저장소의 deploy SSOT 불일치 자체는 c7bca94로 상당 부분 해소됐고, 이 사실만으로는 최신 0s 종료를 더 이상 설명하기 어렵다.
• 현재 우선 원인 후보는 rb8001 앱보다 51123 Gitea Actions self-hosted runner 실행층이다.
• 특히 runner 프로세스 부재, systemd 유닛 부재, 로그 정지 시점(2026-03-06)이 함께 보여서 최신 #677은 workflow 본문 이전 단계에서 종료됐을 가능성이 높다.
• DB 기준으로도 #677은 task 미생성 대기 상태라, 0s 종료는 workflow 내부 스텝 실패보다 runner fetch/할당 경로 미작동 해석이 더 맞다.
• 재기동 이후 새 task가 다시 생성되는 것이 실증됐으므로, runner fetch 경로 자체는 복구 가능함이 확인됐다.
• 이후 수동 SSH 테스트 결과, 남은 핵심 병목은 runtime SSOT 자체보다 23에서 사용하는 deploy key가 24에 등록되지 않았던 인증 불일치였음이 확인됐다.
• runner 실행층과 SSH 인증 경로는 각각 별개로 확인됐고, 현재 남은 미해결 범위는 rb8001 새 run이 실제로 Test SSH Connection -> Deploy to Target Server까지 통과하는지 여부다.
• 다만 start-act-runner.sh의 --config .runner 사용이 실제 재기동 실패와 연결되는지는 아직 미확정이므로, 관측 사실과 추정 원인을 분리해서 다뤄야 한다.

직접 영향

• git push origin main이 배포 완료를 의미하지 않게 된다.
• 운영자가 수동 배포로 개입해야 하므로 배포 재현성과 추적성이 깨진다.
• runner가 실제로 죽어 있으면 rb8001뿐 아니라 같은 self-hosted runner를 쓰는 다른 저장소도 dispatch를 받아도 실행층에서 멈출 수 있다.

한 줄 결론

• 이번 자동 배포 실패는 rb8001 deploy SSOT 불일치에서 시작됐지만, 2026-03-11 기준 실증된 직접 병목은 51123 self-hosted runner 복구 이후에도 남아 있던 23 -> 24 deploy key 인증 불일치다.