Carryduo | 시리즈 개요 및 CD 구축

유현준·2022년 9월 5일

Carryduo | 롤 듀오 서칭 프로젝트

목록 보기

1/8

1. 시리즈 개요

BE 2명(필자 포함), FE 1명 구성으로 LOL을 주제로 사이드 프로젝트를 시작했다.
프로젝트의 주제는 롤 듀오 서칭 플랫폼이다. 대략 다음 같은 서비스를 제공할 예정이다.

롤 계정 전적 검색
유저 간 1:1 채팅 기능
롤 계정 구독 기능
챔피언 조합(2개) 승률 데이터 제공
챔피언 상세정보 제공
이 프로젝트에 대한 시리즈를 별도로 제작한 까닭은 프로젝트를 하면서 새로 배우는 기술들 그리고 주요한 의사결정들의 근거에 대한 기록을 남기기 위해서이다. 경험컨대, 직접 만들면서 맥락적으로 경험하는 것이 기술에 대한 가장 크고 빠른 배움이라고 느꼈기 떄문에, 프로젝트를 중심으로 배운 내용을 기록하고자 한다.
이 프로젝트에서 사용해볼 주요한 기술은 다음과 같다. 프로젝트 과정에서 스택은 계속 추가될 여지가 있다.

framework
- nest.js

DB
- TypeORM
- PostgreSQL
- Redis

Infra
- AWS EC2
- AWS CodeDeploy/CodePipeLine
- Ngnix
- PM2
- github action

Library
- axios

2. 프로젝트 기본 세팅 시작.

이번 주는 함께하는 BE 팀원과 서버 인프라에 대한 스펙을 먼저 클리어하기로 하였다.
대략 다음 내용들을 이번 주에 새로 해보면서 배울 듯 싶다.

Https(Ngnix)
CI/CD(github action/AWS CodeDeploy)
무중단배포(PM2 or Ngnix)
로드밸런싱(AWS or Ngnix)

3. EC2와 프로젝트 깃헙에 CD 적용

CD는 쉽게 말하면, 지속적 제공/배포 자동화를 의미한다.
배포할 EC2 instance와 프로젝트 Github을 연동시켜서, github의 특정 branch에 새로운 커밋이 추가되면 이것이 자동적으로 EC2 instance에 배포되게끔 하는 기술인 것이다.
즉, 수동적으로 EC2 instance에서 git pull을 하지 않아도 되기 때문에, 도입만 한다면, 개발 생산성이 매우 높아질 수 있다. 그래서 다른 기술들보다 가장 먼저 챌린지하여 적용했다.
CD를 적용하는 것은 AWS 인프라에 대한 일정 수준의 이해를 요구했다. EC2, IAM, CodeDeploy 등을 직접 만져야하는데, 아직 AWS 인프라에 대한 이해 수준이 매우 낮아, 공식문서만으로 CD를 적용하는데는 한계가 있었다.
그래서 참고자료의 블로그를 거의 따라하다시피... 하면서 CD를 구현할 수 있었다. 블로그를 따라하면서 구현한 만큼, 추후에 시간을 내어, CD를 적용하기 위해 밟아야하는 각 절차/단계들이 어떤 의미인지를 정리하고자 한다.
지금 여기서 작성하려고 하는 것은 아래 참고자료에 근거하여 CD를 적용하면서, 필자가 느꼈던 점 + 이를 해결했던 점을 중심으로 작성하고자 한다.

1) CD를 적용한다는 건 CodeDeploy에 EC2를 등록하는 것 + CodePipeline으로 github 레포지토리를 CodeDeploy에 연결하는 것 두 가지를 함께하는 것이다.

단순히 CodeDeploy에 EC2를 적용하는 것만으로는 깃헙 레포지토리에 push된 commit이 자동적으로 EC2에 배포되지 않는다.
CodeDeploy에 EC2를 적용하면, EC2에 접속하지 않더라도 AWS 사이트에서 레포지토리와 커밋에 대한 정보를 기입함으로써 EC2에 배포할 수 있게 되는 것일 뿐이다. 즉, 레포지토리와 커밋에 대한 정보는 수동으로 EC2에 전달해야하는 것이다.
이를 해결해주는 것이 Code pipeline이다. code pipeline으로 깃헙 레포지토리를 EC2가 연결된 CodeDeploy에 연동하면, 깃헙 레포지토리에 push된 최근 commit을 자동적으로 EC2에 배포할 수 있게 되는 것이다.

2) appspec.yml 파일은 배포할 사버(우분투 등)의 root 경로 + 프로젝트 폴더의 root 경로에

CodeDeploy에 ec2를 적용하는 과정에서 다음과 같은 에러가 계속 떴었다.
이유는 appspec.yml 파일을 codeDeploy가 찾지 못한다는 것이었다.
참고자료에서 리드한대로 ubuntu의 root 경로(대략 etc 같은 파일이 있는 곳, cd / 로 접근 가능)에 appspec.yml 파일을 만들어뒀음에도 불구하고, 이런 에러가 떴다.
에러에서 제시된 경로에 appspec.yml을 동일하게 설치해보았으나, 제시된 경로는 커밋을 배포할 때마다 새로 생기는 경로였기에 의미가 없었다.
결론적으로, 위 에러는 프로젝트 폴더에 appspec.yml 파일을 커밋하니 해결되었다.

즉, appspec.yml은 프로젝트 root 경로 + 배포할 서버의 root 경로 모두에 필요하다.

3) EC2 태그를 미리 해주자.

CodeDeploy에 EC2를 등록하는 데에는 key-value로 구성된 태그값이 활용되므로 미리 ec2 태그를 생성해두는 것이 좋다.
태그는 ec2 대시보드에서 등록할 수 있다.

4) 배포 자동화 대상이 될 branch 생성은 미리!

깃헙 레포지토리를 CodePipeline에 연결할 때, branch를 미리 만들어두지 않아, 연결 작업을 2~3번 정도 다시 해야했다...

5) ecosystem.json의 위치 그리고 property들의 의미

ecosystem.json도 프로젝트 폴더의 root 경로에 있어야 한다.
script는 pm2 start 시 실행되어야 할 파일의 경로를 의미한다.
args는 scripts가 참조할 내용이 들어있는 경로를 의미한다.
기타 property는 아래 참고자료를 보면 좋다.

{
  "apps": [
    {
      "name": "carryduo",
      "script": "./project-carryduo/node_modules/.bin/ts-node",
      "args": "./project-carryduo/src/main.ts",
      "watch": true
    }
  ]
}

6) appspec.yml의 hook으로 afterInstall 활용하기

배포 완료된 이후에 자동화가 필요한 동작들을 afterInstall hook으로 설정할 수 있다.
요컨대, 빌드, pm2 실행 등을 지정해줄 수 있는 것이다.
hook으로 지정할 명령어는 일반적으로 scripts라는 폴더에 after.install.sh 파일을 통해 생성한다.
아래는 예시이다.

1. appspec.yml
version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/build/
hooks:
  AfterInstall:
    - location: scripts/after.install.sh
      timeout: 300


2. after.install.sh
#!/bin/bash
sudo chmod -R 777 /home/ubuntu/build

#navigate into our working directory
cd /home/ubuntu/build

#install node modules & update swagger & pm2 reload
sudo npm ci
sudo npm run build
sudo pm2 reload carryduo