[AWS EC2] 배포 스크립트 생성

배포란?

작성한 코드를 실제 서버에 반영하는 것.

 

• git clone 혹은 git pull을 통해 새 버전의 프로젝트를 받음
• Gradle이나 Maven을 통해 프로젝트 테스트와 빌드
• EC2 서버에서 해당 프로젝트 실행 및 재실행

위와 같은 과정을 배포할 때마다 매번 명령어를 실행시키는 것은 번거롭다.

이를 쉘 스크립트로 작성해 스크립트만 실행하면 차례로 진행되도록 하는 스크립트를 짜보겠다.

(+쉘 스크립트란? .sh 파일 확장자를 가진 파일. 리눅스에서 기본적으로 사용 가능한 스크립트 파일의 한 종류.)

 

 

deploy.sh 파일 생성

vim ~/app/step1/deploy.sh

# 자주 사용하는 값 변수에 저장
REPOSITORY=/home/ec2-user/app/step1
PROJECT_NAME=springboot-aws

# git clone 받은 위치로 이동
cd $REPOSITORY/$PROJECT_NAME/

# master 브랜치의 최신 내용 받기
echo "> Git Pull"
git pull

# build 수행
echo "> project build start"
./gradlew build

echo "> directory로 이동"
cd $REPOSITORY

# build의 결과물 (jar 파일) 특정 위치로 복사
echo "> build 파일 복사"
cp $REPOSITORY/$PROJECT_NAME/build/libs/*.jar $REPOSITORY/

echo "> 현재 구동중인 애플리케이션 pid 확인"
CURRENT_PID=$(pgrep -f ${PROJECT_NAME}.*.jar)

echo "> 현재 구동중인 애플리케이션 pid: $CURRENT_PID"
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/ | grep jar | tail -n 1)

echo "> Jar Name: $JAR_NAME"
nohup java -jar $REPOSITORY/$JAR_NAME 2>&1 &

코드 설명 ▼

CURRENT_PID=$(pgrep -f ${PROJECT_NAME}.*.jar)

- 기존 수행 중이던 스프링 부트 애플리케이션 종료
- pgrep: progress id만 추출하는 명령어

- -f: 프로세스 이름으로 찾기

if ~ else ~ fi

- 현재 구동 중인 프로세스 유무에 따라 기능 수행

- process id 값을 보고 프로세스가 있으면 해당 프로세스 종료

JAR_NAME=$(ls -tr $REPOSITORY/ | grep jar | tail -n 1)
- 새로 실행할 jar 파일명 찾기

- tail -n으로 가장 나중의 jar 파일(최신 파일)은 변수에 저장

nohup java -jar $REPOSITORY/$JAR_NAME 2>&1 &

- 찾은 jar 파일명으로 해당 jar 파일을 nohup으로 실행

- 외장 톰캣 설치 X

- 내장 톰캣을 통해 jar 파일만 있으면 바로 웹 애플리케이션 서버를 실행 가능

- 일반적으로 자바를 실행할 때는 "java -jar" 사용하지만, 이 경우 사용자가 터미널 접속을 끊을 때 애플리케이션도 종료된다.

- 애플리케이션 실행자가 터미널을 종료해도 애플리케이션은 계속 구동될 수 있도록 nohup 명령어를 사용

 

생성한 deploy.sh가 제 역할을 잘 하는지 실행시켜 보자.

$ chmod +x ./deploy.sh  // 권한 부여
$ ./deploy.sh           // 실행
$ vim nohup.out         // 로그 확인

Error: Invalid or corrupt jarfile ~~ 라는 에러가 뜨면 다음 사항들을 확인해보자

1. $REPOSITORY/$PROJECT_NAME/build/libs 경로에 jar 파일이 존재하는지
2. 명령어에 오타가 있는지
3. 변수명이나 변수에 넣은 값에 오타가 있는지
4. PROJECT_NAME 등의 설정이 본인의 설정과 다르진 않은지

첫 번째 경우, "./gradlew test" 를 건너뛰었을 경우 생긴다. 

빌드를 통해 jar 파일이 생겨나는데, 빌드를 하지 않았으니 jar 파일도 존재하지 않는다.

따라서 cp 명령어를 통해 파일을 복사하는 것도 불가능하다.

 

네 번째 경우, 프로젝트 명이나 깃허브 레포지토리 이름 등을 개인적으로 따로 설정했을 경우이다.

자신이 설정한 값에 맞춰 설정해주어야 한다.

 

 

배포 스크립트는 완성됐지만, OAuth 기능 구현까지 했던 사람들은 문제가 있을 것이다.

보안상 oauth 관련 설정들을 저장한 properties는 Git에 업로드하지 않았다.

따라서 Git에서 프로젝트를 받아온 ec2에도 설정 파일이 없다.

이 설정들을 서버에서 직접 가지고 있도록 새로 작성해보겠다.

 

step1이 아닌 app 디렉토리에 properties 파일을 생성한다. (내용은 로컬에서 복붙)

deploy.sh의 일부 내용을 변경한다.

nohup java -jar \
	-Dspring.config.location=classpath:/application.properties,/home/ec2-user/app/application-oauth.properties \
	$REPOSITORY/$JAR_NAME 2>&1 &

 

코드 설명 ▼

\ (역슬래시)

- 다음 라인도 같은 줄로 인식

 

-Dspring.config.loaction

- 스프링 설정 파일 위치 지정

- application.properties(기본옵션), application-oauth.properties(OAuth 설정들)

- classpath가 붙으면 jar 파일 안의 resources 디렉토리 기준으로 경로 생성

- application-oauth.properties는 파일이 외부에 있기 때문에 절대 경로 사용

 

수정한 deploy.sh를 실행시키면 로그 파일을 통해 실행을 확인할 수 있다.

 

---

해당 게시글은 [ 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 / 이동욱 ] 책을 따라한 것을 정리하기 위한 게시글입니다. 요약, 생략한 부분이 많으니 보다 자세한 설명은 책 구매를 권장합니다.