Vue나 React같이 SPA로 된 프로젝트의 경우는 자바스크립트만 동작하면 돼서 서버가 필요없다고 한다. 따라서 간편하게 s3를 이용해 배포를 진행했다.
생성된 lAM 계정이 있어서 계정 생성은 생략~
배포 과정
S3 버킷 생성하기
-
지역은 서울로 설정하고 버킷 이름을 적어준다.
(만약 전에 만든 버킷이 있다면 버킷을 선택하여 설정을 복사할 수 있다.) -
이 버킷의 퍼블릭 액세스 차단 설정을 풀어주고, 버킷 키만 활성화로 변경한 후 버킷을 만들어준다.
-
객체 에서 파일을 업로드 해 준다.
vite 로 프로젝트를 생성해 주었기 때문에npm run build로 빌드 파일을 만들어 주었다. 빌드 파일(dist 폴더)에서 폴더와 폴더 안의 파일들을 전부 올려준다.(폴더를 올리고, 파일도 또 따로 올려야 한다.)
-
정적 웹사이트 호스팅
속성 창의 맨 아래에 정적 웹사이트 호스팅에 들어가 활성화를 해준다. 인덱스 문서는 전부 index.html 를 작성해준다. -
권한
권한 탭에 들어가면 버킷 정책을 작성하는 공간이 있다. 정책 생성기에 들어가서 정책을 만들어준다. 나는 정책 생성 예시 를 보고 정책을 생성해 주었다. 생성된 정책을 복사하여 붙여넣고 저장해준다.
Cloudfront 배포하기
Cloudfront 는 AWS에서 제공하는 CDN 서비스이다. https 를 사용할 수 있게 되어 보안이 보장되고 캐싱을 통해 사용자에게 좀 더 빠른 전송 속도를 제공한다는 장점이 있다.
- cloudfront 배포 생성
아직 도메인 구매를 하지 않았기 때문에 s3에서 생성한 정적 웹사이트 주소를 선택해 준다.
위 사진처럼 원본 액세스 제어 설정을 해주고, origin shield 를 활성화 시켜주었다.
기본 캐시 동작은 뷰어 프로토콜 정책에서 Redirect HTTP to HTTPS 를 선택해주고
캐시 키 및 원본 요청 부분은 추천대로 해주었다
그 다음부터는 기본값 루트 객체만 index.html 로 작성해주고 배포생성을 해준다.
- 오류페이지
403,404 설정해주기~
끗
배포 도메인 이름에 있는 링크에 접속해보면 잘 배포된 것을 확인 할 수 있다!
그리고 전대위키는 지도 api 를 사용하기 때문에 해당 주소를 등록해주면 된다~
이슈
1. 파일 업로드 시 이슈
파일을 업로드 할 때 어떤 레퍼런스를 보다가 파일과 폴더를 모두 올려야 한다고 해서 그렇게 올렸는데 흰 화면이 뜨고 403,404 에러와 함께
cloudfront Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.
라는 에러메세지가 나왔다.
그래서 레퍼런스(레퍼런스1, 레퍼런스2)를 조금 찾아봤는데 대부분의 사례가 vue 나 angular 였지만 전체적으로 경로상 문제 때문에 이런 에러가 나는 것 이라고 판단해서 html 파일의 경로를 확인해 보았다. html 파일 중 <script type="module" crossorigin src="/assets/index-a44a3059.js"> 를 보고 이렇게 경로가 있으면 폴더에서 경로를 찾을 수 없을것같아서 직접... <script type="module" crossorigin src="./assets/index-a44a3059.js"> 이렇게 경로를 수정해 주었더니 웹페이지가 정상적으로 작동했다. .. (추가로 폴더를 올리지 않고 파일들만 올리게 되면 경로는 제대로 설정이 되지만 동적으로 돌아가지 않는다는 에러가 뜨면서 화면이 꺼졌다.)
2. s3 파일 수정 후 cloudfront 에 적용이 되지 않는 문제
위에서 html 파일의 경로를 수정한 후 배포 주소로 들어갔더니...
반영이 되지 않았다. 나는 반영이 바로 되는줄 알고 엄청 땅을 팠다... 파일무효화
클라우드프론트의 파일 무효화에서 /* 를 적고 제출해주면 s3 수정이 반영이 된다. 반영하는데 시간이 조금 걸릴수도 있으니 기다려보자.
(+ 마찬가지로 배포를 잘못 만들었을때 비활성화를 한 후 5분정도 기다려야 삭제가 가능하다..! )
3. https 에서 http 에 요청 보내기
경로를 제대로 수정을 해서 화면은 띄워졌지만
Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource ...
라는 에러메세지가 나왔다. 그래서 찾아보니 https 에서 http 에 요청을 보내서 에러가 난 것 이었다. html 파일에
<meta
http-equiv="Content-Security-Policy"
content="upgrade-insecure-requests"
/>를 넣어주면 된다고 해서 넣어줬는데 Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR 라는 에러가 났다.
위의 meta 코드는 http 요청을 전부 https 로 수정해서 보내주는 코드였다. 백엔드에서는 ec2로 배포를 해서 http 만 되어있는데 https 로 보내니 에러가 난 것이라 도메인을 구매하기로 결정이 났다.
