[CI/CD] Git Webhook 을 통한 Jenkins-Spring Boot 빌드, 배포 자동화

이전 포스트 에서는 Docker 위에서 Jenkins 개발환경을 셋팅하였다.

 

본 포스트에서는 실제로 Jenkins project 를 생성하여 빌드 스크립트를 구축하고

 

Git Webhook 을 이용해 개발자가 빌드 버튼을 매번 누르는 것이 아닌 Github 의 develop 브렌치에 push 되었을 때 빌드가 되도록 자동화를 할 생각이다

백엔드 시스템 아키텍쳐

프로젝트에서 백엔드의 개략적인 시스템 아키텍쳐가 나왔다.

 

초기 AWS 를 사용할 예정이였으나 최근 GCP 에서 제공하는 쿠버네티스 엔진을 이리저리 만져보다가 프로젝트 2차 챌린지로 쿠버네티스 환경 구축을 하면 좋을 것 같아서 사전에 플랫폼에 좀 친숙해지기 위해서 GCP 로 배포하기로 마음먹었다.

 

실제로 이전 포스팅 의 환경 또한 현재 GCP VM 에 구축한 상황이다.

 

시스템 아키텍쳐

위 시스템 아키텍쳐의 타임라인에 대해 간단하게 요약하자면 아래와 같다.

1. 개발자가 develop 브렌치에 push 를 한다.

2. GitHub Webhook 을 Jenkins 에게 전달한다.

3. Webhook 을 받은 jenkins project 는 빌드를 진행한다.

4. 빌드과정 (Jenkins 가 하는 일)

     - 타겟 repo 를 pull 한다.

     - 현재 위치(repo root) 에서 gradle build 를 수행한다.

     - docker build 를 수행한다. (spring boot image 생성)

     - docker run spring-boot-image 를 수행한다

 

위와 같이 젠킨스 컨테이너 내부에서 docker 명령어를 수행해야하기 때문에 일전에 컨테이너 내부에서도 docker 를 설치했다.

 

같은 호스트 머신에서 젠킨스와 스프링 부트 서버 컨테이너를 동시에 띄운 이유는 아래와 같다

 

1. 서로 다른 머신에 Jenkins, SpringBoot 를 띄우면 추가적으로 ssh 연결을 통해서 배포가 트리거 되어야하는데, 당장의 규모가 작은 프로젝트에서 해당 환경을 셋팅하는데 들어가는 시간이 너무 길 것 같아서 최대한 간략한(확장 가능한) CI/CD 환경을 셋팅했다. 서로 다른 머신을 이용한 환경은 2차 챌린지로 넘길 예정이다.

 

2. VM 한대 추가할 때 마다 비용이...

Jenkins Project 생성

1. 새로운 Item 추가 버튼으로 Freestyle project 를 생성한다.

2. Jenkins 가 빌드작업을 시작할 프로젝트의 GitHub 주소를 명시한다.

[Git Access Token name]:[Access Token]@GitHub 저장소 주소.git 을 적는다.

 

Private repo 의 경우에는 AccessToken 이 있어야만 접근 가능하기 때문에 위와 같은 방법 혹은

Credentials 을 별도로 생성해서 git Username-Access Token 을 기입하도록 한다.

 

3. 빌드할 브렌치 경로를 기입한다.

 

4. 해당 프로젝트는위에서 명시한 GitHub 프로젝트 경로와 일치하는 경우에  GiHub Webhook 을 받는다는 것을 의미하고, 사전에 젠킨스에 설치한 GitHub Plugin 은 프로젝트의 변경사항을 감지하고, 빌드를 수행한다는 것을 의미한다.

 

5. 해당 섹션에서는 젠킨스가 프로젝트를 불러오고 나서 프로젝트의 루트 경로에서부터 수행하는 명령을 명시한다.

따라서 Execute shell 을 통해 직접 커맨드를 추가한다.

 

# SpringBoot 프로젝트를 jar 파일로 빌드한다.
./gradlew clean build

# jar 파일을 포함하여 SpringBoot image 를 생성한다.
docker build -t username/spring-boot:1.0 .

# 기존에 동작중인 container 의 id 를 찾고, 존재하면 container 를 내린다.
docker ps -q --filter "name=spring-boot-server" | grep -q . && docker stop spring-boot-server && docker rm spring-boot-server | true

# 위에서 생성한 SpringBoot 이미지를 구동시킨다.
docker run -p 8081:8080 -d --name=spring-boot-server username/spring-boot:1.0

# 태그가 겹친 이미지는 tag 가 none 이 되므로 해당 이미지들을 삭제한다.
docker rmi -f $(docker images -f "dangling=true" -q) || true

 

각각의 커맨드는 따로따로 Execute shell 로 추가해도 되고, \ 를 이용해서 한꺼번에 수행해도 되지만

 

개인적으로 각각 추가했을 때 Jenkins Console 에서 보기 편해서 각각 추가해줬다

 

 

Jenkins 수동 Build 

생성한 Jenkins 프로젝트에 들어가서 좌측의 지금 빌드를 클릭하면 성공적으로 빌드가 되는 것을 알 수 있다.

오류가 날 시 젠킨스 빌드 console 을 보면 상세 오류정보를 알 수 있다.

 

개인적으로 실수했던 것은

1. project 경로.git 설정 및 branch 이름 설정

2. credential 이 필요한 private repo

 

등등을 다시 체크하며 오류를 고쳐보자

 

GitHub Webhook 을 통한 CI/CD 완성

위 단계까지 진행한 것은 "젠킨스를 통한 빌드/배포 자동화" 이고, 젠킨스를 통해 직접 빌드 버튼을 누르는게 아닌 Github 에 특정 Action 을 통해서 젠킨스의 빌드 버튼을 트리거링 하는 방법을 알아보려고 한다.

 

위와 같은 GitHub Webhook 을 통한 자동 빌드-배포 시스템을 구축해놓으면, 개발자들은 단순히 repo 에 코드를 올리기만해도 자동으로 서버에 반영되는 효과를 느낄 수 있다.

 

Webhook 설정은 GitHub 프로젝트의 Settings 메뉴에서 생성할 수 있다.

 

 

1. Add Webhook 을 선택하고

[Jenkins server uri]:[port num]/github-webhook/ 을 Payload URL 에 기입한다.

 

jenkins server 에 webhook 을 triggering 하는 경로를 의미하고, application/json 타입의 데이터를 전송해야한다.

 

2. GitHub project 에서 언제 Webhook 을 날리는가에 대한 설정인데, 우선은 push 이벤트에 대해서만 설정한다.

 

3. 이제 실제로 repo 의 master(개인이 설정한 브렌치 이름) 에 push 를 하면 젠킨스가 빌드 및 배포를 수행하는 것을 확인할 수 있다.