지난 시간에는 스와핑을 통하여 Jenkins가 동작하지 않는 오류를 해결해보았습니다.

그러나, Jenkins를 동작하니 다음처럼 빌드에 실패하는 상황이 발생하였습니다.

따라서 오늘은 빌드에서 발생한 문제를 해결해보고, Jenkins의 동작을 확인해보도록 하겠습니다.

Gradle 버전으로 인한 문제

Jenkins는 다음처럼 빌드 과정에서 출력되는 구문을 확인할 수 있습니다.

이를 통하여 빌드에서 오류가 발생하였을 경우, 오류 원인을 확인할 수 있는데, 저는 다음과 같은 원인으로 인하여 빌드에 실패하였습니다.

처음에는 grardlew에게 실행 권한이 부여되지 않아서 발생하는 오류인줄 알았으나, 결국 gradle의 버전 문제인 것으로 밝혀졌습니다.

https://github.com/spring-projects/spring-boot/issues/38718

따라서 다음처럼 Gradle의 버전을 프로젝트의 버전과 동일시함으로써 문제를 해결하였습니다.

빌드 환경으로 인한 문제

Jenkins의 경우, 우리가 사전에 설정해두었던 Repository의 정보를 가져와서 빌드하기 때문에 다음처럼 application.yml 파일을 설정하였을 경우, 데이터베이스를 위한 정보가 존재하지 않기 때문에 오류가 발생합니다.

spring:
  profiles:
    include: prod

따라서, 프로젝트 내부에 환경 변수를 저장하기 위한 파일을 추가하였으며, 다음처럼 yml 파일을 수정하였습니다.

빌드 과정에서 필요한 환경 변수는 Jenkins 내부에서 환경 변수를 설정하는 옵션이 존재하기 때문에,

DashBoard -> System -> Global properties 에서 환경 변수를 지정해주었습니다.

이후, 빌드가 성공하는 것을 확인할 수 있었습니다.

환경 변수로 인한 문제

Jenkins에서 빌드까지는 성공하였으나, Application Server에서 프로젝트를 실행하는 것은 실패하였습니다.

그 이유는 Jenkins에서 오류가 발생했던 이유와 동일한 환경 변수로 인하여 문제가 발생한다는 점입니다.

따라서, 다음처럼 쉘 스크립트 파일을 생성한 뒤, 이를 통하여 jar 파일을 실행하였습니다.

#!/bin/bash

DIRECTORY=/home/ubuntu/chrkb1569
PROJECT_NAME=CI-CD-Practice-0.0.1-SNAPSHOT
DB_URL=
DB_USERNAME=
DB_PASSWORD=

echo "> 현재 실행중인 애플리케이션의 프로세스 ID 확인"
CURRENT_PID=$(pgrep -fl $PROJECT_NAME/*.jar| awk '{print $1}')

echo "> 현재 실행중인 프로세스 ID == $CURRENT_PID"
if [ -z "$CURRENT_PID" ]; then
  echo "> 현재 실행 중인 애플리케이션이 존재하지 않습니다."
else
  echo "실행 중인 애플리케이션을 종료하겠습니다."
  kill -9 $CURRENT_PID
  sleep 10
fi

echo "> 애플리케이션을 종료하였습니다!"

echo "> 새로운 애플리케이션 실행"
LATEST_PROJECT_NAME=$(ls -tr $DIRECTORY/*.jar | grep jar | tail -n 1)

echo "> 실행 권한 부여"
chmod 700 $LATEST_PROJECT_NAME

export DB_URL
export DB_USERNAME
export DB_PASSWORD

echo "> $LATEST_PROJECT_NAME 실행"
nohup java -jar $LATEST_PROJECT_NAME > $DIRECTORY/nohup.out 2>&1 -dDB_URL=$DB_URL -dDB_USERNAME=$DB_USERNAME -dDB_PASSWORD=$DB_PASSWORD &

쉘 스크립트 파일의 경우, github Action에서 사용하였던 파일을 거의 그대로 사용하였기 때문에 어려운 점은 없었습니다.

기껏해야 환경 변수를 조금 추가해줬다는 것 정도?

다음처럼 스크립트 파일을 생성한 뒤, 다음처럼 Jenkins에서의 빌드 이후 실행할 명령어를 수정한 뒤 빌드를 실행해본다면,

다음처럼 배포까지 성공적으로 수행된 것을 확인할 수 있습니다.

한계

사실 이제까지 열심히 Jenkins를 사용하여 CI/CD 환경을 구축해보았으나, 이러한 방식은 잘 사용하지 않는 방식이라고합니다.

일단 SSH 통신을 사용하여 파일을 주고 받기 때문에 보안적으로도 취약할 뿐더러, 가장 결정적인 이유는 바로 편리성입니다.

Github Action을 사용하는 경우에는 PR이 발생하자마자 빌드 및 배포까지 진행되었기 때문에 초기 설정이 끝마친 뒤에 개발자는 추가적으로 수행해야하는 작업이 없었습니다.

그러나, Jenkins의 경우에는 github repository에 커밋 -> Jenkins 접속 -> Jenkins에서 빌드 수행 이라는 과정을 거쳐야지만 배포가 이루어진다는 불편함이 존재합니다.

그래서 요즘 많이 사용하는 방식이 Github Action과 Jenkins를 같이 사용하는 방식을 많이 사용한다고합니다.

또한, Jenkins도 Github Action처럼 별도의 스크립트 파일을 생성하여 사용자가 정의한대로 동작하도록 설계할 수 있다는데, 다음 시간에는 이를 활용해보는 시간을 가져봐야겠습니다.