🔔 젠킨스 파이프라인을 활용한 배포 자동화

• 파이프라인을 활용하여 배포 자동화

 

📚 1. Jenkins 어떤 구조로 동작할까?

✔️ 현재 상황
프로젝트에 기능을 추가해서 base branch에 merge 되었다. 이제 실제 서버에 배포를 해야하겠다.

 

✔️ 팀프로젝트에서 많이 사용하는 work flow - 현재 매번 실행되어야 한다.

(1) 각 개발자가 기능을 구현한 후 PR (2) EC2 서버로 접속 (3) github에 merge된 코드를 git pull (4) gradle을 이용해 bootJar (5) jar 파일을 java -jar 명령어를 통해 80port에 실행한다.

=> 5가지를 매번 실행해야 한다. 귀찮지 않은가? Jenkins를 이용하면 해결할 수 있다.

 

💡 참고

• 서버 배포는 매번 기능이 추가될 때마다 시행되어야 한다.
• 현재 flow는 새로운 기능마다 바뀌는 것이 아니기 때문에, 자동화 할 수 있는 대상이다.

 

✔️ Continuous Distribution - 지속적 배포

flow를 자동화하여 최신 상태의 코드가 자동으로 배포되는 것

 

✔️ Jenkins가 해주는 것은?
Jenkins가 기능 구현을 해주지는 않는다.

Jenkins가 해주는 부분은?
(1) github으로부터 merge 되었다는 연락을 받아서
(2) 코드를 git clone하고
(3) gradle로 프로젝트를 build 하여
(4) build한 목적파일을 어플리케이션이 실행되어야 할 서버로 전달하고, 어플리케이션을 구동하기 위한 명령어를 실행한다.

 

✔️ Jenkins의 설정이 배포를 할때 어떤 부분을 자동화 해주는 걸까?

 

💡 참고
어플리케이션 서버에서 Jenkins를 구동할 경우, 빌드가 진행될 때마다 CPU 자원이 모자라서 서버가 다운되는 일이 있다.
이로 인해 별도 EC2로 분리하는 것이 좋다.
만약, 서버 자원이 모자라거나 여러 개의 WAS를 띄울 일이 생긴다면, 별도 환경으로 분리하는 것을 추천한다.

 

✔️ Ubuntu 초기설정(20.04)

sudo apt-get update
sudo apt-get install apache2
sudo apt-get install openjdk-11-jdk

 

Jenkins 설치 참고

• sudo cat ~/initialAdminPassword : 첫 설치시 필요한 password

 

💡 참고
sudo apt-get install openjdk-11-jdk : java 11 jdk 설치

 

📚 2. credentials 세팅

컴퓨터가 나 대신에 git clone을 하게 하려면 해당 레포지토리에 대한 권한이 필요하다!

 

💡 참고

• 공개 레포지토리에 있는 소스코드를 clone 하는 목적이라면 권한이 필요없기 때문에 따로 credentials를 설정하지 않아도 된다.
• PipeLine 상에서 push 또는 서브모듈 등 권한이 필요한 일이 있다면 credentials이 필요하다.

 

📖 A. access token 발급 및 test

• 시스템 설정

 

✔️ github repository 연결

• github 탭으로 이동, add 누른다.

- Secret text 선택, Secret(github token), ID는 아무거나

 

• test Connection이 발생할 경우 성공

 

✔️ credentials이 필요하다 (미리 생성하자)

• 시스템 설정의 github과 연관된 것은 credentials에 Secret text로 등록한 credentials만 인식한다.
• 지금은 Username with password 로 생성한 credentials이 필요하다.

 

✔️ 등록 혹은 확인 가능하다.

credentials는 추후 manage credentials에서 등록 혹은 확인이 가능하다.

 

 

📚 2. 파이프라인 생성하기

💡 참고

• 간단한 Job을 위해선 freestyle도 좋은 선택 (비교적 세팅이 단순)
• 복잡한 종류의 Job간의 연계나 상세한 세팅, UI (각 job별로 어떻게 진행되고 있는지 보여준다.)를 원한다면 파이프라인을 선택

 

✔️ pipeline script

pipeline script은 Groobee 또는 Jenkins에서 정의한 pipeline syntax를 통해 item에서 수행할 Job을 선언하고, 순서를 조정하고, 환경을 설정하는 역할을 한다.

PipeLine 공식문서

 

✔️ pipeline syntax

플러그인 별로 syntax를 만들어준다.

