AWS 배포 - RDS 연결

dawn·2021년 5월 27일
0

인프런

목록 보기
2/11

지금까지는 배포 환경을 구성하였는데 이제 이들을 조합해 실제 서비스를 배포할 것이다.
+먼저 프로젝트가 깃허브에 올라가 있어야 한다. 그래야 CI/CD가 가능하다.

1. EC2에 프로젝트 Clone 받기

  • 깃허브에서 코드를 받아올 수 있도록 EC2에 깃 설치
    sudo yum install git

  • 설치 완료 되었는지 확인
    git --version

  • 설치 되었으면 git clone으로 프로젝트를 저장할 디렉토리 생성
    mkdir ~/app && mkdir ~/app/step1

  • 생성된 디렉토리로 이동
    cd ~/app/step1
    git clone 프로젝트 깃허브 주소

  • git clon이 끝났으면 클론된 프로젝트로 이동해서 파일들이 잘 복사되었는지 확인
    cd 프로젝트 명
    ll

  • 코드들이 잘 수행되는지 테스트로 검증
    ./gradlew test

  • 권한 거부 뜨면 chmod +x ./gradlew
    +만약 실패하였을 경우 책 298p 참고하기

  • 현재 ec2에 Gradle를 설치하지 않았지만 Gradle Task를 수행할 수 있다. 이는 프로젝트 내부에 포함된 gradlew 파일 때문이다. 그그레이들이 설치되지 않은 환경 혹은 버전이 다른 상황에서도 해당 프로젝트에 한해서 그레이들을 쓸 수 있도록 지원하는 Wrapper 파일이다.

2. 배포 스크립트 만들기

배포란 작성한 코드를 실제 서버에 반영하는 것을 말한다. 해당 책에서는 다음의 것들이 포함된다.

  • git clone 혹은 git pull을 통해 새 버전의 프로젝트를 받음
  • Gradle이나 Maven을 통해 프로젝트 테스트와 빌드
  • EC2 서버에서 해당 프로젝트 실행 및 재실행
    이것들을 쉘 스크립트를 작성해 스크립트만 실행하면 차례로 진행되도록 할것이다!!

vim ~/app/step1/deploy.sh

다음의 코드를 deploy.sh 에 작성

#!/bin/bash

REPOSITORY=/home/ec2-user/app/step1
PROJECT_NAME=[프로젝트 이름]

cd $REPOSITORY/$PROJECT_NAME/

echo "> Git Pull"

git pull

echo "> 프로젝트 Build 시작"
 
./gradlew build

echo "> step1 디렉토리로 이동"

cd $REPOSITORY

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"
   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 &

코드 설명

+nohup 명령어는 리눅스에서 프로세스를 실행한 터미널의 세션 연결이 끊어지더라도 지속적으로 동작 할 수 있게 해주는 명령어
nohup 상세설명
+"2>&1" 은 표준 에러를 표준 출력과 같게 만드는 명령어
+kill -15 : 정상종료
+kill -9 : 강제 종료
+$(명령어 or 쉘 스크립트 실행 or 쉘 스크립트 함수) : 리턴 결과를 얻고 싶을 때 사용

  1. 프로젝트를 clone 받은 곳으로 이동
  2. git pull을 통해 master 브렌치의 최신 내용을 받는다.
  3. ./gradlew buil를 통해 build 수행
  4. build의 결과물인 jar 파일을 복사해 jar 파일을 모아둔 위치로 복사
  5. 현재 구동중인 pid가 있으면 종료
  6. 가장 마지막에 생성된 jar 파일을 찾아 새로 배포한다.

3.생성한 스크립트에 실행 권한 추가, 실행

chmod +x ./deploy.sh

  • 스크립트 실행
    ./deploy.sh
  • 잘 실행되었으면 nohup.put파일을 열어 로그를 보자. nohup.out은 실행되는 애플리케이션에서 풀력되는 모든 내용을 갖고 있다.

4. 스프링 부트 프로젝트로 RDS 접근하기

진행할 작업은 다음과 같다.

  • 테이블 생성 : H2에서 자동 생성해주던 테이블들을 MariaDB에선 직접 쿼리를 이용해 생성한다.
  • 프로젝트 설정 : MariaDB에서 사용 가능한 드라이버를 프로젝트에 추가
  • EC2(리눅스 서버) 설정 : 데이터베이스이 접속 정보는 중요하게 보호해야 할 정보이다. 따라서 EC2 서버 내부에서 접속 정보를 관리하도록 설정할 것이다.

1)RDS 테이블 생성
JPA가 사용될 엔티티 테이블과 스프링 세션이 사용될 테이블 2가지 종류를 생성한다.
음... JPA가 알아서 테이블 생성해준댔는데..?
스프링 세션 테이블은 schema-mysql.sql 파일에서 확인할 수 있다. 이것을 복사해서 RDS에 붙여넣으래

스프링 세션 테이블은 좀 더 찾아보자. 뭔지 모르겟넹

2) 프로젝트 설정

  • spring.jpa.hibernate.ddl-auto=none로 지정
    create로 설정하면 서버가 다시 실행될 때 테이블을 새로 생성해서 그러는건가...?

JPA의 ddl-auto옵션이 지원하는 속성값은 아래와 같다.

none - 실행하지 않음
create-drop - 어플리데케이션이 구동되고 Session이 시작될때 drop -> create가 실행되고, Session이 종료될 때 (어플리케이션 종료) drop
create - 어플리케이션이 구동되고 Session이 시작될떄 drop -> create 가 실행
update - 스키마가 변경된 경우에만 실행
validate - 변경여부 확인 후 출력, 애플리케이션은 종료

JPA를 사용하는 개발환경에서는 보통 최초 배포시에는 ddl-auto속성을 create, create-drop중 하나를 사용한다.
운영할 때는 none으로 해야함

문제점

  • 수동 실행되는 Test
  • 수동 Build : 다른 사람이 작성한 브랜치와 본인이 작성한 브랜치가 합쳐졌을 때(Merge) 이상이 없는지는 Build를 수행해야만 알수있는데 이를 개발자가 매번 직접 실행해야 한다.

깃허브에 push를 하면 자동으로 Test & Build & Depoly가 진행되도록 개선해보자

profile
안녕하세요

0개의 댓글