[DevOps] AWS EC2 인스턴스에 Spring 애플리케이션 배포하기 / + 백그라운드에서 배포 방법 (nohup, tmux, (리눅스) systemd 서비스 파일)

0-1. AWS EC2 생성 방법

2023.12.28 - [DevOps/CI,CD] - [CI/CD] AWS EC2 인스턴스 생성 방법

[CI/CD] AWS EC2 인스턴스 생성 방법

 

0-2. AWS EC2 인스턴스 접속 방법

2023.12.28 - [DevOps/CI,CD] - [CI/CD] AWS EC2 인스턴스 SSH 접속 + Docker 설치

[CI/CD] AWS EC2 인스턴스 SSH 접속 + Docker 설치

• 위의 글에서 1. 터미널로 접속하는 방법으로 진행

 

1. EC2 인스턴스에서 Spring 애플리케이션 배포 방법

• EC2 인스턴스 생성 시 OS를 Amazon Linux 로 선택함
  • Linux, Ubuntu 각각의 명령어에 대해 적을 것임

 

1-1. Java 설치

• 생성된 EC2 인스턴스에는 자바가 설치되어 있지 않음 ⇒ 직접 설치해야 함
• 여기서는 java-17-amazon-corretto 를 설치함 → 원하는 패키지를 설치할 것

(Linux) 
sudo yum install java-17-amazon-corretto -y

(Ubuntu) 
sudo apt install amazon-corretto-17 -y

 

• (JDK 설치) Amazon Corretto의 JDK 설치 (우분투에서는 -devel 패키지가 별도 존재 x)

(Linux)
sudo yum install java-17-amazon-corretto-devel -y

 

1-2. 환경 변수 설정

• 자바의 설치 경로를 환경 변수로 설정

(Linux, Ubuntu)
echo 'export JAVA_HOME=$(dirname $(dirname $(readlink -f $(which java))))' >> ~/.bashrc

• export JAVA_HOME=… : JAVA_HOME 환경 변수 설정
• $(which java) : 설치된 자바 실행 파일의 경로를 찾음
• $(readlink -f ...) : 심볼릭 링크를 따라가 실제 파일의 경로를 반환
• $(dirname ...) : 주어진 경로의 디렉토리 이름을 반환 ⇒ 여기서는 JDK의 최상위 디렉토리를 반환함
• >> ~/.bashrc : ~/.bashrc 파일의 끝에 위에서 생성된 export JAVA_HOME=... 내용을 추가
  • 이 파일은 사용자가 로그인할 때마다 실행되는 스크립트

 

(Linux, Ubuntu)
echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.bashrc 
source ~/.bashrc

• export PATH=... : PATH 환경 변수 설정
• $JAVA_HOME/bin : JAVA_HOME 환경 변수에 설정된 Java 설치 경로의 bin 디렉토리를 참조
• :$PATH : 기존의 PATH 변수 값을 유지하면서, 새로운 경로를 추가
• source ~/.bashrc : .bashrc 의 내용을 현재 세션에 적용함

 

2. Spring 프로젝트 클론

2-1. Git 설치

(Linux)
sudo yum install git -y

(Ubuntu)
sudo apt install git -y

 

2-2. 프로젝트 클론

git clone 클론받을 (깃허브 레포 등) 주소

 

3. 프로젝트 실행

• ssh로 EC2 인스턴스 접속 후 Spring 프로젝트를 빌드 및 실행함으로써 배포 완료할 것

 

3-1. 프로젝트 빌드

cd 프로젝트 디렉토리
sudo chmod 777 gradlew
./gradlew clean
./gradlew build

• sudo chmod 777 gradlew : 프로젝트 내의 gradlew 의 권한 변경
• ./gradlew clean : 프로젝트를 새로 빌드하기 전에 이전 빌드 결과 제거 ⇒ 깨끗한 상태에서 빌드 시작
• ./gradlew build : gradle 빌드 작업 실행
  • 소스 코드 컴파일
  • 필요한 의존성 다운로드
  • 최종적으로 JAR 파일이 생성됨! (build/libs 에 생성됨)

 

3-2. 프로젝트 실행

java -jar build/libs/생성된 jar파일명.jar

• 별도의 설정이 없다면 프로젝트의 이름-0.0.1-SNAPSHOT.jar 일 것임
  • jar 파일의 이름을 설정하고 싶다면 build.gradle에서 설정 가능

  jar {
      baseName = 'custom-jar-name'  // 원하는 JAR 파일 이름 설정
      version = '1.0.0'             // 버전 설정
  }
  

 

3-3. 배포 확인

• EC2 인스턴스의 퍼블릭 IPv4DNS:8080 으로 접속 가능

 

4. 백그라운드에서 실행

• 위의 방법대로 배포까지 마침
• 만약 ssh 세션이 끊긴다면 애플리케이션이 종료됨 ⇒ 배포 중단되는 결과!
  • ssh로 접속한 터미널에서 실행된 프로세스가 해당 터미널 세션과 연결되어 있음
  • 따라서 ssh 세션이 끊어지면 그 세션에서 실행중인 모든 프로세스가 종료되기 때문

 

4-1. nohup 명령어 사용