(1) pipe line은 이 파이프라인 자체를 의미한다.
(2) agent는 이 파이프라인 스크립트를 실행할 executor를 지정한다. any로 둘 시 어떤 executor도 실행할 수 있다는 의미가 된다.
(3) stages는 실행할 Job들의 집합이다.
(4) stage는 각각의 Job을 의미한다. Job 내부의 단계를 의미하는 steps를 포함해야한다.
(5) steps에선 실제로 실행할 쉘이나 syntax를 입력해주면 된다.

 

 

📚 3. Git Clone 하기

git clone 하기 위해서는 syntax를 만들어야 한다. (pipeline syntax를 클릭)

pipeline syntax -> snippet generate click

- git check

 

• repository url을 적어주고, branch를 선택하고, credentials를 넣어준다.
• 아까 추가하지 않았다면 지금 추가해준다.
• 공용 레포지토리를 clone하는 입장이라면 비워놓아도 된다.

 

• generate를 누르면 스니펫이 생성된다. 해당 내용을 복사하자!

 

- `stage` 이름을 원하는 이름으로 변경하고, `steps`에는 위에서 생성한 `snippet`을 붙여주면 된다. - **읽어보면, git 특정 브랜치에서 특정 `credentials`로 url의 레포지토리에서 소스를 가져오는 `snippet`이다.**

=> 이제 저장을 누르면, github을 clone 하는 job을 가진 파이프라인을 생성한 것이다.

 

💡 참고

• 한 번에 전체 job을 작성하면 trouble shooting이 힘들어지므로 각 단계별로 테스트 하자.
• 대쉬보드에서 생성한 아이템을 클릭하여 들어갑시다.

 

✔️ 이전까지 작업한 내용 테스트

- 수동적으로 build 할시, job을 유발한다. - 실행되어 Build History에 잘 들어간 것을 볼 수 있다.

 

✔️ 빌드 과정에서 출력되는 콘솔문은 console output 탭에서 확인할 수 있다.

- `pipeline` job의 진행 경과 및 `github clone`을 진행하며 입력된 명령어와 출력문들을 확인할 수 있다.

 

 

📚 4. Build

📣 시작하기전

• 빌드는(Build) clone해 온 소스에 포함되어 있는 gradle wrapper를 활용한다!
• 프로젝트에서 .gradlew 위치를 찾아야 한다.
• dir 스니펫 : cd
• sh ''' ${쉘 명령어} ''' : pipeline syntax에서 쉘 명령어를 실행하도록 설정하는 부분
• 현재 빌드를 위해 실행해야할 테스트 : clean, bootJar

 

pipeline {
    agent any

    stages {
        stage('github clone') {
            steps {
                git branch: 'main', credentialsId: 'repo-and-hook-access-token-credentials', url: 'https://github.com/ToDoStudy/study_jenkins'
            }
        }
        
        stage('build'){
            steps {
                dir('jenkins') {
                    sh '''
                        echo 'start bootJar'
                        ./gradlew clean bootJar
                    '''
                }
            }
        }
    }
}

 

✔️ 스니펫(snippet)
스니펫(snippet) : 재사용 가능한 소스 코드, 기계어, 텍스트의 작은 부분을 일컫는 프로그래밍 용어

• dir : cd
• stages : 실행할 Job들의 집합
• stage : 각각의 Job을 의미

 

✔️ build 결과(실패)

- 현재 서브 모듈을 init하고 update하지 않는다!

현재 실패한 결과를 얻게 되었다. 이유는?
코드를 빌드할 때 서브모듈이 필요한데, 해당 내용을 고려하지 않았기 때문이다. (만약에, 서브 모듈이 없었다면 성공이다!)

git plugin snippet은 서브 모듈의 init과 update까지 지원해주지 않는다.

=> 이렇게 생성한 syntax가 원하는대로 동작하지 않는다면 다른 step을 찾거나, 공식문서를 통해 원하는 설정이 있는지 확인해야 한다.

 

✔️ 서브모듈까지 받아오기 위해 다른 step syntax을 활용해보자

서브 모듈까지 받아오기 위해서는 다른 step syntax을 활용해보자!
checkout으로 검색하여 해당 simple step을 선택한다.
private repository로 등록한 서브모듈을 받아오기 위한 여정이므로! credentials를 세팅해준다.

 

- `pipeline syntax`에서 `additional behaviours`의 add 버튼을 클릭한 후, `Advanced sub-modules behaviours`를 눌러 위와 같이 설정해준다. - `Generate Pipeline Script`을 눌러서, 부모 레포지토리의 `credentials`를 그대로 활용한다.

 

