0. 시작전
대부분의 프로젝트는 동적 웹페이지 방식으로 배포를 한다.
하지만, 간혹 정적 웹페이지를 간단히 배포하여 사용할일이 있다. 그게 바로 오늘이다..
오늘 받은 요구사항을 요약하자면 아래와 같다.
- 일회성 프로젝트라 수정할 일이 없음
- 클라우드 프론트 주소가 아니라 깔끔한 도메인주소로 보일 것
이전에도 비슷한 경험이 있었는데, 그땐 순수 html,JS,CSS 만으로 구성된 코드였다. 순수 html은 폴더만 업로드하면 되므로 매우 간단했다.
그때와 달리 React.js, Next.js의 경우 모두 빌드하는 방법이 다르니 주의해야한다. 이번 프로젝트의 경우 Next.js 프로젝트 였으므로 이 경우만 설명하도록 한다.
또한, 기존 배포와 Next.js 환경하에서 배포하는 방법의 차이를 중점으로 설명할 것이기때문에 공통적인 부분은 빠르게 생략하고 넘어갈 것이다.
1. IAM
- 사용자 등록
2. Route53
2.1 호스팅 영역 생성
- 기존에 생성해둔 도메인을 이용하거나 새롭게 도메인을 생성한 뒤, 클릭
2.2 레코드 생성
- 레코드 이름은 내가 배포할 도메인주소와 일치 하도록 만들어 준다.
- 레코드 유형은 A
- 트래픽 라우팅 대상은 CloudFront로 해주면 아래에서 자동으로 해당 주소를 선택할 수 있다. (따라서, 원래는 이 단계 이전에 CloudFront를 만들어 둬야함)
3. S3
3.1 버킷 만들기
버킷 이름은 추후에 생성할 대체 도메인 주소와 동일하게 지어야 한다.
버킷만들기는 aws를 경험해본 사람들이라면 아주 익숙할 것이다.
하지만 클라우드프론트와 도메인을 연결할 때 아주 중요한 포인트가 있다.
그건 버킷이름을 꼭!!! 대체 도메인주소와 동일하게 만들어야 한다는 것이다.
다시 한번 강조, 또 강조하자면, 버킷은 수정이 불가능하기 때문에 다 만들고 이것때문에 삭제 후 재생성하는 실수를 많이 저지르기 때문이다.
3.2 업로드
정적 사이트 배포는 깃을 연결한다던가 이런 작업을 하지않고, 냅다 파일을 올려버린다.
이때 Next.js는 조금 다른 방식으로 배포를 해야한다.
next export명령어를 이용하여.out폴더에 모든 페이지를 정적 HTML 파일로 내보내기
관련된 자세한 내용은 Next.js 공식 문서의 정적 HTML 내보내기를 통해 확인할 수 있다.
https://nextjs.org/docs/advanced-features/static-html-export
아무튼 이렇게 생성된 .out 폴더를 버킷에 업로드 해주면되는데, 한가지 더 주의할 점은 파일추가, 폴더추가 버튼이 분리되어있다는 점이다.
(파일추가를 누른뒤, 모든 파일들을 선택해서 업로드를 했는데 에러가 뜨길래, 알고보니 폴더는 추가가 안됐더라; 오로지 파일만... 올라가있다. 그리고 분노하며 폴더를 올렸는데 이번엔 폴더는 하나씩 하나씩 눌러야한다.. 빠트린 파일이나 폴더가 없는지 잘 확인해야한다.. 아무튼 요약하자면..)
파일추가, 폴더추가 둘다 눌러서 빠트린 파일, 폴더 없도록 꼼꼼히 업로드 하기!
3.3 속성 > 정적 웹 사이트 호스팅
편집을 누르고 활성화해준다음 인덱스문서도 야무지게 적어준다.
(간혹 업로드한 폴더 시작점이 index가 아니라 상위폴더부터 시작할 경우 index가 인식이 안될 수 있으니, 주의해야한다.)
3.4 버킷 웹사이트 엔드포인트 생성
여기까지 했으면 속성의 제일 하단에서 정적 웹사이트 엔드포인트 주소가 생성된다.
클릭해서 잘 돌아가는지 확인해주고 다음 단계로 넘어간다.
3.5 권한
권한, 정책 관련 부분은 aws를 다루며 자주했던 내용이니 생략한다.
4 CloudFront
4.1 배포 생성
생성 과정은 평소처럼 해주면되고..
대망의 대체 도메인 이름에 S3 버킷생성에 사용했던 동일한 이름으로 적어주면 된다.
대체 도메인 이름은 버킷이름과 동일하게 만들어야 함
5 작업을 마친 뒤
모든 작업을 아무 문제 없이 끝냈는데 대체 도메인으로 접속이 안되는 문제가 발생했다..
클라우드 프론트주소나, 버킷주소로를 통해서는 잘만 돌아가는데 도대체 왜?! 대체 도메인만 안되는 건지 도무지 이유를 알수가 없었다.
혹시 오타가 있을까봐 버킷을 지웠다가 만들었다가.. 처음부터 다시 반복해보고 1시간을 끙끙 거리고 있었는데 문제의 해결방법은 아주 허탈했다.
기다리면 ... 된다
문제의 원인은 CloudFront의 캐시가 남아있어서였는데, 내 예상보다 아주 오래 지속되었고 캐시문제라고 전혀 생각하지 못했다.
이번 경험을 통해 TTL 설정에 관한 것도 공부가 필요하다는 것을 느꼈다.
신속하게 대응해야하는 경우도 있을텐데, 캐시가 삭제될때까지 하염없이 기다리기 보다 직접 삭제하는 방법(캐시무효화)을 익혀야할 것 같다.
