본문 바로가기

백엔드 개발/Jenkins

[Jenkins] 젠킨스를 도커 컨테이너로 사용할 때 주의할 점 + (어떤 aws instance를 사용할까?)

반응형

개인 프로젝트에 빌드 자동화를 하기 위해서 젠킨스를 도입하려고 작업 중이다.

생각하고 있는 작업의 흐름은

push(혹은 pull request) -> web hook으로 jenkins에 http 요청 -> 빌드(gradle build) -> 성공시 docker build -> docker push

으로 진행된다.


1. 정품 = 좋은 것 = Jenkins Official = 정품


Official이라는 말에 공식 이미지를 pull해서 사용했었다.

그런데 처음에 실행하고 필요한 라이브러리를 받을 때 부터 뭔가 이상하다.

버전때문에 다운받아지지 않는 라이브러리가 꽤나 많다.

Docker Hub repository에 들어가보면 update 날짜가 5달 전이다.




2. simple is best? alpine is best?

alpine은 컨테이너에서 사용하기 좋은 리눅스 배포판이라고 한다.

용량이 5mb밖에 되지 않으니 정말 가볍긴 가볍다.

그리고 Jenkins 이미지의 크기 자체도 절반이상 차이가 난다.

공식이미지의 경우 Debian이고 alpine으로 구성되어 있는 애는 160mb 정도 된다.

그래서 alpine으로 구성된 docker image를 사용했다.

그런데 ./gradlw 같은 명령어가 먹지 않는다...

window 환경에서 잘 통과되던 test가 jenkins에서 깨지는 문제가 발생했다.

(물론 장인은 연장을 탓하지 않는다...근본적으로는 나의 부족함이 원인...)


총체적인 난국이라는 생각이 들었다.

alpine이 젠킨스를 돌리기 좋은 환경은 아니라는 생각이들었다.


3. jenkins/jenkins:lts image

절망해서 찾아보다가 Jenkins Official docker image를 찾게 되었다.

lts 버전이고 주마다 업데이트된다.

처음에 라이브러리 설치도 모두 다 잘된다.

alpine에서 실패하던 build 작업도 별다른 설정없이도 바로 통과된다.

(공식의 힘..)


요 며칠 엄청난 삽질을 하고 있다.

자동화를 하는 과정이 너무나 험난하다.

수동 배포와 키보드로 일일이 명령어를 치는 것이 머리는 덜 아픈 것이라는 생각도 들지만...

시작한 것 멈출 수 없다.

이제 github webhook으로 push가 되면 jenkins에서 build를 하는 과정과

jenkins에서 docker build를 하기 위해서 docker in docker 설정을 하는 작업을 진행할 것이다.


Tip


처음에 t2.micro로 인스턴스를 생성해서 젠킨스를 올렸는데.

테스트 용도의 간단한 프로젝트들은 빌드가 되었는데.

개인 프로젝트같은 경우는 빌드하니깐 인스턴스가 죽어버리는 일이 생겼다.

그래서 t2.medium으로 스케일업해서 빌드하니깐 잘된다.


반응형