- 생성한 `pipeline script`를 steps 하위에 붙여넣어서 **기존의 `git syntax`를 대체해준다.** - 서브 모듈 관련 명령어가 추가되었다.

 

✔️ 현재까지의 파이프라인

pipeline {
    agent any

    stages {
        stage('github clone') {
            steps {
                checkout scmGit(branches: [[name: '*/main']], extensions: [submodule(parentCredentials: true, reference: '', trackingSubmodules: true)], userRemoteConfigs: [[credentialsId: 'repo-and-hook-access-token-credentials', url: 'https://github.com/ToDoStudy/study_jenkins']])
            }
        }
        
        stage('build'){
            steps {
                dir('jenkins') {
                    sh '''
                        echo 'start bootJar'
                        ./gradlew clean bootJar
                    '''
                }
            }
        }
    }
}

 

✔️ 테스트 결과

처음에는 3시간 정도 기다려도 빌드에서 오류가 발생했었다. (이는 가상메모리 ec2 메모리 크기가 1GB 이기 때문이다.) 해결책 : EC2 메모리 크기 1GB + 2GB 추가

 

 

📚 5. ssh를 이용하여 서버로 jar 파일 전달하기

이제 배포용 Jenkins에서 WAS용 EC2로 Build 결과 파일을 전달해야 한다.
이를 위해서는 Publish over ssh 플러그인을 활용해주면 된다.

✔️ 플러그인 추가

• ssh를 통해 파일을 보내기전에, pem키의 정보가 필요하다.
• EC2에 접속할 수 있는 pem키의 내용을 얻어온 후, 내용을 복사한 후, EC2 접속에 필요한 pem키의 내용을 사진 key에 붙여넣어 준다.

`Name` : syntax에서 참조할 수 있는 이름 `HostName` : 빌드된 파일을 전송할 서버의 private ip (같은 vpc에 속해있어 private ip로 접근할 수 있다.) `username` : ubuntu(default) `Remote Directory` : 파일이 도착할 디렉터리를 적어준다. (ec2 가상서버에서 생성한 디렉터리로 해줘야함 아니면, `jenkins.plugins.publish_over.bappublisherexception` 발생) 현재는 `/home/ubuntu`로 변경

 

💡 참고
(Ubuntu22버전 사용할 경우 jenkins.plugins.publish_over.bappublisherexception: failed to connect and initialize ssh connection. message: failed to connect session for config 와 같은 오류를 만날 수도 있으니 Ubuntu20.04.5 사용하기를 권장한다.) -> 내가 경험한 오류

 

 

📖 A. snippet을 만들어보자! - sshPublisher simple step

