[CICD] Jenkins 설치 방법과 간단 사용법

현 재직중인 회사에서는 Github Action을 통해서 이미지를 빌드하고(흔히 말하길 CI 과정), Argocd를 통해서 배포(흔히 말하길 CD 과정)을 진행하고 있다. 이처럼 Github Action + Argocd 조합으로 CI/CD 프로세스로 되어 있는 회사들이 많이 있다.

 

Github Action을 사용해본 사람들이라면 공감하겠지만, 생각보다 Github 장애 발생 비율이 적지 않다. 그리고 Github Action에 완전히 의존하는 경우에는 장애 상황에서는 배포를 할 수 없는 어려움이 있다.

 

그래서 일부 회사에서는 IDC 환경에 GitLab을 사용하기도 하고, Jenkins를 사용하기도한다.

필자는 지금까지 Github Action + Argocd 조합만 사용해봤기 때문에 Jenkins와 어떤 차이점이 있을까 알고싶었다.

---

CI/CD란?

먼저 CI는 Continuous Intergration의 약자이고, CD는 Continuous Deploy의 약자이다.

그리고 풀 네임에서 알 수 있듯이 CI는 코드 변경 사항을 자동으로 감지하고, 테스트하고 애플리케이션을 빌드하는 프로세스이며

CD는 CI 과정에서 만들어진 애플리케이션으로 자동으로 배포하는 프로세스이다.

 

CI/CD는 별도의 도구라기 보다는 코드 변경을 자동 빌드, 테스트하고 이를 자동으로 배포하는 Devops의 주요 방법론이다.

취지 자체가 자동화 프로세스를 통해서 품질과 속도를 향상시키고자 하기 때문에 Devops팀에서 많이 수행하는 업무이다.

 

CI/CD에는 여러가지 도구가 있지만, 대표적으로는 아래와 같다.

• CI : Jenkins, Github Action, CicleCI, GitLab
• CD : Argocd, FluxCD, Spinnaker

오늘은 Jenkins에 대한 사용 방법과 Github과 연결하여 자동으로 코드 변경사항을 인지하는 과정까지 진행해볼 예정이다.

Jenkins란?

Jenkins는 위에서 말한것과 같이 대표적인 CI 도구이다. Jenkins를 이용해서 CD 과정도 진행할 수 있다.

하지만 일반적으로 권고하지는 않는다. CD만 담당하는 도구를 사용하는게 훨씬 효과적이다.

Jenkins 배포 방법

배포는 기본적으로 helm-charts + EKS 환경을 기본으로 한다. 그리고 helm-charts를 사용해봤다면 설치는 쉽다.

아래 그림과 같이 jenkins에서 이미 helm-charts template이 공개되어 있기 때문에 values 파일만 수정해서 사용하면 된다.

Jenkins helm-chars

그리고 values 파일을 받았다면, 아래와 같이 쉽게 jenkins 이름으로 helm deploy를 할 수 있다.

• values 파일을 별도 주입하는 방식으로 했으나, helm 변수로 넣을 수도 있고 values 파일 없이 배포할 수 있는 방법도 있다.

helm install jenkins jenkins/jenkins -f ./jenkins_values.yaml

 

배포해보면 아래와 같이 statefulset 1개의 Pod만 생성된다.

왜 statefulset으로 배포되고 1개의 pod만 생성되나?

배포를 해보면 알겠지만, statefulset 1개밖에 생성되지 않는다. 그리고 가장 먼저 든 생각은 그럼 고가용성을 어떻게 확보할까? 이다.

찾아보니 jenkins는 별도 DB를 사용하지 않고, pipline 그리고 각 작업에 대한 결과를 PVC에 저장한다.

그렇기 때문에 자연스럽게 statefulset에서는 PVC를 동기화 할 수 없고, 그래서 1개의 pod만 유지가 된다.

 

물론 고가용성을 위해 External Share Storage를 사용하는 방법도 있으나, 일반적인 방법은 아니다.

