클라우드 기반이 아무래도 편하다 보니까 AWS를 통해서 다양한 서비스들을 직접 띄우면서 작업하는 도중이었으나, 최근에 일과 개인적인 공모전 관련해서 AWS를 쓰기 힘든 상황이다 보니까 온프레미즈를 통해서 배포하기 시작했다. 아무래도 AWS를 쓰는 편이 편하기는 하지만, 비용적인 측면을 고려할 수밖에 없었고, 학교에서 일하게 되면서 서버 리소스들이 꽤나 많기 때문에 대부분 Jenkins를 기반으로 서빙하기 시작했다.
빌드의 꽃은 역시 매개 변수를 넣어주는 것이라고 생각한다. 도커 이미지를 만드는 과정에서도 다른 사람들의 스크립트를 보면서 저마다 도커 이미지를 빌드하는 방법이 다 다르다고 생각하였는데, 각각 다양한 이후의 확장성을 고려한 도커 파일을 작성하는 것이었다. 그렇기 때문에 이러한 젠킨스 빌드에서도 매개 변수등을 따로 두어 확장성을 크게 고려한 아키텍처를 만들 수 있을 것이라고 보아 관련된 레퍼런스를 조사하고 직접 실험해 보면서 관련 내용을 정리해 보았다.
본론
jenkins 실행
docker를 통해서 jenkins를 간단하게 실행할 수 있다. 아래의 쉘 스크립트를 그대로 실행하면 된다.
docker run -d --name jenkins \
-u jenkins \
-p 8080:8080 \
-p 50000:50000 \
-v jenkins_home:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
jenkins/jenkins:lts
이 과정에서 docker의 소켓을 볼륨으로 들고 가는데, 이는 jenkins의 도커 컨테이너에서 jenkins 컨테이너 위에 또 쌓아 올리는 게 아니라, 같은 레이어에 만들 수 있게 호스트의 docker 소켓을 볼륨으로 가져가게 설정한 것이다. 자세한 내용은 아래의 포스팅에서 다룬다.
- [marsboy]DinD vs DooD 그리고 DooD 설정법 : https://marsboy.tistory.com/50
[Jenkins] DinD vs DooD 그리고 DooD 설정법
들어가며최근 AWS 기반으로 CI/CD 파이프라인이 구축되어 있던 것을 온프레미즈로 옮기고 있기도 하고, 현재 일하는 곳에서 젠킨스를 이용한 CI/CD 파이프라인을 구축해야할 일이 있었다.젠킨스에
marsboy.tistory.com
Pipeline 생성
젠킨스의 대시보드에서 new item을 클릭하여 아래와 같이 파이프라인을 만들어줄 수 있다. 이번 포스팅에서 다룰 내용은 해당 파이프라인에서 쓰일 파라미터의 사용 및 활용 방법이기 때문에 해당 Pipeline을 선택하여 만들어준다.
파이프라인을 만들었다면, 아래와 같은 섹션을 확인할 수 있다. 이 빌드는 매개변수가 있습니다. 항목이 있는데, 눌러보면 아래와 같은 다양한 매개변수를 넣어줄 수 있다.
여러 가지 파라미터를 확인할 수 있다. Boolean, Choice, Credentials, File, Git, Multi-line String, Password, Run, String 등의 parameter들을 지정해 줄 수 있는데, 각각의 파라미터 사용 방법과 그 예시에 대해서 포스팅하려고 한다.
Parameters 설정
Boolean Parameter
pipeline {
agent any
parameters {
booleanParam(name: 'DEBUG_MODE', defaultValue: false, description: '디버그 모드 활성화')
}
stages {
stage('Example') {
steps {
sh 'echo "DEBUG_MODE는 ${DEBUG_MODE} 입니다."'
}
}
}
}
불리언 값을 설정해 줄 수 있는 파라미터로 대표적으로는 DEBUG_MODE를 False 및 True로 두어 기능을 껐다 켰다 할 수 있는 목적으로 사용한다.
Choice Parameter
pipeline {
agent any
parameters {
choice(name: 'BRANCH', choices: ['develop', 'master', 'feature'], description: '배포할 브랜치를 선택하세요')
}
stages {
stage('Checkout') {
steps {
sh 'echo "선택된 브랜치는 ${BRANCH} 입니다."'
git branch: "${BRANCH}", url: 'https://github.com/your-repo.git'
}
}
}
}
위는 choice parameter인데, 위와 같이 깃허브를 배포하는 경우에 브랜치를 나누어 배포하는 경우에 사용한다. production과 staging 서버를 나누는 데 특히 유용하게 사용할 수 있다.
참고로, 젠킨스파일에서의 choice 선택하는 부분에서 나열해주지 않고, 콘솔에서만 추가하는 경우 휘발성으로 다시 입력하면 사라지게 된다. 이는 이뿐만 아니라 다른 파라미터 설정에서도 비슷하게 작동하는 경우가 꽤나 있다.
Credentials Parameter
pipeline {
agent any
parameters {
credentials(name: 'CREDENTIALS_ID', description: '자격 증명을 선택하세요')
}
stages {
stage('Use Credentials') {
steps {
withCredentials([usernamePassword(credentialsId: "${CREDENTIALS_ID}", passwordVariable: 'PASSWORD', usernameVariable: 'USERNAME')]) {
sh 'echo "사용자 이름은 $USERNAME 입니다."'
}
}
}
}
}
Credentails Parameter는 보안을 위해 직접 노출되지 않는 파라미터 전달 방법이다. withCredentails 블록 내에서만 접근이 가능하다. 위의 + Add 버튼을 누르면 다양한 config key 등 보안과 관련된 키를 전달할 수 있게 된다.
File Parameter
pipeline {
agent any
parameters {
file(name: 'UPLOAD_FILE', description: '업로드할 파일을 선택하세요')
}
stages {
stage('Use File') {
steps {
sh 'echo "업로드된 파일 경로는 ${UPLOAD_FILE} 입니다."'
}
}
}
}
위와 같이 입력하는 경우 file location을 입력하기 때문에, UPLOAD_FILE과 같이 입력하는 경우에는 루트 디렉터리에 UPLOAD_FILE와 같이 파일이 업로드 되게 된다. 예를 들어 ./src/resources/.env 와 같이 위 디렉토리에 .env 라는 이름으로 만들고 싶다면 ./src/resources/.env를 입력해주어야 한다. 그리고 매번 빌드할 때마다 파일을 넣어 빌드하여야 한다.
Git Parameter
pipeline {
agent any
parameters {
gitParameter(name: 'GIT_BRANCH', type: 'PT_BRANCH', defaultValue: 'master', description: 'Git 브랜치를 선택하세요')
}
stages {
stage('Checkout') {
steps {
sh 'echo "선택된 Git 브랜치는 ${GIT_BRANCH} 입니다."'
git branch: "${GIT_BRANCH}", url: 'https://github.com/your-repo.git'
}
}
}
}
git parameter는 주로 브랜치와 Tag와 관련된 부분에 대해서 선택하여 배포할 수 있게 해 준다. 앞에서 본 choice parameter 또한 깃 브랜치에 맞춰 배포할 수 있으나, 이 파라미터는 보다 정교하게 git의 브랜치를 선택하여 배포할 수 있게 도와준다.
Multi-line String Parameter
pipeline {
agent any
parameters {
text(name: 'MULTI_LINE_TEXT', defaultValue: '', description: '여러 줄의 텍스트를 입력하세요')
}
stages {
stage('Use Text') {
steps {
sh 'echo "입력된 텍스트는 다음과 같습니다:\n${MULTI_LINE_TEXT}"'
}
}
}
}
위와 같은 경우에는 .env 파일이나 스크립트 내용 등의 여러 줄로 텍스트 입력을 설정하는 경우에 위와 같은 파라미터를 선택할 수 있다. 여기서 defaultValue가 ''으로 잡혀있는데, 저 부분을 따로 채워주지 않는 이상 jenkins에서 콘솔로 설정해 둔 파라미터를 망각하는 버그가 있다... 이는 수동으로 jenkins 파이프라인으로 배포하는 경우에 해당하기 때문에 웹훅으로 자동으로 파이프라인을 쏜다면 건드릴 필요가 없다.
Password Parameter
pipeline {
agent any
parameters {
password(name: 'SECRET', defaultValue: '', description: '비밀번호를 입력하세요')
}
stages {
stage('Use Password') {
steps {
sh 'echo "비밀 값이 입력되었습니다."'
}
}
}
}
Password 파라미터는 젠킨스파일 내에서 접근이 가능하지만 보안 상의 이유로 값을 출력하거나 로그에 남기지 않아야 하는 경우에 해당한다. API 키, 비밀번호 등 민감한 정보를 안전하게 입력해야 하는 경우에는 해당 파라미터를 사용한다.
Run Parameter
pipeline {
agent any
parameters {
run(name: 'UPSTREAM_BUILD', job: 'OtherJob', description: '이전 빌드를 선택하세요')
}
stages {
stage('Use Run') {
steps {
sh 'echo "선택된 빌드는 ${UPSTREAM_BUILD} 입니다."'
}
}
}
}
Run Parameter는 다른 job의 특정 빌드 결과를 참조하거나, 해당 빌드의 결과물을 사용할 때 쓰인다. 파라미터를 지정하는 콘솔에 대한 사진은 아래와 같다.
위와 같이 특정 job을 선택하여 빌드할 수 있는 기능을 제공한다.
마치며
요즘에는 젠킨스와 함께 많은 시간을 보내고 있는데, 꽤나 괜찮은 친구인 것 같다. jenkins의 활용 방법에 대해서 좀 더 하드하게 다뤄보고 싶은 마음이다.
'DevOps > On-premise' 카테고리의 다른 글
AWS에서 온프레미즈 Jenkins로의 여정 (5) | 2024.11.08 |
---|---|
Nginx Proxy Manager란? (1) | 2024.11.01 |