• ssh Server 설정에서 선언한 name을 넣어준다. (원래 자동으로 들어간다.)
• Source files : 소스파일의 위치, gradlew wrapper에서 빌드 결과물을 build/libs/로 위치하므로, build/libs/*.jar 로 작성하였다.
• Remove prefix : 소스파일에서 원본파일의 디렉터리를 어디까지 포함할 것인지에 대한 설정
• remote directory : 배포될 경로를 적는다. 배포 서버의 해당 폴더로 목적파일이 도착하게 된다. (디렉터리 미리 만들어야 한다.)
• Exec command : 전송을 마치고 실행할 shell 문의 디렉터리 및 파일 위치이다.

 

✔️ 프로젝트에서 제공하는 배포 쉘

echo "> pid 확인"
CURRENT_PID=$(ps -ef | grep java | grep D208 | grep -v nohup | awk '{print $2}')
echo "$CURRENT_PID"
if [ -z ${CURRENT_PID} ] ;then
	echo "> 현재 구동중인 애플리케이션이 없으므로 종료하지 않습니다."
else
	echo "> sudo kill -9 $CURRENT_PID"
	sudo kill -9 $CURRENT_PID
	sleep 10
fi
echo "> jujeol 배포"
JAR_PATH=$(ls -t /home/ubuntu/D208-Project/deploy/*.jar | head -1)
sudo nohup java -jar ${JAR_PATH} >> /home/ubuntu/D208-Project/logs/D208.log &

• CURRENT_PID=$(ps -ef | grep java | grep D208 | grep -v nohup | awk '{print $2}') : CURRENT_PID에 현재 실행되고 있는 프로젝트의 pid를 받아온다.
• 쉘을 작성하기 전 직접 서버를 실행하고 해당 명령어를 입력해서 pid를 잘 잡아오는지 확인한다.
  • ps -ef | grep java | grep D208 | grep -v nohup | awk '{print $2}'
• CURRENT_PID가 있다면 먼저 종료한다. (셧다운 시간이 있기 때문에 sleep을 해준다.)
• 종료가 끝나면 deploy 폴더에서 마지막 jar을, 80port에 dev 프로필로 실행한다.

 

📝 리눅스 2>&1 그리고 /dev/null
참고 : https://inpa.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-devnull-%EB%A6%AC%EB%8B%A4%EC%9D%B4%EB%A0%89%EC%85%98-%EA%B8%B0%ED%98%B8-%EC%A2%85%EB%A5%98
(1) 2>&1

(2) /dev/null

• /dev/null로 결과를 보낸다는 것은, 데이터를 죄다 말끔히 없애버려서 깔끔하게 화면에 표시하지 않는다는 것을 말한다.
  

 

• Generate Pipeline Script클릭을 통해 발급 받는다.
• snippet을 stage로 만들어보자.
• sshPublisher 같은 경우 verbose 옵션이 있는데, 해당 옵션을 true로 주면 트러플 슈팅시 유용하다. 빌드의 console output에 해당 내용이 상세히 찍힌다. (true 줄 시, 디벅)

 

현재까지의 파이프라인

pipeline {
    agent any

    stages {
        stage('git clone') {
            steps {
                checkout scmGit(branches: [[name: '*/main']], extensions: [submodule(parentCredentials: true, reference: '', trackingSubmodules: true)], userRemoteConfigs: [[credentialsId: 'repo-and-hook-access-token-credentials', url: 'https://github.com/ToDoStudy/study_jenkins']])
            }
        }
        
        stage('build'){
            steps {
                dir('jenkins') {
                    sh '''
                        echo 'start bootJar'
                        ./gradlew clean bootJar
                    '''
                }
            }
        }
        
        stage('publish on ssh'){
            steps{
                dir('jenkins'){
                    sshPublisher(publishers: [sshPublisherDesc(configName: 'ECGumD208', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: 'sh /home/ubuntu/D208-Project/script/init_server.sh', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '/D208-Project/deploy', remoteDirectorySDF: false, removePrefix: 'build/libs', sourceFiles: 'build/libs/*.jar')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: true)])
                }
            }
        }
    }
}

 

✔️ 성공적으로 실행되었는지 파일 확인

• 성공적으로 실행된 결과다. (EC2 콘솔에서 ps -ef | grep java 명령어를 통해 구동이 잘되었는지 확인한다.)
• 다만, 실행하다 2분뒤 종료된다. 그전까지는 업로드가 계속 진행중이었다.

=> 이제 Jenkins 웹 콘솔에 접속해 build now를 누르면 프로그램을 자동 배포할 수 있는 발판을 마련했다!

 

 

📚 6. 빌드 유발하기

✔️ github에서 제공하는 webhook

• 특정한 이벤트가 발생했을 때, 해당 내용을 등록해놓은 api로 보내주는 기능이다.
• 이 기능을 활용하여 github에서 특정한 활동이 일어났을 때 job이 유발되도록 구현할 수 있다.

=> 이를 적용해보기 위해 PR이 merge될 때 자동으로 빌드가 일어나도록 설정해보자!

 

💡 참고
Github hook trigger for GITScm polling 옵션은 freestyle에서 build trigger로 많이 사용했었다.
하지만, pipeline에서는 제대로 동작시키기 어렵고 디테일한 세팅을 할 수 없다는 단점이 있다.

 

✔️ 백엔드 PR merge에만 Jenkins가 동작하도록 만들어보자!

어떻게 하면 될까?

=> Pull Request의 라벨을 바탕으로 백엔드와 프론트엔드 PR을 구분하도록 해보자!
=> 백엔드 라벨이 붙어 있는 PR이 머지 되었을 때만 빌드가 일어나도록 해보자!

 

✔️ Generic Webhook Trigger 플러그인 설치

 

파이프라인의 상세내용에서 build triggers로 이동하면, generic webhook trigger가 추가된 것을 볼 수 있다.

라고 했지만, 일단은 시간이 없어

Github hook trigger for GITScm polling 을 사용했다. (추후 변경될 예정)

 

 

---

참고

• https://velog.io/@sihyung92/%EC%9A%B0%EC%A0%A0%EA%B5%AC2%ED%8E%B8-%EC%A0%A0%ED%82%A8%EC%8A%A4-%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%9C-%EB%B0%B0%ED%8F%AC-%EC%9E%90%EB%8F%99%ED%99%94