그래서 Jenkins Controller는 1개만 유지하고, 각 Pieline에 대해서는 Agent Pod을 사용해서 고가용성을 확보한다.

Jenkins 고가용성 확보 방안

위에서 말한것과 같이 Jenkins Controller는 싱글톤 애플리케이션으로 구현되었기 때문에 다수의 Pod을 배포할 수는 없다.

대신에 Controller의 역할을 최소화하고, 실제 배포가 실행되는 Agent Pod을 추가하는 방식이 일반적으로 사용된다.

Jenkins HA 구성 방안

물론 Agent Pod을 사용하기 위해서는 Kubernetes Plugin 설치가 필요하다.

그리고 설치 후, Pipeline을 실행하면 Pipeline 이름으로 별도의 Pod이 실행되고 해당 Pod에서 Pipeline이 실행된다.

Agent Pod을 Github Action에 비유하면 Runner가 되는것이다. 차이점이 있다면 각 Pipeline마다 독립적이라는것이다.

Jenkins HA 방안

Jenkins - Github 연동 방법

Github과 연동하는 방법은 어렵지 않다. 1. Github Plugin을 설치하고, 2. PAT를 넣어주고 3. 확인할 Repo를 추가한다.

 

1. 먼저 Github Pluin을 설치한다. github으로 검색하면 바로 설치가 가능하다.

Github Plugin

2. Github Repo에 접근 권한이 있는 사용자의 PAT 를 넣는다. 쉽게 말하면 Token을 넣는것이다.

Github PAT 추가

3. 마지막으로 Github SCM을 추가하고, 내가 확인할 Repo를 추가한다.

SCM

Repo 추가

지금까지 이상이 없었다면, 이제 Jenkins Pod이 Gihub PAT를 이용해서 특정 Repo에 접근할 수 있는것이다.

그리고 마지막으로 Jenkins에서 어떤 방법 또는 주기로 Github 변경사항을 인지할지 Trigger를 선택하면 된다.

SCM Trigger

이 부분은 자세히 나와있는 부분이 없어서 ChatGPT 선생님의 답변을 찾아봤는데 아래와 같다.

가장 많이 사용하는 것이 Github Branchs가 될것 같다.

Trigger ChatCPT 선생님 답변

지금까지 설정에 이상이 없었다면, 특정 Branch에 Commit이 추가되면 아래와 같이 변경된 사항을 알 수 있고

Jenkins에서는 Agent Pod이 생성되고 Pipeline이 실행된다.

Github Trigger

 

 

Jenkins에서 Item을 만들때 보면 FreeStyle로 만들어서 사용했다.

하지만 이는 소규모 프로젝트, 정확히 말하면 Branch가 소수/고정된 브랜치를 사용할 때 일반적인 방법이다.

 

재직중인 회사에서는 Git Flow 방법론으로 개발이 진행되고 있기 때문에 FreeStyle로 Item을 만드는 경우에는 어려움이 있고

이런 경우는 MultiBranch Pipeline으로 만들어서 다수의 Branch를 같은 Pipeline으로 관리하는 방법을 사용한다.

 

이 부분은 조금 더 찾아보고, 게시물을 작성하도록 하겠다.

지금까지 Github Action만 사용했었는데 Jenkins를 써보니 또 다른 세상인것 같다.

• 무엇보다 Github Action 장애 상황이 없다는 것이 마음에 들었다. 그만큼 Pod 관리를 해야겠지만..
• 그리고 Github Action은 무료 Action을 넘어가면 초과과금이 발생하지만, Jenkins는 그렇지 않다.
  • 물론 이것도 Agent Pod로 인해서 EKS Node가 추가될 수도 있지만..

 

특정 솔루션이 무조건 좋고, 우위에 있는것은 없는것 같다. 어떤 솔루션이든 장/단점은 있다.

각 상황에 맞춰서 얻을 수 있는 부분과 포기할 수 있는 부분을 잘 고려해서 잘 사용할 수 있는 솔루션을 선택하면 될것 같다!!

 

그럼 이만!!