지금까지 저는 netlify나 vercel을 이용해서 간단한 배포만 해왔었는데요,,!
Bridge 프로젝트를 진행하며 처음으로 직접 도메인 연결&배포,,! 을 해야하게 됩니다.
((그 이유는 프론트가 저 혼자이기 때문입니다.......))
아무튼
험난했던 저의 AWS EC2 첫 배포 도전기를 기록해보겠습니다!
😟 사실 처음엔 포기를 했었습니다 . . .
사실 처음에 aws로 배포를 시도했다가 포기했습니다.
여러 블로그들을 참고하여 ec2 인스턴스까지는 만들었으나,, 도저히 서버에 업로드하는 방법을 이해하지 못했습니다.
에라 모르겠다...는 심정으로 그냥 netlify로 배포를 하고, netlify에서 지원해주는 서비스를 이용해 도메인을 연결해주었습니다.
🤓 돌아온 AWS 배포
저희 프로젝트가 사용하는 도메인 구조는
프론트 - www.bridgeai.co.kr
백 - api.bridgeai.co.kr
입니다.
도메인을 공유하지만, 서브 도메인을 통해 서버를 분리합니다!
예전에 했던 프로젝트에서는 백과 프론트 서버의 도메인을 완전히 분리하였기 때문에 이런 구조 역시 처음 접해보아 재밌는 경험이었습니다 🤧
백엔드 서버를 도메인을 사용하여 재배포하게 되면서,
1. 도메인을 aws-Route 53을 통해 라우팅하였고
2. 기존에 연결해두었던 netlify용 DNS에서 aws용으로 도메인의 네임서버를 변경하게 됩니다.
=> 따라서 netlify로 배포해두었던 프론트 서버는 제대로 도메인에 연결되지 않아 재배포를 해야하는 상황이었습니다.
처음에는 계속 netlify를 사용하여 배포할 생각이었으나, 이번 프로젝트를 기회로 aws로 직접 배포해보고 싶어 이번에는 정말 aws를 사용해보기로 결심했습니다! 🔥🔥🔥
💻 EC2 인스턴스 생성하기
EC2 ?
AWS에서 제공하는 클라우드 컴퓨팅 서비스로, 하나의 큰 컴퓨터를 빌려주는 개념이라고 한다.
AWS에서 제공하는 URL을 통해 이 컴퓨터에 접근할 수 있는 것이다.
EC2 인스턴스 ?
클라우드의 가상 서버.
말 그대로 EC2의 인스턴스라고 생각하면 편할 것 같다.
따라서 프론트 코드를 배포하기 위한 서버가 하나 필요하므로
-> 프론트용 인스턴스를 하나 생성해준다!
생성하는 방법은 다음 블로그들을 참고하였다.
AWS EC2 프론트 배포 이렇게만 해보자.
aws ec2 프론트배포 어렵지 않다.
velog.io
여기서 네트워크 설정 - 보안 그룹 파트에서 포트를 열어주는데, http(80)와 https(443) 이외에
우리는 프론트를 배포할 것이므로 3000을 추가로 열어준다!
💻 EC2 인스턴스 접속하기
인스턴스를 생성했으면, 프론트 코드를 서버에 올리기 위해 서버에 접속해야 합니다.
터미널에서 인스턴스에 접속하는 방법은
만든 인스턴스 우클릭 -> '연결' -> SSH 클라이언트 탭에 있는 예시를 터미널에 복붙 해주면 됩니다!
⚠️ 이때 서버에 접속하는 경로(현재 터미널 경로)에 키페어 파일이 존재해야 합니다.
아니면 그냥 키페어 파일의 경로를 적어줘도 됩니다!
접속에 성공하면, git clone을 통해 서버에 올릴 프로젝트를 다운받습니다.
이때, 인스턴스에는 노드가 없으므로 직접 설치해줍니다. 그리고 로컬 서버에서와 같이 서버를 실행시켜주면 끝!
환경변수를 사용하셨다면, vi를 통해 서버에 .env 파일을 생성해주면 됩니다!
(netlify나 vercel은 따로 환경변수를 설정해주는 곳이 있어서.. 처음에 어떻게 설정해야할지 당황했어요💦)
🧐 무중단 배포의 필요성
그러나 이렇게만 하면 내가 로컬에서 터미널을 끌 경우, npm도 동시에 종료되므로 상시에 서버를 켜둘 수 없습니다.
즉, 배포를 해도 내 컴퓨터가 꺼져있으면 다른 사람 아무도 못들어오는 셈,,,, ㅎㅎ
배포하나 마나인 상황이 됩니다..!
(전 그걸 모르고... 배포 성공했다! 좋아했다가 몇 시간 뒤에 다시 안된다길래 좌절했습니다 .......하핫)
따라서 pm2를 이용해 백그라운드 실행을 시켜 무중단 배포를 해주었습니다!
pm2 서버가 제가 터미널에 접속하지 않더라도 계속 npm 서버를 실행시켜줍니다.
(저는 pm2를 설치할 때 알 수 없는 에러가 나서 force 설치를 했던 것 같습니다!)
pm2 설치
sudo npm install -g pm2@latest
serve 라이브러리 설치
sudo npm install -g serve
코드 실행
pm2 serve [빌드된 폴더의 경로] [포트번호] --spa
알아두면 쓸모있는 pm2 명령어
- 리스트 확인 : pm2 list
- 중지 : pm2 stop <app_name>
- 재시작 : pm2 restart <app_name>
- 삭제 : pm2 delete <app_name>
😵💫 빌드/배포 자동화의 필요성
성공적으로 배포는 했으나, 또 한가지 문제점이 있었습니다.
바로 배포 자동화를 하지 않은 것인데요!
배포 자동화를 하지 않으면,
pm2는 정적으로 빌드된 파일을 돌리고 있는 것이므로 코드를 수정하더라도 알아서 반영이 되지 않습니다.
따라서 코드를 수정할 때마다 직접 서버에 접속하고, 다시 코드를 pull 받아서 npm run build를 다시하고.. pm2 서버를 다시 켜고...를 반복해야 하는 셈이죠,,
그래서 배포 자동화에 대해 검색해봤더니 깃허브 액션을 통해 쉽게 자동화(CI/CD)를 할 수가 있었습니다!
(CI는 빌드 및 테스트의 자동화, CD는 배포의 자동화)
깃허브 액션은 프로젝트 레포에 뭔가 변화가 있을때마다 해당 스크립트를 실행시켜주는 서비스입니다.
따라서, 저희의 상황에서는
깃헙 레포의 배포 브랜치에 push가 일어날 때마다, 서버에서 최신 버전의 코드를 pull 받고, 다시 서버를 실행해주는 스크립트를 작성하면 배포 자동화가 되는 것입니다!
https://iamjooon2.tistory.com/25
Github Action을 이용한 EC2 자동배포 적용기
이전 프로젝트에서 배포를 담당했다. main 브랜치에 팀원들의 개발 내역이 머지되면, EC2에서 브랜치를 pull 하는 방식으로 배포를 진행했는데, 이 과정이 정말 너무나도 번거로웠다. 그래서 다음
iamjooon2.tistory.com
깃헙 액션은 위의 블로그를 참고하여 설정하였습니다!
그런데 스크립트까지 그대로 가져가면 에러가 날 수 있습니다,, (는 제가 그랬거든요......)
저는 스크립트를 다음과 같이 수정하였습니다.
스크립트 작성하는 꿀팁(?)은 자동화를 하기 전에 배포하기까지 자기가 어떤 코드를 적었는지를 되짚어 보면 됩니다...!
거기에 git pull만 끼워넣어주면 끝!
script: | # 실행할 스크립트
cd Bridge
git pull origin main
pm2 kill
npm i --force
npm run build
sudo npm install -g serve
pm2 serve build 3000 --spa
이렇게 여러 시행착오 끝에,,, ec2 배포 -> 무중단 배포 -> 배포 자동화까지 완료!
이번 프로젝트를 통해 처음으로 aws로 배포도 해보고, 말로만 들었던 무중단 배포와 배포 자동화가 왜 필요한지에 대해 몸소 깨달을 수 있는 기회가 되어 배울 점이 아주 많았던 것 같습니다!
처음엔 ec2 서버에 접속하는 방법도 몰랐었는데,, 이제는 어느정도 익숙해진 것 같아 제 자신이 대견하군요 (껄껄) 학교 과제를 할 때 putty로 cspro 서버에 접속해서 하는데, cspro 서버 대신 ec2 서버에 접속해서 한다고 생각하니까 쉽게 이해 완료🫡!
특히 경험해보고 싶었던 Github Actions를 통해 CI/CD를 여러 실패 끝에,, 성공하여 매우 뿌듯합니다 ✨
이번 기회에 CI/CD의 뜻도 제대로 알고 가는 것 같습니다 💨💨
'📂 에러로그' 카테고리의 다른 글
| 라이브러리 사용하기 전에 꼭! 버전 체크하기 💥 (5) | 2024.08.23 |
|---|---|
| Next.js에서 svg 파일을 사용하며 겪은 일 (0) | 2024.08.02 |
| useFunnel과 zustand 동시 사용 시, state 초기화 문제 (0) | 2024.03.05 |
| Router.replace를 사용하게 된 이유 - 뒤로가기의 무한 굴레 (1) | 2024.02.27 |
