runner를 nginx 경유(https://git.zioinfo.co.kr)로 등록하면 declare까지는 되는데
작업을 가져오지 않고 재기동해야만 처리하는 문제가 있었다. long-poll이 nginx의
proxy_buffering(기본 on)에 물리는 것으로 보인다. Gitea가 같은 서버에 있으므로
127.0.0.1:9003 직결로 재등록해 해결했고, 재발 시 쓰도록 스크립트로 남긴다.
deploy/README.md에 전체 구조(개발 WAS/DB 단일, 운영은 웹 티어 전용),
접속 방향이 양쪽으로 다른 이유(NAT), 키 제한 범위, 알려진 이슈를 정리했다.
웹 티어(211.37.173.197 / Rocky 8):
- csv.wise.ai.kr nginx vhost + Let's Encrypt SSL
- WAS는 SSH 터널(arko-was-tunnel.service)로 연결 — 개발서버가 NAT 뒤라
8088이 포워딩되지 않고 Tomcat도 127.0.0.1 바인딩이기 때문이다.
키는 WAS에서 restrict,permitopen="127.0.0.1:8088" 로 묶어 셸 접근 불가.
- 정적 리소스는 운영 웹이 직접 서빙하고 없으면 @was 폴백 — 전환 중에도 깨지지 않는다.
파이프라인:
git push -> 개발 WAS 배포 -> 개발 헬스체크 -> 운영 웹 정적 배포 -> 운영 검증
개발 헬스체크를 통과한 뒤에만 운영으로 넘어간다.
접속 방향은 개발->운영(개발서버는 NAT 뒤라 역방향 접속이 불가능하다).
Gitea 1.22.3은 workflow_dispatch(수동 실행)와 inputs 컨텍스트를 지원하지 않아
워크플로가 Actions 목록에 표시되지 않았다. 트리거를 push 하나로 단순화한다.
롤백은 서버에서 직접 수행하도록 README에 절차를 남긴다.
Tomcat 힙도 768m -> 448m로 낮춘다. 가용 메모리 1G 안팎인 서버에서
Tomcat 재기동 직후 서버 전체가 응답 불능이 된 사례가 두 번 있었다.
- 00-server-setup.sh: JDK8(Temurin)·Tomcat9·systemd·nginx·act_runner 구축 (멱등)
- arko-dev-deploy.sh: WAR 검증→백업→ROOT 재전개→환경설정 주입→기동→헬스체크→실패 시 롤백
- build-and-upload.sh: 개발자 PC에서 JDK8 빌드 후 WAR 업로드 (서버 자원 보호)
- deploy-dev.yml: master push 시 자동 배포, 수동 재배포·롤백 지원
서버가 2코어/메모리 여유 1G에 40여 개 서비스가 동거하는 환경이라
Maven 빌드는 서버에서 돌리지 않고 개발자 PC에서 수행한다.
JSP가 리소스를 컨텍스트 경로 없이 하드코딩해 ROOT 전개만 가능하며,
globals-{dev,live}.properties는 .gitignore 대상이라 서버 config/에 두고 배포 시 주입한다.
