arko_renual/deploy

arko_renual 배포 구성

전체 구조

                  ┌──────────────────────────────────────────────────────────┐
   git push ─────>│ Gitea (git.zioinfo.co.kr) + act_runner                    │
                  │   ※ runner는 nginx를 거치지 않고 127.0.0.1:9003 직결      │
                  └────────────────────────┬─────────────────────────────────┘
                                           │
                  ┌────────────────────────▼─────────────────────────────────┐
                  │ 개발서버 zio-server (101.79.17.164, NAT 뒤)               │
                  │   Tomcat 9 :8088 (127.0.0.1) ← ROOT 전개                  │
                  │   MariaDB csv                                            │
                  │   nginx → https://csv.zioinfo.co.kr        [개발 웹]      │
                  └───────┬──────────────────────────────┬───────────────────┘
                          │ ① SSH 터널(운영→개발, 인바운드)  │ ② rsync(개발→운영)
                          │    8088 프록시                  │    정적 리소스
                  ┌───────▼──────────────────────────────▼───────────────────┐
                  │ 운영 웹서버 utimsurpai.cafe24.com (211.37.173.197)        │
                  │   nginx → https://csv.wise.ai.kr           [운영 웹]      │
                  │   정적: /var/www/csv.wise.ai.kr/static (로컬 서빙)        │
                  │   그 외: 터널 통해 개발 WAS로 프록시                      │
                  └──────────────────────────────────────────────────────────┘

WAS와 DB는 개발서버 것 하나만 쓴다. 운영 웹서버는 웹 티어 전용이다.

배포 흐름

bash deploy/dev/build-and-upload.sh   # ① 로컬 JDK8 빌드 + WAR 업로드
git push origin master                # ② 이하 자동

② push
   → 개발 WAS 배포 (ROOT 재전개 + 환경설정 주입 + 재기동 + 헬스체크, 실패 시 자동 롤백)
   → 개발 웹 확인 (csv.zioinfo.co.kr)
   → 운영 웹 배포 (정적 리소스 rsync)
   → 운영 웹 확인 (csv.wise.ai.kr)

개발 헬스체크를 통과한 뒤에만 운영으로 넘어간다. 문서(**.md)만 바뀐 커밋은 배포하지 않는다.

왜 이런 구조인가

빌드를 서버에서 하지 않는 이유 — 개발서버는 2코어에 가용 메모리 1G 안팎이고 40개 이상의 서비스가 동거한다. 실제로 2026-07-29 하루에만 서버 전체가 응답 불능이 되어 두 번 재부팅됐다. Maven(힙 1G)을 여기서 돌리지 않는다.

접속 방향 — 개발서버는 NAT 뒤라 외부에서 먼저 접속할 수 없다. 그래서

• 웹→WAS 연결은 운영 웹서버가 개발서버로 SSH 터널을 연다(아웃바운드)
• 배포는 개발서버가 운영 웹서버로 나간다(운영은 공인망 SSH 9271이 열려 있음)

터널을 쓰는 이유 — WAS의 8088은 NAT에서 포워딩되지 않고 Tomcat도 127.0.0.1 바인딩이다. 포트를 인터넷에 여는 대신 터널을 쓴다. 양쪽 키 모두 authorized_keys에서 용도를 좁혀 두었다.

키	위치	제한
id_arko_tunnel	운영 웹 → 개발	restrict,port-forwarding,permitopen="127.0.0.1:8088" (셸 불가)
id_arko_prodweb	개발 → 운영 웹	from="101.79.17.164",no-pty,no-port-forwarding,...

정적 리소스를 운영 웹이 직접 서빙하는 이유 — 릴리스마다 실제로 옮길 산출물이 생기고, WAS 왕복과 터널 트래픽이 줄어든다. 아직 배포되지 않은 파일은 @was 폴백으로 나가므로 전환 중에도 화면이 깨지지 않는다.

디렉토리

경로	내용
deploy/dev/	개발서버(WAS) 구축·배포 — 상세
deploy/web/	운영 웹서버 구축·배포
.gitea/workflows/deploy-dev.yml	파이프라인 정의

deploy/web

파일	실행 위치	역할
01-web-server-setup.sh	운영 웹	터널 서비스 + nginx vhost + SSL 발급
03-was-tunnel-key.sh	개발서버	운영 웹의 터널 공개키를 제한 등록
04-prod-web-deploy.sh	개발서버	정적 리소스 rsync (CI가 호출)
05-prodweb-prepare.sh	운영 웹	배포 키 등록 + 정적 경로 전환
arko-was-tunnel.service	운영 웹	SSH 터널 (자동 재연결)
csv.wise.ai.kr.conf	운영 웹	nginx vhost

운영 명령

# 개발서버
systemctl status arko-dev arko-dev-runner
tail -f /opt/arko-dev/logs/deploy.log
tail -f /opt/arko-dev/tomcat/logs/catalina.out

# 운영 웹서버 (ssh -p 9271 root@211.37.173.197)
systemctl status arko-was-tunnel        # 502가 나면 여기부터 확인
tail -f /var/log/nginx/csv.wise.ai.kr.error.log

알려진 이슈

act_runner 폴링 정지 (미해결 — 워치독으로 우회 중)

act_runner가 작업 하나를 끝낸 뒤 폴링을 멈춘다. 프로세스는 살아 있고 Gitea로의 TCP 연결도 ESTABLISHED 인데 응답 없이 물려 있으며, CPU 사용량이 완전히 정지한다(20초 관찰 시 utime/stime 변화 0). 재기동하면 밀린 작업을 즉시 집어간다.

시도한 것과 결과:

조치	결과
nginx 경유 제거 → Gitea 직결(127.0.0.1:9003) 재등록 (06-runner-reregister.sh)	재현
act_runner 0.2.11 → 0.2.13 업그레이드 (07-runner-upgrade.sh)	재현

근본 원인을 잡지 못해 워치독으로 보완했다. arko-runner-watchdog.timer가 1분마다 "대기 90초 넘긴 작업이 있는데 실행 중인 작업은 없는" 상태를 확인해 러너를 재기동한다. 실행 중인 작업이 있으면 절대 건드리지 않으므로 배포 도중 끊길 일은 없다. 동작 기록은 /opt/arko-dev/logs/watchdog.log.

즉 배포는 자동으로 완료되지만, 러너가 멈췄다가 최대 1분 뒤 워치독에 의해 살아나 처리되는 경우가 있다. 배포가 1~2분 늦어지는 것으로 보일 수 있다.

Gitea 1.22는 workflow_dispatch를 지원하지 않는다 — 넣으면 워크플로가 Actions 목록에 아예 뜨지 않는다. 수동 재배포는 git commit --allow-empty 후 push 로 한다.

개발서버 자원 — 가용 메모리가 상시 1G 안팎이다. Tomcat 힙은 448m로 묶여 있고 (arko-dev.service), 늘리기 전에 반드시 free -h 로 여유를 확인할 것.