항해99 11주차(2021.5.17-5.23) WIL : 5주 과정 실전프로젝트 4주차, https로 배포하기.

지난주까지 최소한으로 목표했던 기능들은 구현했으니, 버그를 잡고 추가 기능들을 덧붙이는 작업들을 했다. 그리고 드디어 https 도메인으로 배포하기까지 했다. 하지만, https로 배포하기까지는 여러 삽질이 동반된 장대한 여정이 필요지만, 알고나니 15분컷으로 바뀌었다. 

https 배포 : 모르면 삽질 5시간, 알면 15분컷으로 끝

https로 배포하게 된 이유는 크게 두가지이다.

1. html5부터 쓸 수 있게 된 geolocation으로 접속한 위치를 지도상에 표시하고, 접속한 위치로 이동시키는 기능을 구현해 놓았는데, 이걸 쓸 수 있으려면 보안문제로 인해서 https에서만 사용이 가능하다.

2. 이 사이트는 https 도메인을 씀으로써 사용자들에게 보안상 안전함을 알려주기 위해서다.

 

https 도메인을 사용하는 방법을 검색해본 결과, AWS에서 도메인 구입부터 https로 배포까지 모두 처리할 수 있음을 알게 되었다.  그래서 먼저 AWS Route53에서 도메인을 구입했다.

먼저 Route53에 들어가면 보이는 저 도메인 등록의 파란색 도메인을 클릭하면 아래와 같이 나오는데,

여기서 도메인 등록을 클릭하면

이렇게 사용 가능한 도메인이 나오는데, 여기서 마음에 드는 도메인을 골라서 계산하면 된다.

이 다음에 할일을 적어보면1. 구매한 도메인 이름과 같은 이름의 AWS S3 버킷을 하나 만들고, 그 안에 yarn build로 빌드한 파일들을 저장한다. 2. ACM(AWS Certificate Manager) 에서 SSL 인증서 받기(반드시 리전을 미국 동부 버지니아로 설정해야 한다!!!)3. AWS Cloud Front에서 SSL을 등록하는 등 여러 설정을 해주어서 SSL을 이용한 https 호스팅을 지원 받는다. 참고로 AWS Cloud Front는 CDN(Contents Delivery Network) 서비스를 지원해준다. 4. 다시 AWS Route53에 접속해, 구매한 도메인 계정에서 필요한 설정을 해준다. 

이렇게 1번부터 4번까지 과정을 하면 https로 배포하게 된다. 말할 것도 없이 백엔드에서도 서버 url을 https 도메인으로 설정해줘야 백엔드 서버와 데이터 통신이 가능하므로 백엔드에서도 https로 배포해야 한다.

하지만, 우리조, 정확히는 우리조 프론트엔드팀은 장장 5시간에 걸친 삽질을 해야 했다. 다행히 삽질이라도 배포는 성공하게 되었고, 우리 프론트엔드팀은 같이 방법을 찾아내어서 https 배포를 15분컷으로 할 수 있도록 방법을 정리하게 되었다. 15분컷이라고 자신있게 말할 수 있는 것은, 다른 조 프론트엔드에서 https 배포를 도와달라고 했을 때 도와주면서 15분으로 끝내줬기 때문이다.

 

사실 다른 여러 블로그를 따라하면 누구나 다 할 수 있다. 하지만 그 블로그들에는 헛점이 있다. 바로 디테일을 알려주지 않는다는 것. 그 디테일만 블로그들이 알려줬더라면, 나는 처음부터 15분컷으로 배포를 끝냈겠지만 그렇지 않아서 5시간을 빙빙 돌아야했다. 그래서 그 아쉬움에 15분컷을 달성할 수 있는 디테일을 채워넣은 TIL을 적었다. 아래는 그 링크다.

https://heo-dev-0229.tistory.com/32

항해99 81일차 TIL : https로 배포하기(feat. AWS SSL 인증, ACM, 아마존 클라우드 프론트)

 

하지만, 예상하지 못한 다른 문제가 발생했다. 

https로 배포한 도메인에서는 https로 배포된 서버와 데이터 통신을 해야 한다. 그런데 위의 오류메시지처럼, https url로 배포된 서버로 데이터 요청을 하지 않고 지난주에 http로 가배포 했을때 처럼 http 서버로 데이터 요청이 들어가고 있었다.

  

이 문제를 해결하기 위해서 프론트와 백에서 여러 시도를 해보았지만 모두 실패로 돌아갔다. 프론트도 백도 왜 http 서버로 요청이 들어가는지 이유를 밝혀 내지 못하고 전전긍긍할 뿐이었다. 왜냐면 프론트와 백엔드 모두 https끼리 통신할 수 있게 코드를 작성해뒀기 때문에, http 서버 url이 갑툭튀한걸 설명하지 못했다. 이 문제로 인해서 우리팀은 반나절동안 대혼란이었다.

 

하지만 이 문제는 아주 허무할 정도로 쉽게 풀렸는데, 문제의 원인은 http로 가배포한 S3버킷에다가 https 도메인을 연결했던 것이 문제였던 것이다! 그래서 S3버킷은 원래 세팅된대로 http서버에다가 요청을 하고 있었기 때문에 저런 문제가 생긴것으로 추정이 된다. 리액트 튜터님도 S3버킷에 도메인은 1개만 연결해야지 2개 이상을 연결해선 안된다고 했다. 그리고 S3 버킷의 이름은 도메인 이름과 같게 해야 하는게 원칙이라고도 하셨다. 이런 원리를 모르고 어차피 빌드 파일은 같으니 굳이 S3를 새로 만들 필요가 있냐는 안일함에서 새 S3를 만들지 않아서 생긴 대참사였다.

 

그래서 https 도메인의 이름으로 된 S3버킷을 새로 만들어서 세팅을 새로 했더니 문제가 해결 되어서 서버와 통신도 문제가 없어졌다. 이런 실수로 반나절을 날린게 아쉽고 팀원들도 혼란스럽게 해서 많이 미안하지만, 그래도 이런 실수를 다시는 범하지 않게 되었다는 점을 위안거리로 삼았다.