웹 프로젝트 배포하기 (3) - 서버(SpringBoot) 배포 및 CI/CD 구축
[AWS] 웹 프로젝트 배포하기 (2) - 메모리 증설 및 자바 설치
웹 프로젝트 배포하기 (2) - 메모리 증설 및 자바 설치 [AWS] 웹 프로젝트 배포하기 (1) - EC2 인스턴스 생성웹 프로젝트 배포하기 (1) - EC2 인스턴스 생성 1. AWS 접속 무료 클라우드 컴
hanadoescoding.tistory.com
이전 글에서 이어집니다
1. 깃허브 계정 설정 및 클론
여태까지 빌드업이었다. (실화)
본격적으로 서버 배포를 시작해보자.
프로젝트 파일을 ① FileZilla 를 통해 직접 옮기는 방식도 있지만
Github 의 Actions 기능을 다루기 위해 미리 깃허브 레포지토리에 업로드해둔 상태다.
따라서 ② 깃허브에서 프로젝트 파일을 클론해 올 것이다.
1.1 깃허브 계정 설정?
계정 설정이 뭔말인가 허늘...
만약 레포지토리가 private 라면 명령을 사용할 때 접근을 위한 토큰키를 요구한다.
사실은 Github 의 Action 기능을 통해
자동으로 커밋/푸시/머지한 내용을 받아 적용하는 CI/CD 기능을 위한 것이라
계정이 public 이고, 최종 배포판이라면 해당 내용은 스킵해도 된다.
물론.. 배포, 외부 서버 접근에 따라 인증을 요하기도 하니 판단은 본인이 하면 되겠다.
1.2 깃허브 정보 저장
해당 방식은 임시방편이다.
위의 명령으로만 깃허브 계정에 대한 정보를 저장해두면
저장해둔 공간인 ~/.git-credentials 파일만 열면 Github 계정의 사용자명과 비밀번호(또는 토큰) 정보를 볼 수 있다.
보안이 중요한 환경에서는 cache 나 SSH 키 방식을 이용하고,
위 방식은 보안이 중요하지 않은 개인 프로젝트 업로드용으로 추천한다.
git config --global user.name "<깃허브아이디>"
git config --global user.email "<깃허브이메일>"
git config --global credential.helper store
| git config --global user.name "<name>" | 깃허브 사용자 이름 |
| git config --global user.email "<email>" | 깃허브 사용자 이메일 |
| git config --global credential.helper store | 정보를 저장해둘 공간 |
1.3 클론 및 토큰키
레포지토리가 private 상태라면 클론 명령을 쳤을 때 깃허브 이름과 비밀번호를 물어본다.
1.3.1 클론
git clone <레포지토리 주소>
<깃허브 아이디 입력>
<토큰키 입력>
토큰키를 작성하는 부분은 텍스트가 나오지 않으니 복사 붙여넣기를 추천한다.
(간혹 붙여넣기 과정에서 이상한 문자들이 들어가 실패하기도 함)
사용자(ubuntu) 이자 cd ~ 에 해당하는 위치에 클론했다.
1.3.2 토큰키 발급
토큰키는 깃허브에서 손쉽게 발급받을 수 있다.
오른쪽 상단 내 프로필을 눌러 Settings
왼쪽 탭의 맨 아래 Developer settings
Personal access tokens 아래 Tokens (classic)
Generate new token (classic) 으로 토큰을 생성하면 된다.
토큰 이름을 설정하고
기간은 원하는대로지만 No expiration 으로 제한을 두지 않았다.
이후 Select scopes 로 해당 토큰이 어떤 기능에서 권한을 갖고 있는지 설정할 것인데
잘 모르겠으면 사진 외에 나온 기능들까지도 다 선택하면 된다. 일단 혼자쓰니까 ^^b
이후 Generate token 버튼을 누르면 토큰이 생성된다.
토큰 생성 직후 가려진 부분에 토큰키가 나타난다.
해당 키는 생성 직후 딱 한 번만 보여주기 때문에 꼭 저장해두자.
토큰 키를 password 입력에 잘 붙여넣으면 첫 사진처럼 빌드가 될 것이다.
ls -all
ls -all 로 해당 디렉토리 위치의 파일들을 다 볼 수 있다.
프로젝트가 클론이 됐는지 확인해보자.
2. SQL 설치
MySql 을 사용하여 entity 로 만든 데이터들을 관리했다.
데이터를 끌어오기 위한 SQL 을 설치해주자.
2.1 SQL 설치
sudo apt-get install mysql-server
중간에 계속하겠니? 라는 문구가 뜬다면 y 를 입력해주어야 설치가 진행된다.
2.2 SQL 계정 설정
sudo mysql -u root -p
(최초 접속 시 password 부분에서 enter)
alter user "root"@"localhost" identified with mysql_native_password by "adminuser";
| sudo mysql -u root -p | mysql 접속 |
| alter user "<사용자>"@"<서버의 위치>" identified with mysql_native_password by "<비밀번호>" | 비밀번호 설정 |
최초 접속 시에는 password 부분에서 enter 로 넘어갈 수 있지만
그 즉시 비밀번호를 설정해주어야 한다.
사용하고 있는 mysql 계정이 최고 권한의 관리자 계정인 root 이고, 비밀번호는 adminuser 로 되어있어 (국룰)
위 명령처럼 작성해 adminuser 를 비밀번호로 설정해주었다.
2.3 스키마 생성
create schema `<스키마 이름>` default character set utf8mb4 collate utf8mb4_0900_ai_ci;
프로젝트의 yml 에 적혀있는대로
사용한 스키마와 이름, 설정까지 동일하게 만들어주었다.
show databases;
해당 명령으로 스키마를 확인할 수 있다.
2.4 sql 파일 사용
기존 sql 파일의 데이터가 필요하기 때문에 깃허브에 sql 파일을 함께 올려놨었다.
sql 파일은 본인처럼 ① 깃허브
혹은 ② filezilla 로 인스턴스에서 조회할 수 있도록 넘겨주면 된다.
quit
잠깐 sql 을 나가주자.
sql 파일이 있는 디렉토리 위치로 이동(cd) 해서 다시 sql 을 실행한다.
(명령에서 경로를 지정해줘도 되지만, 절대 경로를 사용하는 등 복잡해져서 sql 파일 위치로 이동했다)
use <스키마 이름>
source ./<sql 파일 이름>
사용할 데이터베이스를 방금 만든 streaming 스키마로 변경하고
현재 MySql 세션에서 sql 스크립트를 실행하는 명령을 입력했다.
show tables;
show 명령을 통해 sql 명령이 실행되어 테이블이 생성된 걸 확인 할 수 있다.
3. 빌드 및 권한 부여
단순히 서버를 여는 작업을 해보는 거라면,
① yml 파일을 따로 만들고 ② 빌드 하는 여기까지의 과정을 실행하면 된다.
만약 CI/CD 작업이라면,
① 최초 빌드 후 ./gradlew 권한을 부여하고
② 깃허브의 Actions 기능을 이용하여 yml 을 secret 으로 숨겨 보내며
③ 자동으로 풀, 빌드, 배포가 되는 자동화 작업(CI/CD)을 추가로 진행할 수 있다
아무튼 빌드해보자.
3.1 yml 생성
cd <프로젝트 폴더>/src/main/resources
application.yml 이 있어야 할 위치로 이동했다.
sudo vi application.yml
application.yml 파일을 생성, 수정하는 vi 명령을 이용해
해당 파일에 프로젝트의 application.yml 전체 내용을 복사-붙여넣기 해준다.
① ' a ' 나 ' i ' 로 편집 모드로 들어간 뒤
② 복사한 내용을 ' 마우스 우클릭 ' → ' 붙여넣기 ' 후
③ ' esc ' + ' !wq ' 로 빠져나오면 된다.
파일이 잘 생성되었는지 확인해주자.
3.2 빌드 전 권한 부여
빌드를 위해서는 gradlew 파일에 실행 권한을 부여해야 한다.
프로젝트 폴더로 올라와 gradlew 파일을 살펴보면
맨 앞에 -rw-rw-r-- 로 되어 있는 걸 볼 수 있다.
-rw-r--r--
│ │ │ │
│ │ │ └── 다른 사용자(Other)의 권한 (읽기만 가능, `r--`)
│ │ └──── 그룹 사용자(Group)의 권한 (읽기만 가능, `r--`)
│ └────── 파일 소유자(User)의 권한 (읽기/쓰기 가능, `rw-`)
└──────── 파일 타입 (`-` = 일반 파일, `d` = 디렉토리)
파일 타입과 권한을 나타내는 부분으로, 실행 권한이 없어 현재는 빌드를 할 수 없다.
sudo chmod 777 ./gradlew
권한을 모두 부여하는 명령을 통해 실행 권한을 부여해주자.
3.3 빌드
.gradlew clean build
BUILD SUCCESSFUL 이 뜨면 성공이다!
.gradlew clean build -x test
만약 test 어쩌고 하면서 오류가 뜬다면
test 파일을 제외하고 빌드하는 위 명령을 사용하자.
3.4 실행 테스트
cd build/libs
java -jar <*SNAPSHOT.jar 파일명>
build/libs 폴더로 들어가 SNAPSHOT.jar 파일을 실행하면
우리가 아는 서버 실행화면이 나오게 된다.
이후 IP:<서버포트> 로 테스트 화면이 있다면 출력할수도 있지만
현재 서버 포트를 인스턴스 생성 당시 열어두겠다는 설정을 하지 않았기에
확인하지 않고, 에러없이 실행되는지만 확인하고 넘어가겠다.
4. 액션 (Actions)
4.1 Action 활성화를 위한 yml 생성
① 프로젝트 폴더에서 .github 이름의 디렉토리를 만들어 준다.
② .github 디렉토리 안에 workflows 디렉토리를 만든다.
③ workflows 디렉토리 안에는 delpoy.yml 을 만든다. (yml 이름은 상관없음)
| .github ㄴ workflows ㄴ delpoy.yml |
사진과 같은 형식으로 만들어주면 된다.
yml 에 코드를 추가하는 순간, 깃허브에서 코드를 실행하게 된다.
4.2 actions 실행을 위한 yml 코드
name: GitHub Actions 실행 # workflow 의 이름
on:
push:
branches:
- main # main 브랜치에 push 될 때 아래의 workflow 를 실행
jobs:
My-Deploy-job: # GitHub Actions 에서 실행될 Job 이름
runs-on: ubuntu-latest # Actions 실행 환경
steps: # Job 이 실행될 단계 정의
- name: Dive 프로젝트 서버 배포
uses: appleboy/ssh-action@master # Actions 의 appleboy/ssh-action 을 사용하여 SSH 접속 수행
env: # 환경변수 설정
APPLICATION_PROPERTIES: ${{ secrets.APPLICATION_YML }} # secret 에 작성한 yml 가져오기
with:
host: ${{ secrets.EC2_HOST }} # EC2 인스턴스의 공인 IP 주소 또는 도메인
username: ${{ secrets.EC2_USERNAME }} # EC2에 접속할 사용자 이름
key: ${{ secrets.EC2_PRIVATE_KEY }} # SSH 접속을 위한 비밀키
envs: APPLICATION_PROPERTIES # 환경변수를 EC2 서버에 전달
script_stop: true # 스크립트 실행 중 오류가 발생하면 즉시 종료
script: |
cd /home/ubuntu/project-dive-musicstreaming
rm -rf src/main/resources/application.yml
git pull origin main
echo "$APPLICATION_PROPERTIES" > src/main/resources/application.yml
sudo ./gradlew clean build
sudo fuser -k -n tcp 8070 || true
nohup java -jar build/libs/*SNAPSHOT.jar > ./output.log 2>&1 &
전체 코드는 다음과 같다.
${{ }} 으로 감싸져 있는 변수는 GitHub Actions 에서 설정해줄 것이다.
해당 정보는 공개되면 안 되는 동시에 관리를 편하게 하도록하기 위함이다.
script 이후 명령은 EC2 에서 실행할 배포 코드가 담겼다.
4.3 배포 코드
배포 코드가 바로 EC2 에서 직접 사용할 명령이다.
수정 사항을 깃허브에 push(or merge) 하는 것만으로도 액션을 통해 해당 코드가 자동 실행되도록 하는 것이다.
| 코드 | 설명 |
| | | 여러 줄 작성 |
| cd /home/ubuntu/project-dive-musicstreaming | 프로젝트 폴더 위치로 이동 |
| rm -rf src/main/resources/application.yml | 기존 yml 파일 삭제 (보안 강화) |
| git pull origin main | 레포지토리의 main 브랜치에서 당겨오기 |
| echo "$APPLICATION_PROPERTIES" > src/main/resources/application.yml | GitHub Secrets 에 저장된 APPLICATION_PROPERTIES 를 application.yml 파일로 생성 |
| sudo ./gradlew clean build | SpringBoot 프로젝트를 빌드 |
| sudo fuser -k -n tcp 8070 || true | 포트 8070을 사용하는 프로세스를 종료 (없어도 계속 실행) |
| nohup java -jar build/libs/*SNAPSHOT.jar > ./output.log 2>&1 & | SpringBoot 서버가 백그라운드에서 계속 실행되도록 설정 |
4.4 Actions 의 Secrets 정보 만들기
deploy.yml 에 secrets 으로 숨겨둔 값들을 작성해줄 차례다.
깃허브 레포지토리 → Settings → Secrets and variables → Actions
탭으로 들어가 New repository secret 을 통해 만들 수 있다.
4.4.1 EC2_HOST
EC2 인스턴스의 공인 IP 또는 도메인 주소 값이 들어가는 부분이다.
인스턴스 터미널 창에서 확인할 수 있다.
Name 은 꼭 설정해준대로, Secret 값에는 IP 주소만 작성해주자.
4.4.2 EC2_USERNAME
EC2 에 접속할 사용자 이름이다.
인스턴스 연결 당시 작성된 사용자 이름을 적어 넣으면 된다.
인스턴스 터미널 내에서도 확인할 수 있다.
4.4.3 EC2_PRIVATE_KEY
SSH 접속을 위한 토큰키다. 인스턴스 생성 당시 설정한 .pem 페어키가 이곳에 해당된다.
.pem 파일을 메모장으로 열어보면
----- BEGIN RSA PRIVATE KEY ----- 부터 ----- END RSA PRIVATE KEY ----- 까지의 내용을 확인할 수 있다.
해당 내용 전체를 복사해서 붙여넣으면 된다.
3.4.4 APPLICATION_YML
application.yml 의 내용을 넣어주면 된다.
이렇게 총 4가지 secrets 를 생성해주었다.
5. 실행
이제 deploy.yml 까지 깃허브에 push 해서 Actions 실행을 확인해보자.
5.1 깃허브 commit / push
| git add . |
| git reset src/main/resources/application.yml |
| git commit -m "<커밋메시지>" |
| git push (origin main) |
대충.. 이 과정을 거쳐 커밋푸시했다.
application.yml 은 보안 문제로 인해 깃에 올라가지 않는다.
만약 올라갔다하더라도 지우는 것이 좋다.
secrets 으로 괜히 설정해둔 게 아니니까!
5.2 GitHub Actions 확인
이제 레포지토리에서 Actions 탭을 확인해보자.
내용을 살펴보면 build 를 했을 때와 거의 유사한 내용들이 올라옴을 확인할 수 있다.
즉, 깃에 푸시함과 동시에 자동으로 빌드까지 이뤄지고 있다는 뜻이다.
Actions 에 깃에서 당겨와 빌드하는 코드를 넣었으니까!
BUILD SUCCESSFUL 문구를 확인함으로써 빌드 완료,
successfully executed commands to all hosts 메시지를 통해 백그라운드 실행까지 됨을 확인했다.
만약 초록 체크 표시가 아닌 빨간 X 표시가 떠있다면 에러 메시지를 확인해보자.
서버포트(8070) 요청도 통신하도록 인스턴스를 새로만들고
test 코드가 실행하는지 확인해봤다.
이로써 서버 배포가 완료되었다!
'Programming > AWS' 카테고리의 다른 글
| [AWS] 웹 프로젝트 배포하기 (2) - 메모리 증설 및 자바 설치 (0) | 2025.03.06 |
|---|---|
| [AWS] 웹 프로젝트 배포하기 (1) - EC2 인스턴스 생성 (0) | 2025.03.06 |
