Jenkins와 Github Actions로 CI/CD를 구축하는 과정에서 계속해서 문제가 생겼다.
Github Actions로 Jenkins 트리거는 잘 이루어졌으나, Jenkins에서 빌드가 무한 로딩 상태에 빠져버리는 현상이 발생한 것이었다.
문제 상황
빌드가 실패하지는 않았다. 차라리 실패라도 했으면 원인을 알고 해결을 했을 텐데, 이유도 모르고 그냥 무한 빌드 상태에 빠져버리니 직접 종료-재실행만 반복하는 상황이었다. 콘솔 로그는 다음 메시지만 반복해서 출력되었다.
Still waiting to schedule task
Waiting for next available executor
원인을 파악하고 해결하는데 3일 이상이 소요되었고, 문제 해결 과정을 기록해본다.
접근 1. Executor 설정 변경
첫 번째로, 로그 메시지를 보고 Executor가 부족할 가능성을 의심했다. 일단 대기 중인 빌드는 전혀 없고, Executor도 2개지만 점유 중인 게 없어서 원인이 아닐 것 같기는 했지만, 내부적으로 내가 모르는 동작이 있을 수도 있으니 일단 executor의 수부터 늘려보았다.
Jenkins 관리->system에서 executor를 설정할 수 있다.
Executor의 수를 5로 늘리고 재실행 해보았지만, 여전히 무한 빌드 상태는 해결되지 않았다. 다른 원인을 찾아보았다.
접근 2: Built-in-Node 상태 확인
빌드 실행 화면을 유심히 관찰하다가 이상한 점을 발견했다. 빌드가 시작되었다가 Built-in Node가 오프라인으로 전환되면서 빌드 대기 목록으로 옮겨지는 현상이었다.
문제의 원인은 Built-in Node가 오프라인 상태로 전환되는 것이라 판단하고 노드 상태를 확인했다
Built-in Node를 클릭해 상태를 보니, 다음과 같은 경고 메시지가 표시되었다.(위 이미지는 문제 해결 후 캡처한 화면)
- Fee Swap Space: 0
- Free Temp Space : 457MB
Bring this node back online 버튼을 눌러 다시 온라인 상태로 전환해도, 빌드만 시작하면 즉시 오프라인으로 돌아가는 상태였다.
문제 원인 분석
1) Swap 공간 부족
Swap 공간은 시스템 메모리가 부족할 때 디스크를 임시 메모리로사용하는 기능이다. Jenkins는 빌드 작업 중 많은 리소스를 필요로 하는데, 어째서인지 Free Swap Space가 0으로 공간이 전혀 할당되지 않아 메모리 부족으로 인해 노드가 오프라인 상태로 전환 되는 것이었다.
2) Temp 공간 부족
Temp 공간은 시스템에서 임시 파일을 저장하는 디렉토리이다. 빌드 과정에서 Jenkins가 생성하는 임시 파일이 저장된다. 공간이 부족하여 빌드 작업에 필요한 임시 데이터를 생성하지 못해 문제가 발생할 수 있다. 내 경우에는 공간이 부족한 것은 아니었다. 457MB가 할당되어 있긴 했고, 또한 메모리 상태를 확인해보았을 때 딱히 사용중인 상태도 아니었다. 이 부분은 Jenkins의 temp 공간 관련 설정과 관련된 문제가 아닌가 의심하고 있다.
해결 과정
우선 Swap 공간을 2GB로 설정해주었다.
# 스왑 파일 생성 (2GB 예시)
sudo fallocate -l 2G /swapfile
# 권한 설정
sudo chmod 600 /swapfile
# 스왑 포맷
sudo mkswap /swapfile
# 스왑 활성화
sudo swapon /swapfile
# 부팅 시 자동 마운트를 위해 /etc/fstab에 추가
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Swap 공간을 확장한 후 Jenkins를 재시작하니 Free Swap Space 경고는 해결되었지만, 문제는 여전히 해결되지 않았다. temp 공간도 부족한가 싶어 용량을 늘려주었다.
# 1. 현재 /tmp 파티션 확인
df -h /tmp
# 2. 현재 마운트된 tmpfs 확인
mount | grep tmpfs
# 3. /etc/fstab 수정
sudo nano /etc/fstab
# tmpfs 설정 추가
tmpfs /tmp tmpfs rw,size=2G,nr_inodes=5k,noexec,nodev,nosuid,mode=1777 0 0
# 4. 변경사항 적용
sudo mount -o remount /tmp
# 6. 변경사항 확인
df -h /tmp
Swap과 Temp 공간을 모두 2GB로 확장한 후, 다시 빌드를 실행하니 빌드가 실패했다!! 드디어 로딩 상태에서 벗어난 것이다. 실패가 이렇게 반가울줄이야.
결과
결국 문제의 원인은 Jenkins가 빌드 과정에서 사용하는 시스템 자원의 부족때문이었다.
용량 확장 이후 자격증명과 파이프라인 스크립트로 인해 발생하는 문제를 수정하여, 빌드와 discord 메시지 전송까지 성공적으로구현했다
Jenkins 설정으로만 거의 3일 이상 소요된 것 같다. 당장 내일이 발표라 기능 개발이 우선인데도, jenkins를 활용한 자동 배포 파이프라인 구축을 꼭 해보고 싶었기 때문에 욕심을 부렸봤다. 생각 이상으로 많은 시간이 걸렸지만 결국 성공해서 뿌듯하다.
파이프라인 스크립트도 열 번 이상 수정하고, 자격증명도 필요한거 필요없는거 다 등록해보고, 설정도 하나하나 다 변경해보면서도 무한 빌드가 해결되지 않았다. 배포에 활용한 EC2 프리티어 문젠가 싶어 돈을 써야 하는 건가 많이 착잡했었는데, swap, temp 공간 확장으로 해결이 되어서 다행이라고 생각한다.
지금 생각해보면 이렇게 오래 걸릴 문제는 아닌 것 같다. 그냥 내가 jenkins에 대해 아는게 없어서 생긴 헤프닝인 것 같다. 그래도 3일 정도 삽질하면서 온갖 설정들을 다 건드려보고, Jenkins를 몸으로 부딪히면서 익힐 수 있었던 것 같다. ec2를 활용한 배포 설정을 하면서 ec2 사용에 대해서도 많이 배울 수 있었다. 다음번 CI/CD 구축 때는, 한 번에 성공할 수 있을 것 같은 자심감
'⭐project > petiary' 카테고리의 다른 글
| Petiary: 프로젝트 배포하기(S3) (1) | 2024.12.24 |
|---|
