"직접 배포를 해보신 적이 있나요?"
"우대사항 : 서비스 배포를 경험하신 분"
..
배포는 프론트엔드 채용 공고나 면접에서 빠지지 않고 등장하는 주제 중 하나다.
하지만 나와 같이 이미 서비스가 되고 있는 프로젝트에 참여하거나,
별도의 인원이 배포를 담당해서 진행하는 경우에는 배포를 실무에서 경험하기가 쉽지 않다.
그렇다고 아예 모를 수는 없으니, 공부를 해보도록 하자!
🚨 공부를 위한 글이라, 정확하지 않은 정보가 포함되어 있을 수 있습니다. 🚨
Netlify로 배포하기
배포할 수 있는 툴은 Netlify이외에도 다양하나, 가장 많이 들어본 걸 활용해보기로 했다.
👍🏻 Pros
빠르고 쉽게 배포 가능
|
👎🏻 Cons
최적화가 어려움
직접 Netlify를 활용해보니, 왜 프론트엔드 배포 뉴비들이 이걸 쓰는지 바로 알겠더라.
시키는 대로 몇 가지만 클릭하면 배포 자체도 간단하게 될 뿐 아니라,
netlify.app의 서브 도메인으로 개인화된 도메인을 생성할 수도 있고
커밋에 따른 자동 배포도 설정할 수 있으니 매우 편안한 툴!!
사실 나는 배포 테스트를 위해 간단하게 만든 프로젝트를 적용한 터라,
추가적으로 설정이 필요하다는 부분이나 최적화가 어렵다는 부분까지는 확인하지 못했다.
하지만 가볍고 별도의 최적화가 필요하지 않은 프로젝트의 경우에는 충분히 활용이 가능할 듯 했다.
배포 방법은 아주 간단하기도 하고, 참고할 수 있는 다른 글이 많기 때문에 별도로 적지는 않겠다.
Netlify 배포 방법 참고 링크 (예시)
🚨 에러 탐험기 🚨
나는 CRA 없이 세팅한 프로젝트를 배포했는데 웬걸.. 이미지가 나오지 않는 것..!!
한참 폭풍 검색을 했는데, 찾아낸 이유는 어이없게도 배포가 아니라webpack설정에 있었다. 이미지 빌드를 위한file-loader설정을 하고index.js에 import 해주고 나니 정상적으로 빌드 되는 걸 확인할 수 있었다. (필요한 이미지를index.js에 임포트하는 것 이외의 방법이 있다면 알고 싶다!!)
모두들 저와 같이 멍청한 실수는 하지 않기를.....
S3 + Cloudfront로 배포하기
👍🏻 Pros
Netlify보다 세부적으로 설정할 수 있는 부분이 많음
|
👎🏻 Cons
정적 웹사이트가 아닌 경우 사용 불가 (SSR)
What is Amazon S3?
Amazon S3(Amazon Simple Storage Service)는 객체 스토리지 서비스.
데이터는 버킷이라고 불리는 리소스에 객체로 저장되며, 정적 웹사이트 호스팅을 지원한다.
여기서 말하는 정적 웹사이트는 동작이나 변화가 없는 웹사이트가 아니라
HTML, CSS, JS 파일이 항상 동일한 리소스인 것을 의미한다.
이에 대해서는 너무나도 잘 설명해놓은 블로그가 있어 아래 링크로 첨부한다!!
S3는 정적 웹사이트만 호스팅을 지원하기 때문에 프론트 서버에서 HTML & JS 파일을 새롭게 생성하는 SSR을 활용할 때는 사용할 수 없다.
또한 S3 웹사이트 엔드포인트는 HTTPS를 지원하지 않아, Amazon Cloudfront를 함께 사용하는 것이 좋다. (추가적으로 성능 & 보안 강화도!)
What is Amazon Cloudfront?
뛰어난 성능, 보안 및 개발자의 편의를 위해 구축된 콘텐츠 전송 네트워크(CDN*)
- 자동화된 네트워크 매핑 및 인텔리전트 라우팅을 사용하여 전 세계에 분포된 상호 접속 위치(PoP - Point of Presence)를 통해 데이터를 전송
- 트래픽 암호화와 액세스 제어를 통해 보안을 개선하고 AWS Shield Standard를 사용하여 추가 요금 없이 서비스 거부(DDoS) 공격으로부터 보호
- 비용, 성능 및 보안의 균형을 맞추도록 서버리스 컴퓨팅 기능을 사용하여 AWS 네트워크 엣지에서 실행하는 코드를 사용자 지정
- 높은 전송 속도로 소프트웨어, 게임 패치 및 IoT 업데이트를 전송하도록 자동으로 크기를 조정
How to deploy a project with S3 + Cloudfront?
IAM권한 설정 (새로 생성하는 것 기준)IAM페이지의 사용자 탭으로 이동하여 사용자 추가 (따로 콘솔 권한은 주지 않음)- 직접 정책 연결을 통해
AmazonS3FullAccess&CloudFrontFullAccesss권한 부여 - 생성한 사용자를 선택하고 보안 자격 증명 탭에서 액세스 키 생성
S3에서 버킷 생성- 사용 용도에 맞게 권한 등은 수정
- Cloudfront를 함께 사용할 것이므로 퍼블릭액세스는 차단
- 생성한 버킷에 코드 업로드
- build 후 복사 붙여넣기를 할 수도 있고
- AWS CLI를 통해 업로드 할 수도 있다
Cloudfront에서 배포 생성- 원본 도메인/Origin Domain : 방금 생성한
S3선택 - S3 버킷 액세스 : Legacy access identities 선택 후 OAI 생성
- 버킷 정책 : 자동 정책 업데이트 선택
- 뷰어 프로토콜 정책 : Redirect HTTP to HTTPS
- 원본 도메인/Origin Domain : 방금 생성한
- 생성한
Cloudfront내에서 기본 루트 객체index.html로 변경 Cloudfront의 오류페이지 탭에서 오류 설정
사실 모든 옵션은 내가 어떤 걸 원하냐에 따라 달라질 수 있다고 생각한다.
나는 내가 생각했을 때 편리하거나 필요하다고 생각하는 옵션 기준으로 설정하였으니
참고만 하기를 바란다.
EC2로 배포하기
여기까지 단숨에 오니 사실 좀 지쳤.....
EC2는 당장 쓸 일이 많을 것 같지 않기도 하고,
다른 방식의 배포 과정을 경험하다보니 원하는 옵션에 따른 여러 설정값을 잘 지정해주면 될 듯 싶어
참고할 수 있는 링크만 우선 기록해보려고 한다.
추후 실무 혹은 개인 프로젝트를 EC2로 배포하게 된다면 다시 한 번 그 삽질기를 남겨보도록 하겠다
📝 용어 정리
✏️ CDN (Content Deliver Network / 콘텐츠 전송 네트워크)
데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크
지리적으로 분산된 여러 개의 서버가 연결되어 있어, 콘텐츠를 사용자의 물리적 위치와 가까운 프록시 서버에 캐싱함으로써 전송 속도를 높일 수 있다.
= 서버와 사용자 간의 물리적 거리를 좁혀 컨텐츠의 로드 지연(로딩)을 최소화!!
이걸 내가 이해한대로 번역하면,
콘텐츠의 복사본을 여러개 만들어 각 지점(PoP)에 캐싱해두고 가까운 곳에서 빠르게 꺼내 주는 것
✏️ CI / CD (Continuous Integration / Continuous Delivery or Deployment)
애플리케이션 개발 단계를 자동화하여 더 짧은 주기로 고객에게 제공하는 방법
-
CI
개발자를 위한 자동화 프로세스로빌드 & 테스트 자동화
새로운 코드 변경사항이 정기적으로 빌드 & 테스트 되어 공유 리포지토리에 통합되어,
여러 명의 개발자가 동시에 작업을 하더라도 충돌을 줄일 수 있음 -
CD
배포 자동화 프로세스
코드 변경에 문제가 없을 경우, 사람의 개입 없이 프로덕션에 자동적으로 반영
