2023. 1. 9. 22:30ㆍCICD
Jenkins(이하 젠킨스) 는 CI/CD 환경을 구축하기 위한 오픈소스 도구이다.
워낙 유명한 도구이니 자세한 설명은 생략하겠다.
요즘은 AWS, GCP, Azure에서 강력한 managed(지들이 운영하는) CI/CD 서비스를 내고 있고
Circle CI 등 유료 툴들이 나오면서 그 위상이 많이 떨어진게 사실이다.
하지만 특정 환경에 종속되는 CI/CD 환경 구축을 원하지 않거나,
비용적인 측면을 고려했을 때 무료 오픈소스라는 점에서 여전히 많이 선택되는 툴임은 분명하다.
젠킨스를 이용하는 방법과 방식에는 여러가지가 있겠지만 Pipeline을 사용하는 것이 대다수이다.
이번 포스팅에서는 젠킨스의 Pipeline 소스코드들을 모듈화해서 관리할 수 있는 Jenkins Library에 대해 다루겠다.
1. Jenkins 파이프라인
위 이미지는 Jenkins에서 CI/CD 환경 구축을 위해 "+ 새로운 item" 버튼을 누르면 나타나는 화면이다. (버전에 따라 조금 다를 수도 있다)
이 선택지들 중 앞서 언급한 대로 두번째 Pipeline을 많이 사용할 것이다.
Pipeline을 많이 쓰는 이유는 단계를 나눠 어플리케이션의 빌드 및 배포를 한 눈에 볼 수 있고 유지보수성이 뛰어나기 때문이다.
Pipeline은 step과 stage 별로 각 단계에 해야할 어플리케이션 빌드나 배포에 필요한 작업들을 나눠서 관리 할 수 있고,
코드 형태이기 때문에 필요한 상수들을 전역변수로 만들고 재사용할 수도 있다.
2. Jenkins Shared Libraries 개요
여기에 유지보수성과 확장성을 극대화 해주는 젠킨스 도구가 있다.
바로 Shared Libraries, 일명 공유 라이브러리이다.
이제부터 Pipeline과 함께 공유 라이브러리가 필요한 이유를 알아보자.
아래는 AWS환경에 EKS, 도커, sonarqube 정적 분석 등을 활용하여 배포하는 pipeline 코드 예시이다.
pipeline{
agent any
environment{
GIT_COMMIT_HASH = sh ( script: "git log -n 1 --pretty=format:'%H'", returnStdout:true)
GIT_COMMIT_TAG = "${GIT_COMMIT_HASH.substring(0,8)}"
SYSTEM_NAME = sh (returnStdout:true,
script: """
basename \$(git remote get-url origin) | sed -e "s/.git\$//" | sed -e "s/\\nn//"
""")
def sonarqubeScannerHome = tool name:'SONARQUBE_SCANNER', thpe:'hudson.plugins.sonar.SonarRunnerInstallation'
}
stages{
stage('step1 : Application Build') {
steps{
gradle 빌드 내용
}
}
stage('step2 : SonarQube Analytics') {
steps{
sonar 실행 내용
}
}
stage('step3 : Docker Image Build and ECR Push') {
steps{
docker 내용
}
}
stage('step4 : Deploy EKS') {
steps{
EKS qovh
}
}
}
post{
success{
slack webhook
}
failure{
slack webhook
}
}
}
만약 시스템이 MSA구성이 되어 있고 spring 프레임워크를 사용하는 어플리케이션이 15개라고 하면 위 Jenkinsfile이 15개 이상이 필요할 것이다.
그러면 15개의 Jenkinsfile 내용이 얼마나 다를까?
거의 비슷할 것이며 반복적으로 기술할 내용이 많을 것이다.
이는 곧 어느 한 부분이 변경이 있다면 15개를 모두 고쳐야 한다는 뜻이다.
이것을 최소화 하기 위해 쓰이는 것이 공유 라이브러리다.
3. Jenkins Shared Libraries 구성
공유 라이브러리 프로젝트의 구조는 아래와 같다.
(root)
+- src # Groovy 소스 파일
| +- org
| +- foo
| +- Bar.groovy # for org.foo.Bar class
+- vars
| +- foo.groovy # 전역으로 foo변수 사용 가능
+- resources # 라이브러리 내부에서만 쓰이는 리소스들
| +- org
| +- foo
| +- bar.json # 정직 데이터
우리가 주목해야하는 부분은 vars 이다.
여기에 공통이 되는 빌드부분, 소나큐브 검사 부분, 도커 빌드 부분, 쿠버네틱스 배포 부분을 넣어서 나눠서 관리하면 된다.
(root)
+- vars
| +- applicationBuild.groovy # spring 빌드 관련 파이프라인 코드
| +- sonarQubeInspect.groovy # 소나큐브 검사 관련 파이프라인 코드
| +- dockerBuild.groovy # 도커빌드 관련 파이프라인 코드
| +- k8sDeploy.groovy # 쿠버네틱스 배포 관련 파이프라인 코드이런 식으로 구성이 가능하다.
이 중 하나의 파일(dockerBuild.groovy)의 코드 구성을 간략하게 보면 아래와 같다.
// dockerBuild.goovy
def call(string systemName, string repoUrl) {
def DOCKER_TAG = systemName.trim()
def DOCKER_REPO = ${env.BASE_REPO_URL}+"/"+repoUrl.trim()
sh"""
docker build -t ${DOCKER_TAG}
docker tag ${DOCKER_TAG} latest
docker push ${DOCKER_REPO}
"""
}
그리고 실제 Jenkinsfile에서는 아래와 같이 공유 라이브러리에 있는걸 불러다 쓰면 된다.
#!groovy
@Library('jenkins_library') _ //공유 라이브러리 import 부분, 젠킨스 설정에 있는 값
pipeline {
agent any
environment{
사용할 환경변수들
}
stages{
stage('clone'){
steps{
git clone // 이부분도 공유라이브러리로 모듈화 가능
}
}
stage('STEP1 : spring build'){
steps{
applicationBuild('systemName') // 공유라이브러리로 만든 groovy 파일이름 호출
}
}
stage('STEP2 : sonarQube inspect'){
steps{
sonarQubeInspect('systemName') // 공유라이브러리로 만든 groovy 파일이름 호출
}
}
stage('STEP3 : docker build'){
steps{
dockerBuild('systemName', 'respoUrl') // 공유라이브러리로 만든 groovy 파일이름 호출
}
}
stage('STEP4 : k8s deploy'){
steps{
applicationBuild('systemName', 'namespace', 'yamlPath') // 공유라이브러리로 만든 groovy 파일이름 호출
}
}
}
}
훨씬 간편해 졌다.
또한 공통되는 모듈이 중앙화 되었기 때문에 변화에 재빠르게 대응할 수 있게 되었다.
4. Jenkins Shared Libraries 사용을 위한 젠킨스 설정
젠킨스 공유 라이브러리 사용을 하려면 공유 라이브러리 프로젝트를 git에 레포를 하나 만들어서 올린다. 이후
젠킨스 설정에 들어가면 나오는 위와 같은 화면에서 해당 git 주소를 입력하고 Name 을 정하여 위 Jenkinsfile 코드의 맨 윗줄에 넣으면 사용할 수 있다.
'CICD' 카테고리의 다른 글
| [CI/CD Pipeline] docker BaseImage Pipeline 구축 (0) | 2022.10.23 |
|---|