Conversation
| effect: "NoSchedule" | ||
|
|
||
| config: |
There was a problem hiding this comment.
백엔드 baseURL을 정하기 위해 env 설정도 필요하다는 설명을 프론트 PR에서 들은 기억이 나는데요, Pod에 ConfigMap등으로 주입하지 않아도 작동하는지 궁금합니다!
There was a problem hiding this comment.
env 설정은 로컬내에서만 사용하는 목적으로 설정해둔 상태입니다! 따라서 로컬 환경 내에서는 ConfigMap이 없어도 정상적으로 동작하지만 클러스터 환경이라면 ConfigMap이 필요합니다
There was a problem hiding this comment.
혹시 그렇다면 제가 이해한 것을 정리하자면
아래의 설명이 맞을까요?
- 로컬 환경에서 baseURL을 지정해주기 위해 env 설정이 필요하다. .env.dev 파일을 생성해서 사용할 수 있다.
아래의 설명은 틀릴까요?
- 클러스터 환경에서 env 설정이 필요하다.
- 클러스터 환경에서는 ConfigMap을 만들어서 .env.dev에 해당되는 설정을 정의하고 VolumeMount 등의 작업을 통해 FE 컨테이너에 해당되는 경로에 .env.dev 파일을 주입해야 한다.
해당되는 이유로는 이렇게 될까요?
- DockerFile 정의에서 two stage build 작업을 통해 yarn build된 정적 파일을 nginx 기반으로 서빙하고 있다. 즉, package.json의 설정인 yarn dev등으로 서빙하는 것이 아니므로, .env 파일을 찾지 못한다.
https://github.com/So1S/frontend/blob/main/Dockerfile
그렇다면 현재 dev / prod 클러스터에서는 baseURL을 env.dev를 통해 주입할 수 없을 것 같은데, 이러한 것들은 리버스 프록싱을 통해 해결할 수 없는 문제로 보입니다!
nginx에 라우팅을 추가하는 것은 가능하지만, baseURL에 빈 문자열이 대입되기 때문에 baseURL FE 서브도메인 혹은 BE 서브도메인으로 주입해야 가능할 것 같은데 맞을까요?
아니면 아예 baseURL을 빈 문자열로 지정해주어도 현재 사용하고 있는 프론트 도메인과 같은 주소로 적용될까요?
세팅이 많이 복잡해진다면 저는 아예 프로덕션 환경에서 yarn dev를 통해 서빙해도 좋을 것 같습니다!
추가적으로 yarn build된 정적 파일에는 yarn dev의 결과물과는 다르게 source map이 없는데, 디버깅에 필수적인 기능이기 때문에 어느정도 소스 코드가 공개되더라도 추가하는 것이 나아 보이는데 어떻게 생각하세요?
추후 Jira 태스크로 논의해도 좋을 것 같습니다!
https://vitejs.dev/config/build-options.html#build-sourcemap
앞서 얘기드린 Pod ConfigMap 주입은 nginx config이 아닌 .env.dev에 대응되는 설정을 의미합니다!
There was a problem hiding this comment.
클러스터 환경에서는 baseURL='' 가 되어야 정상입니다! 리버스 프록시 장점 중 하나로 http://<FE도메인주소>/api/v1/signin으로 보내면 nginx upstream 설정에 의해서 자동으로 BE API 서버로 요청이 들어갑니다!
There was a problem hiding this comment.
DockerFile 정의에서 two stage build 작업을 통해 yarn build된 정적 파일을 nginx 기반으로 서빙하고 있다. 즉, package.json의 설정인 yarn dev등으로 서빙하는 것이 아니므로, .env 파일을 찾지 못한다.
현재는 의도적으로 build할 때는 넣지 않고 있지만 vite 옵션 중 --mode를 통해서 .env.prod 같은 env 파일을 빌드 작업에 넣어줄 수 있습니다!
There was a problem hiding this comment.
명확하게 이해되었습니다 ㅎㅎ
말씀하신대로 FE 자체에서 baseURL을 같은 주소로 사용한 뒤, /api/v1 prefix에 해당되는 라우팅을 리버스 프록싱하는 것이 깔끔해 보입니다!
권한이 없는 악의적인 사용자가 백엔드 swagger 라우팅을 찾아가는 것 같은 어뷰징을 막을 수 있고, 현재 인증 포함한 사용중인 모든 API중에 /api/v1을 사용하지 않는 케이스는 없기 때문에 API 연동에도 문제가 없을 것 같습니다!
charts/frontend/dev-values.yaml
Outdated
| server so1s-dev.backend.svc.cluster.local; | ||
| } | ||
|
|
||
| server { | ||
| include /etc/nginx/mime.types; | ||
|
|
||
| listen 80; | ||
|
|
||
| location / { | ||
| root /usr/share/nginx/html; | ||
| index index.html index.htm; | ||
|
|
||
| try_files $uri /index.html; | ||
| } | ||
|
|
||
| location /api/v1 { | ||
| proxy_pass http://Backend/api/v1; | ||
| proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; | ||
| proxy_set_header Host $host; | ||
| proxy_http_version 1.1; | ||
| } |
There was a problem hiding this comment.
업스트림 서버를 정해서 리버스 프록싱을 하는 것은 좋은 것 같은데요, 앞서 말씀하신 방법대로 baseURL을 세팅할 경우 이 라우팅을 할 필요가 없을 것 같아서 고민이 됩니다!
There was a problem hiding this comment.
넵 사실 이 부분도 애매하긴 합니다. .env.prod으로 새로운 env를 만들고 거기에 백엔드 서브 도메인을 적어주면 됩니다.
리버스 프록시 장점외에도 사용성 측면에서 헬름 차트, ArgoCD Application으로 프로덕트를 전달한다고 하면 사용자가 FE 레포지토리를 건들 수 없기 때문에 사용자가 원하는 도메인(e.g. api.test.com)으로 설정할 수 없습니다.
그렇지만 Nginx 리버스 프록시 설정으로 인한 트러블 슈팅도 감안해야하기 때문에 2가지 방법 다 좋은 거 같네요
제 개인적인 생각으로는 사실 이미 사용성 측면에서의 이점은 많이 없기 때문에 말씀하신 방안으로 가도 좋을 거 같습니다. 어떻게 생각하시나요? @DPS0340
There was a problem hiding this comment.
리버스 프록시 장점외에도 사용성 측면에서 헬름 차트, ArgoCD Application으로 프로덕트를 전달한다고 하면 사용자가 FE 레포지토리를 건들 수 없기 때문에 사용자가 원하는 도메인(e.g. api.test.com)으로 설정할 수 없습니다.
차트 Values가 아닌 FE .env.prod 파일을 추가하여 고정하는 것은 문제가 있을 것 같습니다!
업스테이지 배포, 온프레미스 배포, 클라우드 서비스화등에서는 저희 so1s.io 도메인이 아닌 자체적으로 사용하고 있는 도메인으로 서비스가 배포될 텐데, 저희 백엔드를 사용하게 되면 문제가 있을 것 같습니다!
There was a problem hiding this comment.
넵 그러면 현재 작업한 내용으로 머지하겠습니다~
좋은 리뷰 감사합니다 :)
nginx 리버스 프록시 설정
Tasks
Discussion
Jira