DevOps/AWS EC2 jar 배포하기

1. 시작하면서

Spring-Boot를 사용해서 api서버를 구현하였으며, 이를 배포하여 프론트단에서 사용할 수 있도록 하려고 한다. 이에 AWS-ec2를 사용하기로 하였으며, 그 경험을 공유하려고 한다.

2. intellij gradle build

intellij를 사용하면 쉽게 프로젝트를 build해서 jar 파일을 만들 수 있다.

 

[더 공부하기]
(1) war vs jar
jar, war 모두 압축파일로 애플리케이션으르 쉽게 배포하고 동작시킬 수 있도록 관련 파일을 패키징한 것이다. war로 파일의 경우, 웹 어플리케이션을 실행하기 위해 별도의 웹서버나 웹 컨테이너가 필요하다.

(2) gradle vs maven
gradle과 maven은 자바 기반의 빌드도구로 프로젝트 빌드, 의존성 관리 등을 자동화하는데 사용된다. xml 문법으로 스크립트를 작성하던 maven과 달리, gradle은 groovy 문법으로 스크립트를 작성하다 보니 가독성이 좋다. 또한 캐싱을 사용하여 빌드 속도를 maven에 비해 최대 100배까지 빠르다고 한다.(https://gradle.org/maven-vs-gradle/)

3. setting ec2 instance

1) create instance

(1) setting region

(2) setting OS

(3) key-pair storage

(4) setting storage

 

2) setting in/out-bound rules

(1) in-bound
api 프로젝트는 9090 포트에서 실행되도록 설정하였다. 따라서, API 서버의 포트(예: 8080)로 들어오는 트래픽을 허용하는 Inbound 규칙이 필요하다. 아래 소스는 모든 주소를 허용하였으나 지금 설정하고 있는 인스턴스는 개발서버용이므로, 추후 개발자들의 로컬 PC IP로 변경해두려고 한다.

• 유형 : Custom TCP
• 포트 : 9090
• 소스 : 0.0.0.0/0

서버 관리자 역할은 혼자 수행하고 있으므로, ssh를 통해서 직접 인스턴스에 접근할 수 있는 IP는 로컬 PC의 주소로 설정한다.

• 유형 : SSH
• 소스 : 로컬 IP

(2) out-bound
외부 서버 또는 목적지의 포트로, 아직 클라이언트의 포트가 정해지지 않아서 모든 외부 주소로 응답할 수 있도록 설정했다. 아래 소스는 모든 주소를 허용하였으나 지금 설정하고 있는 인스턴스는 개발서버용이므로, 추후 개발자들의 로컬 PC IP로 변경해두려고 한다.

• 유형 : All traffic
• 소스 : 0.0.0.0/0

3) Elastic Ip setting

인스턴스를 중지하거나 다시 시작하면 public ip가 변경되어서, 다른 프로젝트를 변경해야 하는 경우가 많았다. 이때 EIP를 사용하면 EC2에 고정된 퍼블릭 주소를 할당할 수 있다. 이를 통해 인스턴스가 중지/재시작되거나 다른 인스턴스로 변경된다고 하더라도 클라이언트가 여기에 대응하지 않도록 설정할 수 있다.

(1) EIP 생성

(2) EIP 할당

4. transfer jar file to ec2

jar 파일을 인스턴스 내부로 옮기는 방법에는 여러가지가 있다. 보통은 git을 사용하여 인스턴스 내에서 직접 빌드하거나, 가상 vm을 통해서 빌드한 jar 파일을 인스턴스 내부로 옮기기도 한다. api프로젝트는 초기 단계이고 빠른 배포가 필요했기에, 우선은 로컬환경에서 jar파일을 생성하고 인스턴스 내부로 옮기는 방법을 선택했다.

[로컬환경 정보]

• macOS
• project/api에 pem, jar 파일이 존재

[local to ec2]

// scp -i [pem파일경로] [로컬 파일 경로] [ec2 사용자 계정명]@[인스턴스의 public DNS]:[ec2 내부경로]
>> cd project/api
>> scp -i key.epm api.jar ec2-user@10.0.0.0:api

5. project setting

(1) install java-jdk
api 프로젝트는 java-jdk17을 사용하고 있기에, 인스턴스에도 17버전의 java를 설치하였다.

>> sudo yum install java-17-amazon-corretto
>> java —version

 

(2) setting timeZone
api 프로젝트에서 리소스가 생성된 시간과 수정된 시각을 저장하도록 구성되어 있다. 여기에 시스템의 시간을 사용하는데, 이를 위해서도 시스템 시간을 설정할 필요가 있었다.

>> rm/etc/localtime
>> sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

 

(3) run project as background-service
nohup 명령어와 &기호를 사용해서 인스턴스를 빠져나오더라도, 프로젝트가 종료되지 않도록 처리하고자 했다. 아래에서는 nohup을 사용했지만, systemd 등 백그랑룬드 서비스를 위한 다양한 방법이 있다.

>> nohup java -jar api.jar
>> tail -f nohup.out

6. test connection

로컬 PC에서 탄력적 IP를 사용해서 리소스에 접근 가능한지 확인한다. api 프로젝트는 swagger가 적용되어 있으며, 아래 사진처럼 swagger 화면에 접근할 수 있음을 확인하였다.

7. 더 공부할 것

(1) 자동 배포와 빌드
위 프로젝트는 자동 빌드와 자동 배포가 적용되지 않았다. github-action이나 jenkins를 활용해서 배포 과정을 더 쉽게 만들 필요가 있다. 이후에 프로젝트가 더 진행됨에 따라 순차적으로 진행하려고 한다.

 

(2) 개발과 운영 환경 분리
위에서 생성하고 사용한 인스턴스는 개발서버로 사용하려고한다. 그래서 이중화를 고려하지 않았지만, 이후에 운영서버를 구축하면서 환경에 따라 설정파일의 분기가 일어날 수 있도록 설정해보려고한다.

 

(3) 데이터베이스 연결
배포에 사용한 api 프로젝트는 내장된 h2서버를 사용하고 있어서 따로 데이터베이스를 연결하지 않았다. 이후 RDS와 같은 데이터베이스 관리 시스템을 연결하여 안정적인 데이터 영속성을 구현하고자 한다.

 

(4) 로그파일 설정
현재는 nohup.out 파일에 로그가 한번에 쌓이고 있는데, 오류가 날 경우에만 로그가 쌓도록 수정하고자 한다. 또한 매일 파일을 새로 생성하고 최근 10개의 파일만 두고 삭제하도록 수정하고자 한다.