사내에서 프로젝트의 빌드와 배포관리를 위해서 Jenkins를 사용하고 있다.

어느 날 Jenkins 대시보드를 열었는데, Job 설정이 전부 사라져 있었다. 처음엔 잘못 본 줄 알았는데, 새로고침을 몇 번 해봐도 똑같았다. Pipeline Script가 전부 비어 있어서 빌드도 못 하고 배포도 못 하는 상태였다.

예전에 GitHub Actions를 쓸 때는 당연히 이런 문제는 없었다. 지금은 GitLab이랑 Jenkins 조합으로 쓰고 있는데 (내부의 사정으로 Gitlab CI를 쓸 수 없다) Jenkins가 멈춰버리니 CI/CD가 그냥 정지된 거나 다름없었다. 조금 아찔했다.

---

문제 상황

딱 봐도 Jenkins에서 뭔가 크게 꼬인 게 확실했다. Job 목록이 전부 사라져 있었고, 마치 새로 설치한 것처럼 초기화된 상태였다. 사용자 계정 외에는 모두 날라간 느낌이었다.

원인 분석

확인해보니 문제는 플러그인 충돌과 네트워크 정책 때문이었다.

• 일부 플러그인이 특정 해외 mirror를 참조하는데, 서버에서 그해당 국가의 접근이 막혀 있었다. (국가 차단 룰 적용)
• 설치가 실패하면서 기존 버전과 충돌이 났다.
• 결국 Jenkins(2.513.1)에서 Job 설정이 날아가 버린 거였다. 특히 문제가 되었던 플러그인은 아래와 같았다.
  • commons-lang3-api
  • workflow-step-api
  • display-url-api
  • plain-credentials

이 중 일부는 설치가 안 됐고, 일부는 충돌이 나면서 결국 전체 Job이 초기화된 것 (혹은 콘솔에서 그렇게 보이는 상황)이었다.

대응 과정

원인을 알았으니 해결은 단순했다.

1. 서버 차단 정책을 수정해서 (해당 국가의 접근을 허용) 플러그인 설치가 가능하게 만들었다.

2. 플러그인을 전부 업데이트했다.

3. Jenkins 자체도 최신 버전(2.516.3)으로 업그레이드했다.

   sudo apt update
   apt list --upgradable | grep jenkins
   sudo apt upgrade jenkins

4. 다행히 빌드 기록은 남아 있었다. 성공한 빌드에서 Pipeline Script를 확인할 수 있었고, 그걸 복사해 다시 Job 설정에 붙여넣었다.

5. 개발 환경에서 빌드를 돌려보고 정상 작동을 확인한 뒤, 운영 환경까지 빌드를 완료했다.

---

결론

이번 사건으로 다시 느낀 건 Jenkins는 플러그인 의존도가 큰 툴이라는 점이었다.

• 네트워크 차단만으로도 문제가 생길 수 있다.
• 플러그인 충돌이 나면 Job 설정이 날아가기도 한다.
• Job 설정은 반드시 백업해둬야 한다. (특히 Pipeline Script, 물론 이전 빌드기록에서 추출가능하다.)

늘 잘 돌아가니까 당연히 괜찮겠지 하고 생각했는데, 방심했다가 크게 당한 셈이었다. CI/CD도 코드처럼 관리해야 한다는 기본기를 다시 떠올리게 된 사건이었다.

물론 GitHub Actions, Gitlab CI등을 쓰면 저장소에서 같이 관리하니까 신경쓰지 않아도 되겠지만.