Chapter4 - 배포 자동화와 협업을 위한 Git 사용(GitHub Webhook, Jenkins로 배포 자동화)

• 안녕하세요~ 이전에 운영하던 블로그 및 GitHub, 공부 내용을 정리하는 Study-GitHub 가 있습니다!

• 네이버 블로그

• GitHub

• Study-GitHub

• 🐔

---

✔ CLASS101 백엔드 시스템 실무 - Chapter4 배포 자동화와 협업을 위한 Git 사용

안녕하세요, 클래스101 백엔드 시스템 실무 강의를 듣고, 복습 차원으로 정리하여 남기려고 합니다! 혹시 문제가 된다면 글을 삭제하겠습니다 !!

 

class101.net/products/5fc4a3b4fc231b000d85661b

현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무!

---

 

✔ GitHub Webhook과 Jenkins로 배포 자동화하기

class101.net/products/5fc4a3b4fc231b000d85661b

위 그림의 과정은 다음과 같습니다.

1) CPU Bound 애플리케이션의 Repository에 Push 가 발생합니다.

2) Jenkins에서 해당 코드를 빌드합니다.

3) 그 후 Jenkins에서 GCP의 각 cpu 인스턴스(1, 2, 3) 으로 배포를 합니다.

 

 

 

github.com/lleellee0/cpu-bound-application

lleellee0/cpu-bound-application

먼저 위 Repository를 fork 받습니다.

 

 

 

Jenkins에 접속하여 프로젝트를 클릭하고, 구성을 클릭하여 소스 코드 관리에서 위의 부분들을 수정합니다.

• Repository URL - fork한 레포지토리의 URL

 

 

 

그 후 아래로 내려와서 Build 부분을 수정합니다.

Add build step에서 Exec shell 을 클릭하면 위와 같은 화면이 생성되는데요,

여기에 메이븐에서 jar 파일을 생성할 수 있는 명령어를 실행합니다.

./mvnw clean package

(Maven Lifecycle 참고)

 

 

 

위 과정이 끝난 뒤 저장을 하고 빌드를 진행하면 실패를 합니다.

 

 

 

로그를 확인해보면 ./mvnw의 Permission denied 로그가 찍힌 걸 볼 수 있습니다.

 

 

 

 

따라서 위와 같이 Jenkins의 구성에서 메이븐을 빌드하기 전, 권한을 부여하도록 Shell 명령어를 수정합니다.

chmod 544 ./mvnw

./mvnw clean package

 

 

 

저장을 한 뒤 Jenkins를 다시 빌드를하면 정상적으로 빌드가 되는데요,

현재 docker를 통해 빌드가 되었는데, 이걸 jar 파일로 빌드를 진행하도록 변경해보겠습니다.

 

 

 

 

위 로그 파일에서 target ~ 부터의 경로를 복사합니다.

target/cpu-0.0.1-SNAPSHOT.jar

 

 

 

 

그 후 Jenkins의 구성으로 돌아와서 빌드 후 조치 메뉴에서 위의 부분을 수정합니다.

    • Source files : 위에서 복사한 target ~ 

    • Remove prefix : target

    • Exec command : sudo java -jar cpu-0.0.1-SNAPSHOT.jar

 

아래 cpu-worker의 인스턴스 2, 3 에도 동일하게 설정을 합니다.

그 후 저장을 한 뒤 빌드를 진행합니다.

 

 

 

로그를 보시면 java라는 명령어를 찾을 수 없다고 나옵니다.

즉, cpu-worker의 인스턴스 1,2,3에는 docker만 설치했을 뿐 Java는 설치를 하지 않아서 발생하는 오류입니다.

 

 

 

 

세 개의 인스턴스에 아래 명령어를 통해 java를 설치합니다

$ sudo yum install -y java

(-y 명령어를 추가하면 중간에 y를 누르지 않아도 됩니다.)

 

그 후 다시 빌드를 진행합니다.

 

 

 

그럼 위와 같이 로그가 끝나지 않았다고 판단해서 빌드가 계속 진행되는데요, 일단 중지를 합니다.

 

 

 

Jenkins의 구성 부분에서 인스턴스1, 2, 3 모두 빌드 후 조치에서 Exec command를 수정합니다.

nohup sudo java -jar cpu-0.0.1-SNAPSHOT.jar > nohup.out 2>&1 &

 

