Jenkins Pipeline이란?
Jenkins Pipeline이란 연속적인 작업들을 Jenkins에서 1개의 Pipeline으로 묶어 관리할 수 있게 만들어주는 Plugin이다.
Jenkins의 기본 작업 단위를 Item이라고 했는데, 이 Item을 연쇄적으로 수행시킴으로써 전체적인 1개의 CI/CD 흐름을 생성 및 관리해주는 Plugin이라고 생각하면 된다.
간단히 말하자면 여러 개의 Item을 하나로 묶어 관리할 수 있게 하는 것이 Jenkins Pipeline이다.
이 과정에서 의문이 생긴다. 굳이 Pipeline을 활용해아할까?
이전까지 우리는 1개의 Item을 가지고서도 충분히 Build 및 배포 과정을 수행할 수 있었다.
Item 1개만으로도 자동화된 CI/CD 과정을 구축할 수 있는데 굳이 배포 과정을 여러 개로 쪼개고 쪼갠 배포 과정을 다시 Pipeline으로 묶어 관리해야 할까?
개인적으로 혼자만 진행하는 프로젝트에서는 Jenkins Pipeline의 필요성이 적고, 오히려 독이 될 수 있다고 생각한다.
하지만 협업 과정에서는 Jenkins Pipeline의 필요성이 두드러진다.
개발 과정에 A, B, C 팀이 참여하며 아래 다이어그램과 같이 업무를 진행한다고 가정하자.
이때 A, B, C 팀을 위한 Item을 각각 1개씩 만든다고 가정해보자.
이 경우 겹치는 작업이 많음에도 불구하고 각 팀의 CI/CD 흐름을 각각 다른 Item으로 처리하기 때문에 어려움이 많이 생긴다.
예를 들어 작업 A에 대해 수정사항이 생겼다고 가정하자. 이 경우 A Item과 C Item에 접속하여 똑같은 변경사항을 적용해야 한다. 만약 변경사항을 적용하다 Human Error가 발생한다면 A팀과 C 팀의 CI/CD 흐름은 완전히 달라져 협업이 깨질 수 있을 것이다.
그나마 작업 A는 2개 Item에 존재하지만 작업 C 같은 것은 3개 팀에 공통적으로 수행되는 절차로써 Human Error의 발생 확률이 더 높아질 것이다.
즉, 모든 팀의 CI/CD 과정에 있어 각각의 Item을 만들어 관리하기에는 유지보수성이 매우 낮아지는 것이다.
하지만 아래 사진과 같이 관리하면 어떻게 될까?
이 경우 작업 C를 1개만 변경하더라도 동일한 변경사항이 A, B, C에 일괄적으로 적용된다. 즉, 유지보수성이 높아지는 것이다. 또한 1개의 절차만 수정해도 모든 팀에 동일한 변경사항이 적용되므로 팀 간 작업에 있어 일관성이 보장된다.
결국 Pipeline을 활용하면 Item(절차)의 재활용성이 높아진다. 또한 Item 변경사항이 모든 Pipeline에 일괄적으로 동일하게 적용되므로 절차에 대한 일관성이 보장된다. 또한 똑같은 절차를 여러 번 관리할 필요가 없고 1번 수정으로 전체 Pipeline에 동일한 수정사항을 적용할 수 있기에 유지보수성이 좋아진다.
이런 점에서 "협업"을 하는 환경에서는 Jenkins Pipeline이 매우 유용하다고 볼 수 있는 것이다.
Pipeline 생성
1. 연속으로 실행될 3개의 Item 생성
연속으로 실행될 Item 순서와 각각의 Item이 수행할 절차는 아래와 같다.
- Pipeline-First : WAR 파일을 빌드 & SSH Server에 배포
- Pipeline-Second : SSH Server에 배포된 WAR 파일을 활용해 Docker Image 생성 & Docker Hub에 배포
- Pipeline-Third : Pipelin-Second 과정에서 생성한 Docker Image를 활용해 Container 실행
참고로 생성할 Image 이름은 violetto/pipeline-project로 지정했고 실행할 Container는 pipeline-server로 지정할 것이다.
Docker Hub에 Image가 존재하지 않고 pipeline-server라는 Container가 실행되고 있지 않음을 확인할 수 있다
2. 생성한 Item에 추가 설정
Pipeline-First와 Pipeline-Second에 Item에서 Build가 완료한 이후 다음에 실행할 Item을 지정해줘야 할 필요가 있다.
Item > 구성 > 빌드 후 조치 > Build other porjects를 통해 다음에 Build 할 Item을 지정할 수 있다.
Pipeline-First
Pipeline-Second
Projects to build에 쉼표 구분자(,)를 통해 다음 Build 할 Item을 여러 개 설정할 수도 있다.
참고로 선택할 수 있는 Option들은 아래와 같다.
- Trigger only if build is stable : Item Build가 성공했을 때만 다음 Item Build를 시작
- Trigger even if the build is unstable : Item 빌드 후 조치가 실패했더라도 다음 Item Build를 시작
- Trigger even if the build failse : Build에 실패했더라도 다음 Item Build를 시작
3. 첫 번째 Item Build 수행
시간이 지나면 Pipeline-First만 빌드시켰는데 Pipeline-Second, Pipeline-Third까지 모두 빌드되는 것을 볼 수 있다.
이를 통해 정상적으로 Pipeline이 구축되었음을 볼 수 있다.
또한 localhost:8081/hello-world에 접속하여 Container가 정상적으로 실행됨을 확인할 수 있고 Docker Hub에 Image가 새로 등록된 것을 통해 Pipeline에 포함된 모든 Item이 정상적으로 수행되었음을 확인할 수 있다.
Pipeline 시각화
1. Jenkins 관리 > 플러그인 관리 > Delivery Pipeline 설
2. Pipeline 실행 과정을 볼 수 있는 View 생성
위 사진에 빨간색 네모 안에 있는 "+" 버튼을 클릭하면 "New view" Section이 나온다.
이 중 "Delivery Pipeline View"를 선택하여 Pipeline을 시각화한 View를 생성해보자.
3. New View 설정
나머지 부분은 지금은 설정할 필요 없다.
바로 마지막 Pipelines Section으로 가자. 이후 Components > 추가 버튼을 클릭한다.
- Name : Pipeline을 구분할 수 있는 이름
- Initial Job : Pipeline 시작 Item
- 우리는 Pipeline-First Item을 빌드함으로써 Pipeline 전체 과정을 시작했으므로 Pipeline-First로 지정해주면 된다.
- Final Job : Pipeline 종료 Item
- 만약 Pipeline 전체 과정이 아닌 일부분만 실행하고 싶다면 마지막 Item을 지정해줌
- 만약 지정하지 않는다면 Item의 설정에 따라 마지막 Pipeline Item까지 빌드할 것이다.
4. 시각화한 Pipeline 확인
위 사진을 통해 4번째 Pipeline이 제대로 실행되었음을 알 수 있다.
#1 ~ #3 과정에 Pipeline-Second 절차가 실행되는 SSH Server에 Docker Login을 하지 않아 Docker Hub에 생성한 Image를 Push하지 못하였는데, 이 문제 때문에 노란색(Unstable) 상태로 중간 종료되었음을 확인할 수 있다.
다시 Pipeline-First Item을 빌드해보면 현재 빌드하는 Item의 진행 상황을 파란색 게이지가 차는 것으로 실시간 확인할 수 있음을 알 수 있다.
