🌻 Jekins란?
Jenkins라는 것은 지속적인 통합, 지속적인 배포라는 의미를 갖고 있는 CI-CD 작업에 있어서 시스템의 자동화 파이프라인 또는 워크플로우를 설계하는 데 사용되는 도구이다.
젠킨스 자체는 무료로 사용할 수 있으며 수많은 레퍼런스를 가지고 있다는 장점을 가지고 있고 플로그인 역시 풍부하다.
그러나 Jira라던가 또는 Redmine 등 이슈 트래핑 해주는 소프트웨어하고 연계하는 부분에 있어서는 다소 불편하다는 단점을 가지고 있습니다.
Jenkins의 플러그인으로서 우리가 Maven 또는 Grade 등 이러한 빌드 도구를 사용할 수 있고, 앞서 말한 SVN, SCM인 Git과 SVN과 같은 형상관리 시스템과 연동할 수 있는 플러그인이 풍부하다.
Jenkins를 이용해서 소스코드 형상관리 시스템에 저장되어 있는 코드를 가져온 다음에 빌드를 한다. 그리고 컴파일을 하고, 단위 테스트를 진행한다. 다음에 배포 작업을 위해서 패키징을 할 수 있다.
🌼 Jekins 외의 CI/CD 도구는 뭐가 있을까?
젠킨스, CircleCI, TeamCity, Bamboo, GitLab 이런 대표적인 제품들이 있는데 오픈소스로 되어 있는 것은 젠킨스가 유일하고, 나머지 제품들은 일정한 부분의 기능을 사용하려고 하면 유료 서비스로 사용해야 한다는 단점을 가지고 있다.
사용성을 보면 다 비슷하다. 그 다음에 내장되어 있는 기능에 대해서는 다른 제품군에 비해 젠킨스가 살짝 떨어지는 면이 있지만 통합이라든가 플러그인 쪽 부분에서는 다른 쪽에 있는 서비스보다는 많고 훨씬 더 많다.
또 하나의 특징이 자체적으로 직접 구축할 수도 있고 클라우드 서비스도 사용할 수 있다. 무엇보다도 무료이다 라는 강점이 있다.
그리고 현재 지원되는 시스템으로서는 Windows 다음에 리눅스, 맥OS 유닉스 다 제공이 된다.
🌷 Jenkins Pipeline
기본적으로 시스템 개발은 개발팀에 의해서 코드 개발이 완료가 되면 앞서 말한 VCM 또는 SCM에서 코드를 저장한 다음에 개발 환경에서 빌드가 되고 단위 테스트하는 단계로 넘어간다.
통합 테스트에 이르기까지 각 단계가 다 끝나야지만 고객이 테스트할 수 있는 UAT 환경으로 넘어가게 된다.
UAT 환경에서의 작업이 마무리가 되어야 그 다음 단계에 속하는 PROD(프로덕션) 작업으로 넘어간다. CI/CD 작업 도구에서는 이렇게 각 단계로 넘어가는 과정을 수작업으로 처리해주는 것이 아니라 자동으로 처리해서 넘어갈 수 있게끔 구성을 할 것이다.
Jenkins에서도 작업하려고 하는 기본적인 단위가 Item(아이템)이라는 단위로 만들어지게 되는데 각각의 단계를 하나의 아이템으로 구성을 해서 실행할 수 있고, 이러한 아이템들을 여러개 묶어서 Jenkins에서 말하는 파이프라인이라는 것을 구성해서 작업할 수 있다.
Jenkins의 파이프라인 이라는 것은 CD 작업에 의해서 필요한 파이프라인을 실제로 구현을 하고 통합하는 것을 지원하는 플러그인이라고 보면 된다.
Jenkins만의 고유한 문법 체계인 DSL을 이용해서 파이프라인 스크립트를 만들 수 있고, 파이프라인 스크립트는 만들 때 사용되는 이름이 Jenkins File 이라는 파일명을 갖게끔 되어 있다.
DSL 이라는 것은 Domain Specific Language 라고 해서 도메인에서 정의한 특화되어 있는 언어 , 다른 쪽을 사용하지 않고 그 서비스에서 그 아이템에서 새롭게 정의해서 만드는 언어라는 뜻으로써 Doker File과 Jenkins File 같은 것들이 DSL이라고 생각하면 된다.
Jenkins File은 크게 두가지 형태로 만들 수 있는데
1. 선언형 방식으로 만들 수가 있고
2. 스크립트 방식으로 만드실 수 있다.
🌴 Jenkins 설치
https://www.jenkins.io/download/
Jenkins 공식 사이트에 가면 설치할 수 있는 버전 또는 배포 유형이 소개되어 있다.
난 도커에 Jenkins를 배포해보도록 하겠다.
실제로 도커에 설치를 하던 Windows에 설치하던 맥OS에 설치하던 설치하는 방법에 의해서 차이가 약간 있을 뿐이고 실제 사용하는 방법에 의해서는 동일하기 때문에 어떠한 배포판을 사용한다 해도 크게 상관은 없다고 한다.
각자 사용하는 운영체제 플랫폼에 맞춰서 도커 런타임을 준비해야 되는데 Windows 환경과 맥OS 환경에서 도커 데스크탑이라는 것을 먼저 설치해야 한다.
첫번째 소개하고 있는 파일은 도커, war 형태 파일이다.
Jenkins 자체가 Java 웹 어플리케이션 형태로 구성되어 있다 보니까 JDK가 설치되어 있는 환경이라고 하면 그냥 바로 실행 할 수 있게끔 제공이 되고 있다.
도커 부분을 선택하면 docker hub 사이트를 이동하게 되는데 이 허브사이트는 별도로 회원가입을 따로 해야 무료로 사용 가능하기 때문에 계정 하나씩 갖고 있어야 한다.
도커 허브 사이트에 만들었던 이미지를 업로드하고 다운로드 받고 하는 과정이 있어서 회원가입을 반드시 해주어야 한다.
지금처럼 도커 허브 사이트가 보면 크게 데이터에 대한 표현법이 이렇게 /(슬러시)를 기준으로 해서 나오게 되는데 앞에 있는 것은 만들고자 하는 계정이라 보면 된다. 뒤쪽에 있는 것은 repository(저장소) 이름이라고 보면 된다.
jenkins/jenkins로 나왔다는 이야기는 Jenkins 계정의 Jenkins Repository라고 보면 된다.
docker pull jenkins/jenkins
하단에 보면 어떻게 Jenkins를 사용할 것인지에 대한 간단한 코멘트가 나와 있다. 제일 먼저 도커 이미지를 다운로드 받는게 필요할 것이기 때문에 오른쪽을 보면docker pull jenkins/jenkins 라고 적혀 있다.
현재 Jenkins 같은 경우에 두번째 탭 메뉴를 클릭해 보시게 되면 latest 버전이 있고 windowsservercore 버전 등 여러가지 형태의 버전들이 있다.
태그(Tag)는 버전을 나타내는 경우가 대부분이다. 버전이라던가 실행 환경이라던가 해당하는 서비스가 베이스가 되고 있는 이 라이브러리가 어떤 것인지를 나타날 때 보통 이 태그를 활용을 하고 있기 때문에 태그를 보면서 어떤 형태의 Jenkins 인지 확인해 볼 수가 있다.
아무것도 입력하지 않으면 그냥 latest고 해서 가장 최신에 발표된 젠킨스 버전을 쓰겠다라고 보면 된다.
일반적인 젠킨스가 필요한 환경이기 때문에 OverView에 있던 PUll(= 도커에서 이미지를 다운로드 받는 명령어)이라고 적힌 해당하는 명령어를 복사하여 터미널 또는 명령 프롬프트 창에다가 실행한다.
https://github.com/jenkinsci/docker/blob/master/README.md
위 링크를 타고 들어가면 젠킨스 이미지의 Official(오피셜) 페이지가 나오고 사용하는 방법 커맨드가 나와있다.
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
기본적으로 첫번째 도커에서 이미지를 생성할 때 사용되는 커맨드가 run 이라는 커맨드 이고, run 이라는 커맨드 뒤에 보시게 되면 -p 옵션이 붙어있다.
-p 옵션은 publish 옵션이라고 해서 컨테이너 내부에 있는 포트를 컨테이너 바깥쪽에 있는 환경에서 어떻게 접속해서 사용할 것인지를 나타내는 설정이다.
컨테이너 바깥쪽에서 8080이라는 포트를 하게 되면 컨테이너 내부로 8080 접속이 된다는 뜻이다.
두 번째 옵션 같은 경우는 컨테이너 외부에서 50000번 호출하게 되면 컨테이너 내부가 50000번이 응답하겠다는 뜻이다.
--restart=on-failure란 옵션에서 fail이 됐을 경우에 restart시켜 줄 것이다.
그 다음에 제일 마지막에 나와 있는 jenkins/jenkins은 도커에서 사용할 수 있는 Jenkins 계정 이름과 그리고 repository 이름 이다.
:(콜론) 뒤에 나와있는lts-jdk17은 우리가 사용하려고 하는 태그의 이름인데 LTS JDK 17 버전을 쓰겠다고 되어 있죠.
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17
-v jenkins_home:/var/jenkins_home :
두 번째 실행 옵션을 보면 위와 다른 점은 -v 옵션이 들어가 있는데 -v 옵션은 볼륨이라고 해서 쓰고 있는 docker가 설치되어 있는 PC, Windows라던가 맥OS같은 PC에서 어떠한 디렉토리하고 도커 내부에 있는 디렉토리하고 마운트, 즉 연결작업을 할 건지에 대한 설정이다.
마운트 작업이 필요한 이유는 마운트 작업을 하지 않았을 경우에 도코 내부에서 발생되어진 데이터는 도커 내부에 저장된 것이기 때문에 도커가 삭제되어 있게 되면 해당 데이터가 같이 없어져 버린다.
또는 도커 내부에 저장된 데이터 값을 없어지지 않게 하기 위해서 어딘가에 그 데이터를 보관시켜 놔야 된다.
이 보관하는 방법 중에서 도커가 실행되고 있는 외부에 해당하는 폴더의 내용을 연결해서 링크를 잡아놓은 다음에 저장하는 방법을 마운트라고 한다.
두 방법을 비교했을 때 두 번째가 볼륨 마운트 작업이 추가로 들어있다는 차이점만 존재하기에 무엇을 실행해도 상관없다.
난 첫 번째 명령어에 추가 옵션을 몇 개 적어서 사용해 볼 것이다.
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 --restart=on-failure --name jenkins-server jenkins/jenkins:lts-jdk17
--name jenkins-server 이라고 적은 이유는 만들고자 하는 컨테이너에다가 이름을 부여하겠다는 것이다.
이렇게 이름을 부여하지 않게 되면 랜덤하게 이름을 만들어 생성을 해버리게 된다. 그러기에 이름을 꼭 지정하는 것을 권장한다.
세번째 커맨드를 보시게 되면 -d 옵션이 들어가 있다. detach모드라고 해서 현재 실행하고 있는 콘솔과 터미널과 분리한 상태에서 실행하겠다는 뜻이다. 즉, 백그라운드로 기동하겠다는 뜻이다.
위에서 살펴본 토대로 컨테이너 실행 명령어를 cmd에 직접 적어 실행시켜보았다.
프로세스가 정상적으로 작동됐는지 확인하시려면 docker ps 입력하면 현재 도커가 UP 상태인 것을 확인할 수 있다.
포트 영역을 보면 0.0.0.0:8080->8080/tcp에서 "0.0.0.0"은 모든 네트워크 인터페이스를 의미하며, "8080"은 포트 번호를 나타낸다. "->"는 포트 포워딩 또는 매핑을 의미하고, "8080/tcp"는 이 포트가 TCP 프로토콜을 사용한다는 것이다.
0.0.0.0:50000->50000/tcp "0.0.0.0"은 여전히 모든 네트워크 인터페이스를 나타내고, "50000"은 포트 번호를 나타낸다.. "->"는 포트 포워딩을 의미하며, "50000/tcp"는 이 포트가 TCP 프로토콜을 사용한다는 것이다.
위는 Jenkins를 docker 형태로 실행을 했을 때 콘솔 로그에 출력되는 내용이다. 중간에 보면 초기 패스워드를 확인할 수 있다.
이 초기 패스워드는 Jenkins에 웹페이지 접근을 할 때 제일 먼저 요청되는 패스워드이기 때문에 초기 패스워드 입력하는 란이 있으면 거기에 입력해 주면 된다.
docker logs jenkins-server
다음 명령어로 초기 패스워드를 확인한다.
🌵 Jenkins 세팅
접속하는 방법은 가지고 있는 ip address 또는 localhost로 입력 후 포트 번호를 쓰면 된다. 난 아까 8088이 아니라 8080으로 만들었기 때문에 8080으로 접속해주면 된다.
그리고 처음 접속하면 관리자 Administrator의 초기 패스워드를 요청하게 되는데 방금 말한 콘솔의 초기 패스워드를 복사했다가 여기에 입력하면 된다.
다음엔 Jenkins의 플러그인들을 설치할 수 있도록 안내가 나오는데 기본적인 모든 플러그인을 다 설치할 건지 아니면 플러그인을 설치할 것인지 골라주면 된다.
난 모든 플러그인을 다 설치하였다.
플러그 설치가 완료가 되면 이렇게 Jenkins 사용할 수 있는 초기 관리자 암호를 요청할 계정 생성을 요청하게 된다. 나는 여기에 간단한 어드민 이라는 계정을 하나 만들어서 사용하도록 하겠다.
모든 작업이 다 끝났으면 접속할 수 있는 방법이 소개된다. 127.0.0.1 (로컬호스트 또는 현재 사용하고 있는 ip주소) 다음에 포트 번호까지 입력하게 되면 Jenkins 에 접속할 수가 있다.
하단에 있는 마지막 단계 하단에 있는 Start using Jenkins 라는 버튼을 클릭하면 되면 바로 서비스에 접속할 수 있게 된다.
잰킨스의 플러그인까지 설치가 끝났으면 본인의 ip address 또는 localhost 127.0.0.1 등을 입력한 후 포트번호까지 잘 적어준다.
제일 먼저 액세스 하면 방금 생성했던 관리자 아이디로 로그인을 할 수 있을 것이고, 왼편에 보면 대시보드 선택이 되어 있는데 현재는 대시보드엔 아무것도 없다.
아이템을 만들지 않았기 때문에 비어있는 화면이 보인다.
만약에 아이템을 추가로 만들어서 빌드도 계속 테스트해보면 마지막에 그 아이템이 언제 실행됐는지 상태가 어땠었는지를 확인할 수 있다.
아이템이라는 것은 Jenkins에서 사용하고 있는 작업의 최소 단위이다. ( DevOps와 CI/CD 포스트 에서도 말했다. )
빌드 후 배포를 할 때 아이템이라는 걸 만들어서 어떤 작업, 어떤 과정을 할 것인지 기술을 해줄 것이다.
그 밑에는 이제 계정에 관련된 부분, 사용자를 새롭게 추가하는 부분도 메뉴로 볼 수 있다.
첫 번째로 할 작업은 Jenkins 관리라는 메뉴로 이동을 해볼 것이다. Jenkins 관리에서 JDK 설정이라든가, Maven 설정이라든가 이런 부분들을 여기서 진행하도록 하겠다.
지금은 잘 보이지 않지만 밑에 보면 빌드 대기 목록도 있고, 빌드 실행 상태라는 것도 있다. 빌드 실행 상태라는 것은 현재 아이템의 실행 여부, 실행 중에 어떤 로고를 가지고 있는지, 실행 결과가 어땠었는지를 나타내는 항목이 될 것이다.
그 위쪽에 보시기에는 빌드 대기 목록이라는 것은 현재 실행된 항목 다음에 실행될 내용들, 그런 내용들을 볼 수 있다.
첫 번째 Jenkins 관리라는 메뉴에 가서 다음에 Tools 메뉴를 선택해 볼 것이다.
그리고 JDK 설정을 제일 먼저 해볼건데 만약 맥OS 혹은 Windows 환경에서 Jenkins를 별도로 설치했다고 하면 당연히 JDK의 홈 디렉토리 위치를 별도로 지정해 주시는게 필요하다. JDK가 존재하지 않으면 Jenkins 자체가 기동이 안된다.
그래서 사전에 JDK가 설치되어 있어야 하고 그 설치되어 있는 JDK의 위치 정보를 정확하게 명시해 주어야 한다. 본인이 쓰고 있는 환경에 맞춰서 잘 설정해주면 된다.
Docker 상태로 Jenkins를 기동할 때는 그 Jenkins 안에 JDK가 정확하게 명시되어 기동되어 있는 상태이기에 해당하는 폴더만 잘 설정해주면 된다. (Add JDK 해줄 필요X)
밑에 보이는 Install Automatically라는 버튼을 클릭하면 하단과 같은 메뉴가 나온다. 하단 메뉴에서 해주는 작업은 JDK가 설치가 안되어 있다라고 가정을 했을 때 자동으로 JDK를 설치해주는 메뉴이다. 이 메뉴에서는 Oracle의 계정을 필요로 한다.
보시는 것처럼 구 버전만 지원하고 있어서 11버전 이상을 사용하고 싶다고 하시면 OpenJDK를 사용하시는 걸 권장한다.
🌳 첫번째 Item(Project) 생성
Jenkins 관리에서 JDK 설정까지 확인하셨으면 첫번째 프로젝트를 생성해 보도록 하자.
Jenkins에서는 빌드하고 컴파일하고 배포하고 이런 단위의 최소로 아이템이라는 용어를 사용.
대시보드 화면에서 왼편에 있는 새로운 아이템이라는 메뉴를 클릭하고 첫번째 아이템 작성을 한번 해보자.
첫번째 만들고자 하는 아이템의 이름을 My-First-Project 라고 지었다.
프리스타일도 있고 파이프라인 등 여러가지 템플릿들이 보인다.
이후에 추가 몇몇 플러그인들이 있는데 아직 그 플러그인들까지는 포함이 안되어 있는 상태여서 프리스타일로 프로젝트를 생성하도록 하겠다.
첫번째 있는 프리스타일 선택 후 하단에 있는 ok 버튼을 클릭한다.
젠킨스에서 제일 먼저 보이는 화면에서는 일반적인 프로젝트 설명이라던가 소스코드를 어디서 갖고 온다던가 이런 설정들을 할 수 있다.
소스코드 관리를 할 때 Git에 사용할 건지, 빌드를 하는 이벤트 조건을 어떻게 할 것인지, 빌드 환경이라던가 실제 액션은 어떤게 있고, 빌드가 끝난 다음에 패키징을 하고, 패키징되어 있는 코드를 어디다가 저장을 하고 등 각 항목별로 나눠서 할 수 있다.
첫번째 예제에서는 다른 것들은 바꾸지 말고 중간에 보면 Build라는 항목에다가 콤보 박스를 클릭하면 두번째에 있는 Execute Shell 이라는 항목을 선택할 수 있다.
즉 지금 만드는 첫번째 아이템에서 이 아이템을 실행하게 되면 어떤 Shell 스크립트가 실행될 수 있도록 처리를 하려고 한다.
만들고 있는 이 Jenkins 자체가 Docker에 설치가 됐었다. Docker는 기본적으로 운영되고 있는 운영체질을 Linux로 사용하고 있기 때문에 다시 말해서 사용하고 있는 Jenkins는 Linux에 설치가 되어 있다라고 볼 수가 있다.
따라서 여기서 말하는 Shell Script를 실행하는 환경은 Linux의 Shell Script라고 보면 된다.
간단하게 echo 문장을 한번 출력해보자.
echo "Welcome to my first project using Jenkins" 를 작성한 후 저장해준다.
저장이 되면 이렇게 대시보드의 My-frist-Project가 선택되어 있는 상태이다.
대시보드로 돌아가기 버튼을 클릭하시게 되면 상위 폴더로 이렇게 이동할 수 있다.
아직 My-frist-Project 프로젝트에 대해서 한 번도 빌드를 한 적이 없었기 때문에 가장 마지막에 실패를 언제 했고 성공을 언제 했는지에 대한 항목이 보이지 않고 있다.
My-frist-Project 로 돌아가 네 번째에 있는 지금 빌드를 선택해보자.
빌드를 선택하시게 되면 하단에 빌드가 진행되고 있는 상태를 볼 수 있다.
정상적으로 잘 끝났다고 하면 일반적으로 초록색의 아이콘이 보이고, 실패했다고 하면 붉은색의 아이콘이 보인다.
여기선 빌드가 성공한 시점이 표시가 되어 있다.
시간 옆에 있는 콤보박스를 클릭한 후 두 번째 항목에 Console Output이라는 항목을 클릭해 보겠다.
여기선 아웃풋 메시지가 어떤게 있는지 표시가 되어 있는데 중간에 보시게 되면 My-First-Project가 실제로 실행을 하면 있어서 워크스페이스는 어디에 자리 잡고 있는지 두번째 추가시켰던 명령어인 에코 문장을 확인할 수 있다.
약간 수정을 한번 해보자. 프로젝트로 돌아가 구성 이란 메뉴를 클릭한다.
조금 전에 수정했던 메뉴가 보인다. 여기에 echo 라는 문장 밑에다가 우리가 사용하고 있는 jdk 버전이 얼마인지 javac -version 이라는 명령어를 추가로 넣어보자.
빌드 후 Console Output 으로 확인해보면 수정한 부분이 출력되는 것을 확인할 수 있다.
그 다음에 워크스페이스를 확인해 볼 수 있다.
이건 도커의 터널링을 이용해서 확인할 수 있다.
터미널에서 docker ps 를 입력하면 현재 젠킨스가 작동되고 있는 화면을 볼 수 있다.
여기에서 현재 기동되고 있는 Jenkins에 터널링해서 접속 하려면 docker-exec-it 컨테이너이름(혹은 아이디) bash 라고 명령어를 치면 된다.
난 사용할 shell 스크립트로 bash를 선택하였다.
위 명령어를 치고 난 뒤 화면은 기동되고 있는 도커 형태의 젠킨스에 터널링 해서 들어갔을 때 모습이라고 보면 된다.
여기서 파일 목록을 보기 위해서 리눅스 명령어 중에서 ls라는 명령어를 입력하면 도커에서 기동되고 있는 젠킨스 내부의 파일을 볼 수 있다.
결과 화면에서 보였던 워크스페이스의 위치로 /var/jenkins_home/workspace 까지 이동을 해보자.
실행했던 MyFirstProject라고 되어있는 폴더를 확인해보면 아무것도 표시가 되어있지 않다.
내가 만들었던 이 첫번째 아이템은 패키징을 하지 않기 때문이다. 즉, echo와 자바 버전을 확인하는 스크립트 명령어들은 실행은 되지만 빌드를 한 후의 결과물을 어떤 형태로 패키징 즉 압축을 한다든가 어떤 파일에 이 빌드 되어있는 결과물을 만들고 있지 않는다.
하지만 이 이후의 과정에서 패키징 과정을 추가하고 빌드 되어있는 결과 파일을 만든다는 명령어를 넣으면 앞에 있는 폴더에 원했던 파일이 생성되는 것도 확인할 수 있긴 하다.
출처
