#22 백엔드와 프론트엔드를 배포했다!

https://app.steamgamequiz.com 로 가서 트라이 해보세요~

 

이전 프로젝트인 이미지니는 GCP에서 백엔드와 프론트엔드를 배포했었지만, 이번에는 AWS에서 배포해보려고 했음.

이번에는 배포할때 겪었던 어려움과 결국 어떻게 구성했는지 다룰것임.

 

도커 활용

GCP에서 도커를 사용해 배포했었는데, 아주 좋았던 기억이 있다.

굳이 컨테이너에 ssh로 접속하지 않아도 GCP CLI 명령어를 이용하면 알아서 새로운 도커 컨테이너를 올려줬었다.

실무에서 AWS를 더 많이 쓰는것으로 알고 있는데, 당연히 AWS도 그런 기능이 “당연히” 있는 줄 알았다.

 

하지만 그런것은 없었다.

 

AWS의 EC2에서 도커를 띄울려면 직접 ssh연결해서 이미지를 pull한 후, 컨테이너를 돌려야 한다.

물론, GCP 처럼 외부에서 배포하는 옵션이 있긴 하다. 

하지만.. 보통은 빌드된 소스를 zip파일로 압축해서 S3에 옮기고 자동화된 스크립트로 실행하는 것 같다.. (스크립트를 직접 작성하는 것 같다)

 

그래서 도커를 쓰지 않을까 고민을 좀 했지만, 그래도 개발과 배포의 실행 환경을 맞추는 이점은 얻을 수 있어서 그냥 도커를 사용했다.

이전에 하던것 처럼 docker hub에 이미지를 올리고, 그 이미지를 받아서 컨테이너를 띄우는 방식이다.

 

프론트는 Netlify에서 배포

AWS는 프리티어에서 EC2를 단 하나밖에 돌릴 수 없다. (정확히는 러닝 시간으로 계산하는데, 하루죙일 돌리면 하나밖에 못돌린다) 

GCP는 그러한 제한이 없었다는 것과 정말 비교되는 부분이다.

 

그래서 프론트는 Netlify에서 배포했다. 

Netlify는 프론트에 최적화되어 있는 정적 웹 호스팅 업체인데, 무료한도가 널널하고 깃허브와 연동성이 상당이 좋다.

내 레포지토리에서 front-release 브랜치에 새로운 커밋이 올라오면 frontend 디렉터리에서 코드를 빌드할 수 있게 설정해두었다.

 

원래 Netlify는 도메인주소도 제공해준다. 그렇지만, 이 프로젝트는 이미 Namecheap에서 사둔 도메인 “steamgamequiz.com”가 있기 때문에 외부 DNS를 사용했다. (아래서 이어 설명함)

 

DNS는 cloudflare!

AWS도 DNS가 있다. 하지만 cloudflare가 더 사용하기 좋은 것 같아서 DNS는 cloudflare를 사용했다. (비용도 부과된다.)

AWS는 그저 ec2에 elastic ip를 할당하고 elastic ip를 cloudflare의 레코드로 도메인에 매핑하는 것으로 설정했다.

 

cloudflare는 인증서도 무료로 제공(공용이라고 함.. 보안성이 있는지는 모르겠음, netlify에서도 제공하는데 이건 let’s encrypt를 사용한다)하고, 모니터링 UI가 잘 되어있어서 좋은 것 같다.

 

cloudflare에서 백엔드와 프론트엔드의 도메인은 이렇게 할당했다.

백엔드: api.steamgamequiz.com (A레코드)

프론트엔드: app.steamgamequiz.com (CNAME레코드)
APEX 도메인인 steamgamequiz.com은 백엔드에 매핑해놓고, cloudflare의 리다이렉트 rule를 이용하고 있다. (steamgamequiz.com -> app.steamgamequiz.com, A record에 매핑한 도메인만 리다이렉트 된다고 해서…. 아닐수도 있음)

 

원래는 APEX 도메인을 프론트엔드에 바로 매핑하고 싶었는데, 접속시 연결이 끊기는 오류가 빈번해서 서브도메인인 app에 매핑했다.

netlify에서는 서브 도메인을 매핑하라고 권장한다. APEX 도메인의 경우 netlify의 로드밸런서의 주소를 매핑하게 되는데, 이것이 느릴 수도 있다는 것 때문이다.

 

현재까지의 인프라 구조

뜬금없이 엘라스틱서치가 등장했지만, 사실 이전부터 엘라스틱 서치에 대한 도입을 고민했었다. 

(이전 번호의 게시글에 해당하는 글이 있으나, 조각조각나서 추후 한번에 올릴예정이다)

 

현재까지의 화면단