본문 바로가기

우아한테크코스

기술 스택 선정의 절망편 - 젠킨스 (jenkins)

프로젝트를 시작하면서 초반에 기술 스택을 선정하는 회의를 가졌다. 

다들 접해본 기술이 우테코 레벨 1, 2 를 진행하면서 사용했던 것들이 다라서 크게 고민했던 것도 없고 오래 걸리지도 않았다.

사실 이유를 솔직하게 적어보자면 기술 스택을 선정한 이유 중 가장 많았던 이유는 '이거밖에 안써봐서' , '써보고 싶어서' 였다. 

 

CI/CD 툴로 젠킨스와 깃허브 액션을 두고 고민하다 젠킨스를 선택하고 겪었던 어려운 점을 정리해보았다.

 

젠킨스를 선택했던 이유

젠킨스를 사용한 이유에 대해서 이렇게 정리를 했었다.

물론 이런 이유들도 있었지만 제일 큰 이유는 깃허브 액션은 전에 진행했던 미션에서 사용한 경험이 있기에 젠킨스를 사용해보고 싶어서였다.

젠킨스를 선택하고 힘들었어요

설치부터 힘들었던 기억

우리 서비스는 Java17 을 사용한다. 그리고 처음 젠킨스 LTS 이미지를 받아 젠킨스 컨테이너를 실행하고 jar 를 빌드했을 때 이런 에러메세지를 만날 수 있었다

 

Doesn't say anything about its target Java version (required compatibility with Java 11)

 

우리가 실행시킨 젠킨스는 자바 버전 11을 사용하는 이미지를 기반으로 해서 Java17 을 빌드하려니 에러가 생긴 것이었다....

 

그래서 Jdk17 을 사용하는 jenkins/jenkins:jdk17 를 사용해서 컨테이너를 실행시켰는데 자동 설치되는 플러그인이 제대로 설치되지 않았다.

 

설치안된 수많은 플러그인들..

결국 젠킨스 설치를 처음 시도했던 날은 지친 마음으로 집에 갔고 다음날 docker container prune 으로 아예 컨테이너 정보를 싹 밀어주고 다시 jenkins/jenkins:jdk17 를 실행시키니 잘 설치가 되어서 찜찜함이 남은 채로 젠킨스 사용을 시작하였다. 

EC2 를 하나 더 관리해야 해요

젠킨스는 젠킨스용 서버를 구축해줘야 한다. 우테코에서 제공되는 EC2 는 4개였고 한대를 젠킨스용 서버로 할당하다보니 운영서버, 개발서버, 운영 DB 서버, 개발 DB 서버, 모니터링 서버 등을 남은 3대로 잘 분배해줘야 했다. 

그리고 초반에는 프론트엔드 빌드가 서버 리소스를 많이 사용해서 젠킨스 서버가 터지는 일이 종종 있었다. 우테코에서 제공하는 EC2 는 ssh 접속을 캠퍼스에서만 허용하기 때문에 주말에 터지면 서버를 확인하고 살리려면 캠퍼스에 등교를 해야 했다!

깃허브 액션을 사용했으면 깃허브의 서버를 사용하기 때문에 관리 포인트를 하나 줄일 수 있어서 좋았을 거 같다. 그리고 제공되는 EC2 를 좀 더 유연하게 사용할 수 있지 않았을까 싶다!

다양한 플러그인을 제공하긴 하지만....

젠킨스는 다양한 기능을 플러그인을 기반으로 제공한다. 그래서 플러그인을 설치해야 하고, 해당 플러그인에 맞게 젠킨스 설정을 해주기가 어려웠다. 빌드한 jar 파일을 배포 서버로 전송하기 위한 ssh 플러그인을 사용할때도, 무중단 배포를 위해 docker hub 를 이용하기 위해 docker 플러그인을 사용할때도 항상 초반에 설정이 제대로 되지 않아 시간을 많이 빼앗겼다. 그리고 결국 보안 설정을 무시하는 옵션을 함께 사용해서 정말 동작하게끔만 설정해두기도 했다. 

장점

너무 단점만 적은거같아서 젠킨스를 사용함으로써 느낀 장점도 정리해보았다. 

젠킨스 파이프라인들
prod-cd 파이프라인

확실히 세팅만 잘해두면 UI 가 보기 좋다. 우리 프로젝트는 규모가 작아서 관리하는 파이프라인이 몇개 안되지만 파이프라인이 많이 추가가 된다면 젠킨스 UI 에서 관리하는게 훨씬 용이할 것 같다. 

우발적 복잡성

강의시간에 우발적 복잡성이라는 개념을 배웠다. 소프트웨어를 만들때 발생 및 경험하게 되는 우발적 복잡성은 도메인의 문제가 아니라 프레임워크, 데이터베이스 또는 기타 인프라 등의 솔루션으로 인해 발생하는 복잡성이다. 그저 사용하고 싶다는 이유로 젠킨스를 사용함으로써 우발적 복잡성에 대해 직접 경험했고 문제점을 느낄 수 있었다. 새로운 기술을 사용해보는 것도 좋지만 잘 모르는 기술을 사용함으로써 초래될 수 있는 문제를 해결할 수 있을지, 우리 서비스에 정말 필요한 기술일지를 고심해 볼 필요도 느꼈다. 우테코 과정이 마무리되면 EC2 제공이 되지 않기 때문에 프로젝트가 마무리된 후 서버 이관을 어떻게 할지 논의를 했었다. 젠킨스는 CI/CD 에 대해 정말 많은 기능을 제공해주지만 현재 서비스에서 사용하고 있는 기술들은 깃허브 액션으로도 충분히 대체할 수 있고 EC2 하나를 더 마련하지 않아도 된다는 장점도 있었다. 그래서 깃허브 액션으로 전환하기로 결정하였고 이관 작업은 현재 진행 중이다.