사이드 프로젝트 - Dotto 개발 일지 - 프론트 배포

프론트는 넷리파이를 통하여 정적 웹 호스팅을 하였고, 백엔드의 경우 aws 에 배포하여 운영하고 있다.

문제는 프론트는 HTTPS, 백엔드는 HTTP 이기 때문에 프론트에서 백엔드로 API 호출 시 Mixed Contents 에러가 발생하게 된다.

 

도메인 구입부터 해서 배포까지 모든게 처음이다 보니까 문제를 해결하는데 있어서 두달 가까이 걸렸다...

 

가비아에서 도메인을 구입 후 처음했던 부분은 넷리파이의 DNS 정보를 가비아에 등록하였고, 구입한 도메인으로 사이트가 잘 들어가져 괜찮을 줄 알았지만 백엔드가 문제였다.

프론트는 HTTPS 로 올라가져있고, 백엔드는 HTTP 인데 Route53에 도메인이 등록되어있지 않기 때문에 ACM을 사용하지 못하였다. 그래서 생각했던 건 ssh 키를 발급받아서 ACM에 업로드 시키자 였다.

그래서 프론트와 백엔드에 동일한 인증서를 사용하자해서 도메인에 대한 인증서를 발급하는게 첫 번째 목표였다.

찾아보니 certbot을 통하여 인증서를 발급받을 수 있다고하여 여러 사이트를 돌아다녔다.

터미널에 cerbot을 다운받고 이것저것 해보는데 계속 unauthorzied 에러가 발생하는 것.

인증서를 받기 전에 도메인 확인을 위해 TXT Record 정보를 확인하는데 이를 도메인 정보에 넣어주지 않아서 발생한 문제였다.

(이 부분도 해결하는데 오래걸렸다.)

 

 

넷리파이 도메인 정보에 TXT 등록해주고 도메인 확인까지 끝냈는데 또 다른 문제점 발생..

발급 받은 인증서를 꺼낼 수 없었다... 악!!!!!!!!🤬🤬🤬🤬🤬

 

넷리파이에 프론트를 배포했기 때문에 인증서를 꺼낼려면 넷리파이 서버에 접근을 해야하는데 접근이 안돼... 미쳐버려...

어떡해든 꺼내보려고 리액트 라우트 경로도 추가해보고.. 백엔드 ec2에 cerbot을 설치해서 자바에 인증서 파일 위치를 임의로 만들어보고... 그 마저도 안되서 jar 뜯어다가 임의로 디렉토리도 추가해보고... 다 안됨..

 

(왜 이렇게 이상하게 하나 생각할 수도 있지만 처음이잖아요..ㅎㅎㅎ 안될 것 같아도 그냥 일단 해보는거죠..ㅎ)

 

결국 다 실패하고 다른 방법을 찾아보자 해서 프론트 배포를 aws로 바꿨다..😭

aws 로 바꾼 이유는 Netlify 서버에 접근해서 ssh key를 가져오는데 실패했으니까 접근이 가능한 서버에 프론트를 배포하여 키를 가져오자 하여 바꾸게 되었다.

 

회사 프로젝트야 부장님께서 인프라를 잡아주시니까 별다른 설정없이 사용했지만 개인적으로 aws에 배포를 해보는건 처음이다 보니 문제를 해결하는데 오래 걸렸다..

 

처음하다 보니 여러 블로그 글을 보면서 따라하는 방법밖에 없었다.

그래서 무작정 따라하면서 배포를 시작하였는데 EC2 에 배포하면서 발생한 몇가지 문제점이 있었다.

 

1️⃣ React Build 실패..

2️⃣ 터미널에서 EC2 접근이 안됨

3️⃣ 80 -> 3000 forwarding 실패

 

첫번째. 빌드의 경우 찾아보니까 프리티어 성능 문제였다.

아무래도 무료 계정을 사용하다보니 EC2의 성능이 좋지 않은데 프로젝트를 빌드하면서 메모리 이유 때문에 EC2가 죽어버리는 것.

2 가지 방법을 찾았는데 그 중 하나가 build script에 GENERATE_SOURCEMAP=false 주어 GENERATE_SOURCEMAP 옵션을 꺼주는 방법이었는데.. 안되더라

 

SOURCEMAP 이란??

 

소스맵(source Map)이란 배포용으로 빌드한 파일과 원본 파일을 서로 연결시켜주는 기능

 

보통 서버에 배포를 할 때 성능최적화를 위해 HTML, CSS, JavaScript와 같은 웹 자원들을 압축한다.
만약 압축하여 배포한 파일에서 에러가 난다면, 소스 맵을 이용해 배포용 파일의 특정 부분이 원본 소스의 어떤 부분인지 확인하여 디버깅할 수 있다.

CRA로 리액트 프로젝트를 빌드하여 배포하는 경우, 기본적으로 webpack에 의해 번들링된 파일과 해당 파일에 대응되는 sourcemap이 생성된다.

 

다른 하나는 ec2의 메모리 스왑을 해주어 임의로 메모리를 늘려주는 방법으로 빌드는 성공했다.

 

두 번째와 세 번째의 경우는 EC2 보안 그룹에 대한 이해 부족이었다.

두 번째의 경우 보안 그룹에 ssh (22 port)를 열어 주지 않아서 접근이 되지 않았던 것이고,

 

(보안 그룹을 건들다가 ssh 관련해서 22번 port를 지워버렸었다...)

 

세 번째의 경우도 결국에는 보안 그룹이 문제였는데 몰랐으니까..

iptables 건드려보고 웹 서버 포트, node 포트 건드려보고... docker에 80으로 올려보고 다 해봤는데 안되서 EC2 삭제...👋

설정을 너무 건드려서 돌이킬 수 없기에 EC2를 삭제하고 다시 만들었다.

 

EC2를 다시 띄우고 또 안되길래 혹시나 하고 도메인:3000 으로 연결해보니까 됐다.

뭐야 도메인은 연결이 잘 됐었네... 근데 왜 3000 꼬리가 붙었을까?

 

 

그냥 별 생각없이 EC2 메뉴를 보다가 보안 그룹이 눈에 들어왔다.

일전에 ssh 연결안됐던 것도 내가 port를 지정안해줘서 그랬던건데 이번에 그런게 아닐까 라는 생각이 들었다.

그래서 확인해보는데 이전에 EC2의 iptables을 80 -> 3000 로 포워딩을 해줬다.

그 말은 EC2에 80 요청이 들어오면 3000으로 리다이렉트를 시켜주는데 보안그룹에는 이와 관련된게 없네?

그냥 뭔가 막 찝찝해서 보안 그룹 키워드로 부랴부랴 검색하니까 바로 나왔다.

 

웹 서버로 3000 을 사용했으면 보안 그룹에도 3000 에 관해서 열어줘야한다는 것

 

 

일단 프론트 배포를 aws로 옮기는데 성공은 했다..👏👏👏

 

이제 본격적으로 인증서를 발급 받아야지

 

다음 글에 계속...

 

https://june-17.tistory.com/294

사이드 프로젝트 - Dotto 개발 일지 - SSL 인증서 발급