그 후 저장을 하고 빌드를 진행합니다.

 

 

 

빌드를 진행하고 로그를 확인해보면 정상적으로 배포가 진행된 걸 확인할 수 있습니다.

 

 

 

현재 Nginx는 8080 포트로 띄어져있는데, 애플리케이션은 80 포트로 띄어져 있어서 문제가 있습니다.

따라서 애플리케이션의 포트를 8080으로 변경한 뒤 Push를 하고, 이를 자동 배포하도록 진행하겠습니다.

먼저 cpu-worker의 인스턴스에서 현재 실행중인 애플리케이션을 종료합니다.(인스턴스 1, 2, 3 모두 종료합니다.)

$ ps -aux | grep java

$ sudo kill -9 1974

$ sudo kill -9 25215

$ sudo kill -9 25227

$ sudo kill -9 1974 25215 25227 ==> 한 번에 종료하기

 

 

 

 

위 과정이 끝나면 GitHub로 와서 레포지토리 > Settings > Webhooks > Add webhook 를 클릭합니다.

 

 

 

 

Payload URL에 Jenkins의 URL/github-webhok/ 을 작성합니다.

Content type은 application/json 으로 수정합니다.

Just the push event - push event가 발생했을 때, Webhook(Payload URL) 호출

 

 

그리고 Add webhook 버튼을 클릭합니다.

 

 

 

 

위 GitHub의 Repository를 clone 받고 인텔리제이에서 실행하고, application.properties 파일에서

포트를 80 -> 8080으로 수정합니다.

 

그 후 add - commit - push 를 진행합니다.

 

Push를 하면 Jenkins에서 빌드가 진행이 됩니다.

 

 

 

로그를 확인해봐도 정상적으로 빌드가 되었고, cpu-worker의 인스턴스 외부 IP/hash/123 으로 접속해도 정상적으로 연결이 됩니다.

 

 

 

 

 

변경 내역이 정상적으로 배포되는지 확인하기

/hello URL의 리턴값을 수정 하고 add > commit > push 를 진행한 뒤 테스트를 해보겠습니다.

 

 

 

 

정상적으로 변경이 되지가 않는데요, nohup의 로그 파일을 확인하면

8080 포트가 이미 사용중이라는 에러가 발생합니다.

 

특정 포트를 사용중인 프로세스를 확인할 때 사용하는 명령어가 lsof 인데, CentOS에서 기본적으로 제공되는 명령어가 이닙니다.

따라서 설치를 해줍니다.(3 개의 인스턴스 모두 설치합니다.)

$ sudo yum install -y lsof

 

 

 

 

lsof 명령어로 8080 포트를 사용하고 있는 프로세스를 죽이는 명령어

sudo kill -15 $(sudo lsof -t -i:8080)

 

위와 같이 Jenkins에서 빌드 후 조치의 Exec command 명령어 맨 앞에 설정합니다.

(이것도 인스턴스 3개 모두 설정합니다.)

 

 

 

수정 후 git Add > Commit > Push 를 진행하면 위와 같이 배포된 파일을 확인할 수 있습니다.

 

 

현재 무중단 배포가 가능한 상황은 아닌데요, Artillery를 통해 스트레스 테스트를 진행해보면 배포 실패가 되는 일이 발생합니다.

이는, 세 인스턴스가 모두 동시에 배포가 되고있어서 모두 인스턴스가 중지되었을때 Nginx에 요청이 들어오면 실패 코드로 떨어지게 됩니다.

 

 

이를 해결하기 위해 여러 방법이 존재하겠지만, sleep 이라는 명령어를 통해 해결할 수 있습니다.

위와 같이 Jenkins의 빌드 후 조치에서 인스턴스 2와 3의 Exec command에 sleep 30 이라는 명령어를 추가합니다.

수정 후 배포를 하고, Artillery를 통해 스트레스 테스트를 진행하면 무중단 배포가 됩니다.

 

 

class101.net/products/5fc4a3b4fc231b000d85661b

도커를 이용한다면 위와 같이 GitHUB와 Jenkins 사이에 도커를 통해 도커 이미지의 AutomatedBuild 라는 명령어를 통해 진행합니다.

즉, 빌드의 주체가 Jenkins -> Docker 로 변경이 됩니다.

또한 인스턴스에서는 docker run 명령어로 실행을 합니다.