Day30
Project deploy - EC2
- 프론트 엔드 배포를 어떻게 할지에 대해 공부한다.
- 서비스들
- Amazon Cloudfront + S3
- Github Pages
- Firebase Hosting
- Netlify
- Vercel
- 기본적으로 History API 기반의 SPA를 배포하려면 해당 서비스에서 404 에러에 대해 처리할 수 있는 옵션이 필요하다.
- 직접 서버에서 호스팅하기 - 가장 자유도가 높음.
- 클라우드 업체에서 제공하는 서버에서 직접 호스팅하는 방법
- EC2 : 제일 복잡하고 난이도가 있는 방법
- Google Cloud Platform :
- Azure
- Naver Cloud Platform
- Cafe24
- iwin
- Oracle Cloud
- 면접볼 때도 만든 서비스를 배포를 진짜로 해봤는지 운영은 어떻게 하는지를 많이 물어본다. 해봤다면 가산점 多
- 포트폴리오를 첨부할 때 본인이 배포한 사이트의 주소를 넣으면 굉장히 좋다.
AWS S3 + cloudfront
- S3 : 파일들을 저장하는 서버
- 버킷 : 파일 저장하는 폴더
- 배포와 운영이 많이 어렵다(불친절하다).
Github Pages
- 공짜다.
- npm gh-pages 플러그인을 사용하여 배포를 할 수 있다.
Firebase Hosting
- 개인 사용자는 무료이나 일정량 이상의 트래픽이 넘어가는 경우에만 과금을 한다.
- npm firebase-tools 플러그인을 사용하여 배포할 수 있다.
- github와 연동해서 github 소스 상의 변화가 감지되면 자동으로 재빌드 및 배포해줄 수 있따.
Netlify
- 위 세 가지 배포 서비스보다 훨씬 더 배포가 쉽고 간단하다.
- 브랜치가 변경이되면 해당 브린치 전용 배포를 볼 수 있다.
- netlify가 쓰는 서버에 한국이 없다. → 접속이 느리다.
Vercel
- Netlify와 비슷하지만 한국 서버가 존재한다.
- Next.js라는 도구를 만드는 회사이다.
- 14일 무료 평가 기간이 끝나면 과금되기 때문에 조심해야 한다.
- history api를 썼을 때의 404 문제가 netlify와 동일하게 발생한다.