먼저 Jenkins 파이프라인의 실행 결과에 대한 메시지를 받아보기 위해 Slack에서 사용할 워크스페이스와 채널을 생성해준다.
워스크페이스와 채널을 생성하고나면 https://YOUR_WORKSPACE.slack.com/apps URL에 접속해서 Slack에 추가 할 앱으로 Jenkins CI를 검색한다.
 |
|---|
| [그림 1] Jenkins CI 앱 추가 |
Slack에 추가 버튼을 누르고 앞서 생성해둔 채널을 선택하여 해당 채널에서 Jenkins의 메시지를 받아 볼 수 있도록 설정한다.
 |
|---|
| [그림 2] Jenkins CI 구성 편집 |
정상적으로 Jenkins CI 앱이 추가되면 구성 탭을 눌러 구성 편집에 들어가면 위의 [그림 2]와 같은 화면을 볼 수 있다.
아래쪽에 보면 토큰이 발급되어 있는 것을 볼 수 있을텐데, 이 토큰은 나중에 Jenkins credentials을 생성할 때 사용된다.
여기까지 설정했다면 Slack에서의 설정은 끝난 것이다.
다음으로 Jenkins에서 Slack과 연동하는 방법을 알아보겠다.
먼저 Jenkins 설정에서 Slack 플러그인을 설치해준다.
 |
|---|
| [그림 3] Slack 플러그인 설치 |
Jenkins에서 Slack 플러그인을 설치하고나면 시스템 설정 탭의 맨 아래쪽에 Slack 설정 공간이 있다.
다음 [그림 4]와 같이 워크스페이스와 Credentials, 채널 ID를 정확하게 기입해준다.
 |
|---|
| [그림 4] Jenkins에서 Slack 설정 |
Credentials의 경우에 옆의 Add 버튼을 눌러 Slack의 Credentials를 추가할 수 있다.
Credentials를 추가할 때 Kind는 Secret text로 두고 Secret은 [그림 2]에서 보이는 토큰 값을 입력해준다.
그런 우측 하단의 Test Connection 버튼을 눌러 정상적으로 연동되어 Success 문구가 뜨는지 확인한다.
Jenkins와 Slack이 정상적으로 연동되고나면 다시 파이프라인으로 돌아와서, 파이프라인이 모두 실행되고나서 Slack에 메시지를 보내는 테스트를 진행해보겠다.
파이프라인 스크립트는 아래의 내용을 앞선 포스트에서 사용했던 스크립트에 추가했다.
pipeline {
environment {
SLACK_CHANNEL = '#send-slack-message-from-jenkins'
}
...(중략)
post {
success {
slackSend (channel: SLACK_CHANNEL, color: '#00FF00', message: "SUCCESSFUL: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
}
failure {
slackSend (channel: SLACK_CHANNEL, color: '#F01717', message: "FAILURE: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
}
}
}
파이프라인을 모두 실행하고 나서 파이프라인이 성공 혹은 실패 상태인지 확인하여 상태에 맞게 Slack 메시지를 보내도록 작성했다.
성공하면 ‘SUCCESSFUL’이라는 문구와 함께 초록색으로 메시지가 전달될 것이고, 실패하면 ‘FAILURE’이라는 문구와 함께 빨간색으로 메시지가 전달될 것이다.
다음 [그림 5]는 파이프라인이 정상적으로 실행되어 Slack으로 메시지가 전달 되었을 경우이다.
 |
|---|
| [그림 5] Slack 메시지 확인 |
이번에는 Jenkins에서 멀티 브랜치 파이프라인을 설정하는 방법을 알아보자.
먼저 Jenkins 시스템 설정에서 다음 [그림 6]과 같이 GitLab 서버에 대해 설정해야 한다.
 |
|---|
| [그림 6] Jenkins에서 GitLab 서버 설정 |
그런 다음 Jenkins 홈에서 왼쪽 탭의 새로운 Item에서 Multibranch Pipeline을 생성해준다.
멀티 브랜치 파이프라인을 만들 때 Branch Sources 항목에서 Add Source -> GitLab Project를 눌러 다음 [그림 7]과 같이 설정해준다.
 |
|---|
| [그림 7] 멀티브랜치 GitLab 설정 |
Server는 [그림 6]에서 정상적으로 설정했다면 자동으로 잡혀있을 것이고, Credentials는 CI 설정할 때 만들어두었던 것을 그대로 사용해주시면 된다.
그리고 파이프라인에 연결할 프로젝트를 생성한 계정의 ID를 Owner로 두면 해당 ID에서 관리하고 있는 프로젝트들을 아래 Projects에서 선택할 수 있다.
Behaviours 항목에서 Add 버튼을 눌러 Filter by name (with wildcards)를 생성해주고, 위에서 선택한 프로젝트에서 파이프라인을 실행할 브랜치들의 이름을 Include에 적어두면 된다.
멀티 브랜치 파이프라인은 각 브랜치들에 Jenkinsfile을 생성하여 Jenkinsfile에서 스크립트를 작성해두어야 한다.
master 브랜치에서는 CI/CD 파이프라인이 모두 동작하여 빌드부터 배포까지 모두 진행되도록 그대로 두었고,
release 브랜치에서는 CI 파이프라인만 동작하도록 아래와 같이 작성했다.
pipeline {
environment {
registry = "crisis513/flask-app"
registryCredential = 'crisis513'
dockerImage = ''
releaseName = "flask-app"
helmChartRepo = "flask-kubernetes-helm"
release_version = 'latest'
SLACK_CHANNEL = '#send-slack-message-from-jenkins'
}
agent {
label "jenkins-slave"
}
stages {
stage('Cloning our Git') {
steps {
git 'http://GITLAB_SERVER_IP:8001/root/flask-app.git'
}
}
stage('Building docker image') {
steps {
script {
dockerImage = docker.build registry + ":${release_version}"
}
}
}
stage('Deploy docker image') {
when {
branch 'master'
}
steps {
script {
docker.withRegistry( '', registryCredential ) {
dockerImage.push()
}
}
}
}
stage('Cleaning up') {
when {
branch 'master'
}
steps {
sh "docker rmi $registry:${release_version}"
}
}
stage('Deploy image to kubernetes') {
when {
branch 'master'
}
steps {
sh """
helm lint ${helmChartRepo}
helm upgrade ${releaseName} ${helmChartRepo}
"""
}
}
}
post {
success {
slackSend (channel: SLACK_CHANNEL, color: '#00FF00', message: "SUCCESSFUL: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
}
failure {
slackSend (channel: SLACK_CHANNEL, color: '#FF0000', message: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
}
}
}
release 파이프라인을 실행시켜 정상적으로 동작하면 다음 [그림 8]과 같은 화면을 볼 수 있다.
 |
|---|
| [그림 8] release 브랜치 파이프라인 테스트 |
Git clone하여 도커 이미지를 빌드하는 부분까지는 정상 동작하지만 도커 이미지를 배포하고 쿠버네티스 클러스터에 배포하기까지의 과정은 master 브랜치에서만 동작하도록 설정하였기 때문에 생락된 것을 확인할 수 있다.
다음 포스팅에서는 지금까지 설정해 둔 DevOps 파이프라인에서 SAST(Static Application Security Testing)를 적용하여 자동으로 정적 테스트를 거쳐 배포할 수 있는 방법을 기술해보겠다.