CICD - 트러블슈팅

🎈deploy.sh 작성 → 리눅스 쉘 스크립트 작성

: CI/CD는 개발자가 하는 작업을 다양한 프로그램들을 활용하여 자동으로 통합배포하는 것이다.

따라서 자동배포에 사용하는 프로그램들이 어떤 과정으로 이루어지는지 정확히 알아야했다.

CI/CD를 구현하는 프로그램들은 아무것도 없이 알아서 해주는게 아니다.

개발자가 직접 코드를 작성하여 명령을 해주어야한다. 그러한 과정 중에 작성하는 쉘 스크립트는 제대로 경험해보지 못했기에 CI/CD 과정중에 맞닥뜨린 기억에 남는 트러블 슈팅 중 하나이다.

백엔드는 해당과정에서 발생한 트러블 슈팅에 대해서 공유해보도록 하겠다.

GithubAction + S3 + CodeDeploy 를 사용하여 CI/CD를 구축하는데 해당 과정 중 ec2에서 실행될 deploy.sh 파일을 작성해야 한다.

해당 파일은 CodeDeploy agent 에 의해 실행되어 ec2 우분투 서버에 작성한 스크립트에 맞춰 실행된다.

REPOSITORY1=/home/ubuntu
REPOSITORY=/home/ubuntu/app
PROJECT_NAME=moabuja

echo "> 현재 구동중인 애플리케이션 pid 확인"
CURRENT_PID=$(pgrep -fl $PROJECT_NAME | grep java | awk '{print $1}')

if [ -z $CURRENT_PID ]; then
    echo "> 현재 구동중인 애플리케이션이 없으므로 종료하지 않습니다."
else
    echo "> kill -15 $CURRENT_PID"
    kill -15 $CURRENT_PID
    sleep 5
fi

echo "> 새 어플리케이션 배포"
JAR_NAME=$(ls -tr $REPOSITORY/*.jar | tail -n 1)

echo "> $JAR_NAME에 실행권한 추가"
chmod +x $JAR_NAME

echo "> $JAR_NAME 실행"
nohup java -jar $JAR_NAME > $REPOSITORY1/nohup.out 2>&1 &

트러블 슈팅이 일어난 부분을 공유해보겠다.

• nohup 시 생성되는 파일인 nohup.out 파일이 빌드파일이 있는 폴더가 아닌 이전 폴더에 생긴다.

→ 따라서 원래 코드인 $REPOSITORY/nohup.out 2>&1 & 코드 작성 시 nohup.out, 파일을 제대로 읽어내지 못해서 에러를 일으켰다.

 

---

😍😍해결 : 로그를 확인하자!!

ec2에서 CodeDeploy가 배포과정 중 일으키는 에러를 로그를 확인하여 하나씩 찾아 나갔다.

/opt/codedeploy-agent/deployment-root/deployment-logs 폴더 위치로 이동하여

cat codedeploy-agent-deployments.log 명령어로 log파일에 들어가 배포 시 발생한 에러 로그를 확인하였다.

로그파일을 살펴보니 nohup.out 파일에 대한 스크립트 언어가 제대로 실행되지 않았다.

에러 로그 확인 후 nohup.out 파일이 생기는 위치를 정확하게 확인하였다.

해당 파일은 실제 .jar 파일이 존재하는 이전 폴더에 생성되어 해당 스크립트 언어가 실행되지 않고 에러를 일으켰다.

따라서 nohup.out 파일이 생성되는 파일의 위치에 맞게 스크립트 언어를 작성하여 해결하였다.

---

🍗🍗로그를 찍는 스크립트 문법

사실 위의 문제를 해결하기 전에 원래 코드는 아래와 같았다.

**/dev/null 2>&1 &**

해당 스크립트어가 어떤 명령어인지를 명확히 알지 못하여 해당 코드가 에러를 일으키는 줄 알았다. 그리고 해당 코드에 대해 살펴보았다.

리눅스에서는 0, 1, 2는 표준 입력, 표준 출력, 표준 에러의 의미를 가진다.

• 0 : 표준 입력(stdin)
• 1 : 표준 출력(stdout)
• 2 : 표준 에러(stderr)

**/dev/null** -> 이 디바이스 파일은, 출력을 버릴 때 언급된다.

즉 위의 코드인 **/dev/null 2>&1 &* 코드는*

: 표준 출력과 표준 에러를 모두 버리기 위해 사용하는 명령어로 쉘 스크립트에서 사용된다.

즉, nohup.out 에 출력과 에러에 대한 내용을 기록하지 않겠다는 명령어이다.

프로젝트를 배포 후 프로그램에 대한 출력이 로그로 남지 않아 어떤 문제인지를 살펴보니 해당 명령어의 용도를 모르고 사용해서 일어난 문제였다.

프론트와 작업을 하는 과정에서 에러를 확인하며 작업을 해야했기에 로그를 찍어 보는건 매우 중요한 문제였다. 따라서 **nohup.out 2>&1 &** 코드를 작성하여 로그를 남기기 시작했다.

 

하지만 우리가 간과한 부분이 있었다. nohup은 백그라운드(&) 작업에서 실행하는 명령어로 여러개의 shell파일을 실행하게 되면 실시간 nohup.out 로그 용량이 감당이 안될정도로 커지게 된다.

 

🔔따라서 해당 문제를 해결하기 위해서 로그를 남기는 파일을 어떤식으로 처리할 지 고민해봐야 겠다는 생각을 해본다.

CloudWatch 사용? / 로그파일 S3에 업로드하기?