이번 게시글에서는 Jenkins Pipeline을 작성하고 우리가 Pipeline을 실행시키는데 필요한 여러 데이터들을 넣어 볼 것이다.
주의!
필자의 현재 진행 환경이 AWS에서 Vultr로 변경되었음을 알려 드립니다. 다만 진행하는 모든 과정을 AWS에서 이미 한 번 해보았고 해당 과정을 완벽하게 그대로 진행했음을 알려 드립니다.
글을 작성하는 지금 실행 환경은 다음과 같습니다. Ubuntu LTS 24.04
Jenkins Pipeline 작성하기
다시 메인메뉴로 돌아온다. 우측에 초록 원에 있는 Create a job을 클릭한다.
Jenkins는 여러 아이템들을 추가해 놓을 수 있는데 우리는 여기에서 Pipeline을 사용할 것이다. Pipeline을 클릭하고 제목을 적당히 지어준 후 OK를 누르면 Jenkins Pipeline이 완성된다.
만들게 되면 다음과 같은 Pipeline 설정 페이지로 이동하게 되는데 지금 우리가 주목할 곳은 맨 아래쪽의 스크립트이다.
Jenkins Pipeline은 agent, tools, stages 과 같은 속성들로 구성된다.
tools의 maven은 maven을 사용할 건데 이름이 "M3"인 maven을 사용할 것이라는 의미이다.
stages는 Jenkins Pipeline의 단계들을 의미한다. 각 내부의 stage는 Pipeline의 각 단계를 정의하며 이 stage는 다시 하나 또는 여러개의 steps으로 나뉘게 된다.
이 steps에 jenkins가 해당 스텝에서 진행해야 할 동작(Behavior)를 정의한다.
우리는 다음과 같은 스크립트를 사용할 것이다.
pipeline {
agent any
tools {
maven "M3" // Jenkins에서 설정한 Maven의 이름
}
stages {
stage('Checkout') {
steps {
git url: '[배포할 github repository 주소]', branch: '[배포시킬 branch]'
}
}
stage('Copy application.properties') {
steps {
withCredentials([file(credentialsId: 'SECRETFILE', variable: 'properties')]) {
script {
sh '''
rm -f src/main/resources/application.properties
cp $properties src/main/resources/application.properties
'''
}
}
}
}
stage('Build') {
steps {
script {
sh 'mvn clean package'
}
}
}
stage('Deploy') {
steps {
script {
// 원격 서버에서 애플리케이션 실행
sshagent(['deploy_ssh_key']) { // 'server-ssh-credentials'는 Jenkins에서 설정한 credentials ID
sh 'ssh -o StrictHostKeyChecking=no ubuntu@[server instance public ip]'
sh 'scp /var/jenkins_home/workspace/[jar file path] ubuntu@[server instance public ip]:/home/ubuntu/project/'
sh 'ssh -tt ubuntu@[server instance ip] sh ./deploy.sh'
}
}
}
}
}
post {
success {
echo 'Deployment was successful.'
}
failure {
echo 'Deployment failed.'
}
}
}
처음 보면 모르는 것들이 많을 것이다. 하지만 하나씩 하나씩 해보면 충분히 이해하고 진행할 수 있을 것이다.
먼저 Checkout 단계부터 보도록 하자.
url에는 여러분이 배포하려고 하는 깃허브 레포지토리 주소를 넣어주면 된다.
branch는 해당 깃허브 레포지토리에 어느 branch를 사용할 것인지를 지정하는 속성이다. 예를 들어 회사나 규모가 있는 프로젝트에서 배포를 한다면 일반적으로 production 브랜치 같은 것을 사용할 것인데 그렇다면 branch에 production이라고 적어주면 될 것이다.
우리는 우선 main 브랜치를 기준으로 배포할 것이기 때문에 main이라고 적어놓을 것이다.
Copy application.properties는 application.properties 또는 application.yml 파일을 복사하여 넣어주는 단계이다.
필자는 Spring Boot를 사용하여 서버를 구성하였으며 해당 프레임워크에서 설정 파일의 이름이 application.properties이다.
해당 파일에 DB의 Connection URL이나 유저, 비밀번호와 같은 민감한 정보들이 들어가기 때문에 해당 파일은 일반적으로 github에 public하게 올라가면 안된다. 그래서 .gitignore같은 파일에 미리 해당 파일을 제외하도록 설정을 해 놓는다.
그렇다면 서버가 실행이 될 때 application.properties 파일이 필요한데 이를 Jenkins에서 가지고 있다가 넣어줄 수 있다. 해당 부분이 application 파일을 넣어주는 역할을 한다.
Build는 말 그대로 빌드를 수행한다. 이때 테스트 코드를 작성했다면 테스트가 동작하게 된다.
Deploy 단계는 이제 빌드되어 jar파일을 서버 EC2에 복사해 넣고 실행시키는 역할을 맡는 단계이다. 해당 단계가 종료되면 배포 과정이 모두 끝나게 된다.
세부 설정
Maven 설정하기
맨 위의 tools에서 maven M3이라고 한 것을 보았는데 우리는 M3이란 이름을 지정해 준 적이 없다. 이것은 우리가 Jenkins에서 설정해줄 수 있다.
Dashboard에서 Jenkins 관리로 들어가자
Tools에 들어가면 다음과 같은 페이지가 나온다.
여기에는 tools에 있는 여러 툴들을 설정하고 정의해줄 수 있는 공간인데 우리가 관심있는 부분은 아래의 Maven installations이다.
Add Maven을 누른다.
Maven의 이름과 installer를 지정해줄 수 있는 부분이 열리게 된다. 여기서 우리가 이름을 설정해 주면 tools에서 해당 이름으로 installer를 가져와 실행하는 것이다.
그러면 해당 installer를 가져와 실행하고 maven이 설치되게 된다. 그렇다 우리는 여기에서 M3의 이름을 가진 maven installer를 넣어주면 된다.
버전의 경우 필자는 3.9.7을 사용하였다.
이후 save을 누르면 정상적으로 저장된 것을 확인할 수 있다.
Secret File 설정
Jenkins에는 특정 파일을 보안을 유지하면서 넣을 수 있는 Secret File을 지원한다. 만약 여러분의 프로젝트 레포지토리에 application.properties가 public하게 저장되어 있다면 해당 부분을 스킵해도 된다.
application.properties와 같은 중요 설정 파일들을 github에 public하게 노출시키는 것은 많은 문제가 발생할 수 있다.
만약 여러분의 AWS S3 access-key가 무분별하게 노출된다면 돌아오는 것은 몇 천 달러의 사용료가 될 수 있다. 가급적이면 application.properties, application.yml과 같은 민감한 데이터가 있는 설정 파일들은 .gitignore를 통해 누락시킬 수 있도록 하자.
사족으로 github action을 사용할 경우 저런 설정 파일을 반드시 git에 올려야 할 경우가 생기게 되는데 이 경우에는 git의 submodule를 사용하여 해결할 수 있으니 참고하자.
다시 Jenkins Dashboard로 돌아가 Jenkins 관리로 들어가자.
이번에는 Credentials로 들어간다.
Jenkins에서 저장하는 비밀 파일이나 데이터들은 Credentials로 지정된다. 여기서 global을 클릭하면 아래와 같은 페이지로 넘어간다.
여기서 add credentials를 누른다.
그럼 credentials를 넣는 form이 뜨는데 kind는 우리는 secret file을 사용할 것이므로 secret file을 지정한다.
Scope는 전역에서 사용하도록 한다.
File은 여러분들의 application.properties 또는 yml과 같은 설정 파일을 찾아서 넣어준다.
ID는 withCredentials([file(credentialsId: 'SECRETFILE', variable: 'properties')]) 에서 credentialsId로 되어 있는 id를 의미한다. 여기에선 SECRETFILE로 되어 있으므로 그대로 따라해준다.
Description은 해당 파일에 대한 설명이므로 넣어줘도 되고 넣지 않아도 된다. 이후 Create를 눌러주면 된다.
마치며
여기까지 진행하면 Deploy를 제외한 나머지 step들은 모두 완성이 되었다. Deploy를 주석으로 처리하고 한 번 실행해 보도록 하자.
여러분의 파이프라인에서 지금 빌드 라고 되어 있는 부분을 클릭하면 Pipeline이 동작을 수행한다.
우리가 stage view plugin을 설치한 덕분에 각 step들이 어떻게 처리되고 있는지를 확인할 수 있다.
만약 해당 부분에서 문제가 발생했다면 빨간색으로 점멸하게 된다. 그 경우에는 Build History로 들어가서 로그를 확인해볼 수 있다.
여기서 Console Output을 클릭하면 왜 실패했는지에 대한 메시지를 확인할 수 있으므로 디버깅할 때 참고하면 될 것이다.
필자는 현재 모든 단계가 정상적으로 진행되었음을 확인할 수 있다. 다음 포스트에서는 배포 단계인 Deploy를 확인해볼 것이다.
