19일차가 많이 늦어졌다.
사실 그간 오류 잡는다고 트러블 슈팅을 너무 오래해서 한 4일을 쓴거같다.
프론트엔드에 대해 아는 지식이 미미하다보니 어떻게 배포하는건지 너무 헷갈려서
부딪혀서 알아보기로 했다.
아무래도 19일차는 배포
20일차는 assets 오류
21일차는 Public 오류
이렇게 진행할거같다.
프론트 엔드를 nginx로 배포하는 방법은 어렵진 않았다.
우선 기존에 aws에서 사용하던 방법은 클라우트 프론트였는데, 내가 알기로는 이 배포방식은
전세계에 퍼진 엣지서버에 index를 캐싱해놓고 요청이 오는 곳에서 가장 가까운 서버에서 요청을 받아 index.html을 보내는 걸로 기억한다.
엔진엑스는 이런 부분과는 완전히 다르게 작동한다.
우선 코드를 보고 말해야 할 듯하다.
location /public/ {
alias /usr/share/nginx/html/;
try_files $uri =404;
이런 식의 코드를 엔진엑스에 넣어야한다.
우선 사용자 편의를 위해 기존에 443포트를 api.~으로 연결한걸 가져와서 80, 443은 www.~으로 변경했다.
그 후에 사용자가 443으로 들어올 경우 index.html로 연결한다는 코드를 엔진엑스에 작성해줘야한다.
리액트 기반의 프론트엔드 코드가 install, run build를 하면 Dist라는 파일이 생기고 그안에 index라는 파일이 생긴다는걸 확인했다.
그래서 ./dist를 usr/ share/ nginx/html로 마운트하는 부분을 compose 파일에 추가하고 그대로 했는데
2가지 문제가 발생했다.
문제점 1.
root 형식으로 적으니 html 폴더에 엔진엑스 기본 파일이 갔다.
문제점 2.
assets 을 찾지못했다.
문제점 2는 다음날로 미루기로하고
문제점 1. 을 보자면 내가 여러가지 이유로 compose에 ./dist를 마운트한게 아니라 빌드 볼륨을 마운트하고 아래다가 빌드 볼륨일 비명시적으로 설정해주었는데 이게 문제였다.
alias로 경로를 지정하면 잘 되길래 처음에는 root가 문제인가했는데 사실 2중에 1개만 작동되는게 말이 안되는걸 알면서 약간 흐린눈으로 넘어갔다.
이후에 마운트 과정에서 빌드가 비어있는 상태로 덮어 씌운다는걸 알게되서
volumes:
build_volume:
driver: local
driver_opts:
type: "none"
device: "./dist" # 빌드된 정적 파일들이 있는 경로를 지정
o: "bind"이렇게 볼륨자체를 디테일하게 명시해주니 그 문제는 해결되었다.
어쨋든 엔진엑스로 프론트엔드 파일을 배포하는 과정은
그냥 사용자가 들어오면 나한테 있는 index.html파일이 있는 위치로 연결만 해주면 되는 부분이라 어렵지 않았다.
다만 이 Index가 다른 무언갈 참고하고 있다면 조금 복잡해질수 있어서 이 부분은 맞으면서 배워야할 듯 하다.