nohup java -jar build/libs/jar파일명.jar &

• nohup : 세션이 종료되어도 프로세스가 계속 실행됨
• & : 명령어를 백그라운드에서 실행하도록 함

 

⇒ ssh 세션이 끊기거나 터미널이 종료되더라도 배포가 됨을 확인가능함!

 

4-2. tmux 사용

• tmux
  • 터미널 멀티플렉서
  • 한 개의 터미널 세션에서 여러 개의 창과 패널을 관리 가능하게 하는 도구
  • SSH 세션이 끊겨도 실행 중인 프로세스 유지 가능!

 

4-2-1. tmux 설치

(Linux)
sudo yum install tmux

(Ubuntu)
sudo apt install tmux

 

4-2-2. tmux 세션 시작

• 새로운 세션 시작

tmux

(세션에 이름 지정 및 시작)
tmux new -s 세션이름

 

4-2-3. 세션에서 애플리케이션 실행

• 위의 방법 (ssh에서 애플리케이션 실행 방법) 과 동일하게 진행하면 됨

java -jar build/libs/jar파일명.jar

 

⇒ ssh 세션이 끊기거나 터미널이 종료되더라도 배포가 됨을 확인가능함!

 

4-2-4. 현재 세션 분리

• 현재의 tmux 세션은 유지하고 tmux 창에서 나오는 것을 의미함
• 현재 실행중인 프로세스는 유지됨
• 나중에 다시 세션에 재접속 가능!

ctrl+b, d (컨트롤과 b 동시에 누르고 이후에 d를 누름)

 

4-2-5. 세션 재접속

• 분리된 세션 목록 보기

tmux ls

⇒ 세션이름 혹은 세션번호와 세부 정보가 출력됨

 

• 분리된 세션에 다시 연결

tmux attach-session -t 세션이름
tmux attach-session -t 세션번호
tmux attach -t 세션번호

• -session → 생략 가능

 

4-2-6. 세션 종료

• 세션 내부에서 아래의 명령어 (둘 중 하나) 입력

exit

ctrl + d

 

4-3. (Linux) systemd 서비스 유닛 파일 생성

• 리눅스에서 가능함
• 시스템의 sytstemd 서비스 유닛 파일을 생성해서 Spring 애플리케이션을 시스템의 서비스로 등록하여 백그라운드에서 실행하도록 설정 가능

 

4-3-1. 서비스 유닛 파일 생성

sudo vi /etc/systemd/system/서비스이름.service

 

4-3-2. 서비스 유닛 파일 작성

[Unit]
Description=설명
After=network.target

[Service]
User=ec2-user
ExecStart=/usr/bin/java -jar /프로젝트 디렉토리/build/libs/jar파일명.jar
SuccessExitStatus=143
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

• [Unit] 섹션
  • Description : 서비스의 간단한 설명 기입
  • After : 이 서비스가 시작되기 전에 반드시 시작되어야 하는 서비스 지정
    • network.target : 네트워크가 준비된 후에 이 서비스가 시작되도록 설정 (애플리케이션이 네트워크에 의존하는 경우에 중요함)
• [Service] 섹션
  • User : 애플리케이션을 실행할 사용자 계정
  • ExecStart : 실제로 사용될 명령어
    • /usr/bin/java : Java 실행 파일의 경로를 명시적으로 지정
  • SuccessExitStatus : 서비스가 성공적으로 종료된 것으로 간주할 exit 상태 코드
    • 143 : 일반적으로 프로세스가 SIGTERM 신호를 받아 종료되었음을 나타냄
  • Restart : 서비스가 종료되었을 때 재시작할 조건 설정
    • on-failure : 애플리케이션이 비정상적으로 종료되면 자동으로 재시작함
    • always : 애플리케이션이 종료되면 자동으로 재시작함
  • RestartSec : 재시작하기 전 대기할 시간 설정 ⇒ 여기서는 5초 후에 재시작 시도함
• [Install] 섹션
  • WantedBy : 서비스가 어떤 런 레벨에서 활성화될 지 지정
    • multi-user.target : 일반적인 다중 사용자 환경 의미

 

⇒ 작성 후에는 esc > :wq! 로 파일 저장 후 나감

 

4-3-3. systemd 데몬 reload

• 위에서 작성한 유닛 파일을 인식하도록 systemd 데몬 reload

sudo systemctl daemon-reload

 

4-3-4. 서비스 시작

• 위에서 작성한 서비스를 시작함

sudo systemctl start 서비스이름.service

• 시스템 부팅 시 자동으로 시작되도록 설정

sudo systemctl enable 서비스이름.service

 

⇒ ssh 세션이 끊기거나 터미널이 종료되더라도 배포가 됨을 확인가능함!

 

4-3-5. 서비스 상태 확인

sudo systemctl status 서비스이름.service

⇒ 현재 실행중인지 확인 가능

 

4-3-6. 서비스 종료

sudo systemctl stop 서비스이름.service

• 위에서 enable로 설정했다면 서비스를 종료하더라도 시스템 부팅 시 자동으로 서비스가 시작됨
• 이를 중단하려면 비활성화 하면 됨

sudo systemctl disable 서비스이름.service