not done
	due on or after 2024-05-08 
	description regex does not match /^$/

	done 2024-05-08
	description regex does not match /^$/

❮ 2024년 / 05월 / 19주 ❯
❮❮ 2024-05-07(화) | 2024-05-08(수) | 2024-05-09(목) ❯❯

nginx 조건문 걸기

오늘 빅 늦잠을 잤다.
머리가 아프더만..

어제 생각한 사항을 다시 정리해보자
요청이 /product/1, /product/1?Target-URL=sdf/product/1로 오게 된다면 그때만 api 서버, 즉 /waiting/enter로 보낸다.
그 외의 사항에 대해서는 전부 /qqueueing-frontend로 보낸다.

어차피 모든 요청은 url주소를 기반으로 한다.
현재 uri 주소는 asdf/waiting/queue-page

gerrit 사용하기

내가 원하는 곳으로 정확하게 리뷰 요청을 날리고 싶다면, HEAD:refs/for로 날려야 한다.
그래서 그것을 간단하게 보낼 수 있는 alias를 만들었다.
비번 입력도 자동화하고 싶었는데, 이건 실패.
깃랩이 https만 지원하기 때문이다;
ssh로 받을 수가 없게 돼있어 키를 등록하는 것이 불가능하다.

변동사항

팀원과의 협업 중 서로 이해가 일치하지 않는 부분이 있었다.
나는 프록시패스를 무조건 하나만 거는 상황을 생각했으나, 팀원의 의견에 의하면 리다이렉트를 시킬 때는 엔드포인트를 다르게 보낸다는 것.
그래서 나는 파이썬 스크립트에 수정하기 보다 직접 nginx 설정 파일을 먼저 건드리는 것이 빠르겠다는 판단을 내리고 이를 수정했다.
단순하게 프록시패스를 거는 것은 생각보다 어렵지 않다.

그러고나니 확실히 성공하는 지점이 있었다.

이렇게 말이다.
백엔드 팀원의 성공적인 파싱으로 제대로 css도 적용된 것이 확인된다.
그러나.. 위의 큐잉 이미지가 제대로 오지 않는 문제가 발생하고 있다.

바로 이런 문제가 발생하고 있는 것이다.
이게 무엇이냐면, js파일에서 추가적인 요청을 보내는데 그러한 요청을 수행하지 못하고 있는 이슈이다.
브라우저가 처음에 받게 되는 파일은 하나의 html이고, 그것에서 필요로 하는 css, js등의 파일들은 주소만 적혀있다.
이 주소들이 프록시패스에 제대로 걸리지 않는 관계로, 나는 이것을 was 서버가 먼저 파일을 받아서 파싱을 하여 프록시 패스에 걸리도록 유도하는 로직을 생각해냈다.
그리고 팀원이 이를 구현해준 덕에 이를 성공시킬 수 있었다.
분명 위의 요청들이 성공한 것을 보면 알 수 있듯이 이 전략은 가능했다.
그러나, 해당 요청들로부터 추가되는 다른 요청들이 있다는 것을 내가 몰랐다.
이것들에 대한 요청들이 실패하고 있는 상황이다.

self.__next_f_push라는 nextjs에서 이뤄지는 요청이 문제인데, 조사하면서 알게 된 사실 중 하나는 사실 성공한 요청들이 재요청되는 로직이 있고, 이 로직들이 문제를 일으킨다는 것이었다.
선 요청을 보내는 로직은 ssr과 연관이 되는 것이라고 하는 것 같다.
아무튼 이후 요청들이 진정으로 의미있는 녀석들인데, 이 친구들은 어떻게 제대로 보낼 수 있을까?

진짜 이런 도전을 하는 게 맞는거냐.. 싶긴 하지만 결국에는 나는 해결사다.
계획을 세웠다면, 그 중간이 아무리 어렵더라도 해내고 만다.
내가 모른다고 포기한다면 진작에 이 직업을 선택하지 않았을 것이다.

갑자기 이건 무슨 문제지.
뭐인지 모르겠다.
설마 gerrit을 사용하게 되면서 내가 이용하고 있던 tls 키에 이상이 생긴 것인가?
그럴 가능성이 있다.
CA에서 이 키에 대해서 어떤 식으로 평가를 바꾼 것일 수도 있다.

현재 이렇게 블럭을 추가해서 localhost로 오는 요청의 경우 값이 제대로 가게 만들어두었다.
그러나 이렇게 하자 일반적인 진입도 막혀버리는 문제가 발생했다.
그래서 서버 블럭의 위치를 기본 설정 파일의 최하단으로 내렸는데, 이렇게 하니 문제가 해결됐다.
내가 알기로는 nginx는 블럭들의 위치가 지대한 영향을 끼치는데, 실제로 그런 것 같다.

운동을 끝내고 다시 돌아왔는데, 위의 tls 관련 이슈는 사라졌다.
CA 서버 문제였을지도 모르겠다.
다시 상황이 나타나지 않으니 추가적인 테스트가 불가능하다.
그리고 아까는 제대로 동작하지 않았는데, 지금은 localhost와 도메인 이름을 가진 서버 블록이 둘 다 정상적으로 동작한다.
아까 전까지만 해도 한쪽이 되면 한쪽이 되지 않는 이슈가 존재했는데 말이다.

네트워크 모드가 호스트라면

말 그대로이다.
이전에 고민하기로는, 최종적으로 대기열에 진입한 사용자가 받을 페이지를 돌려주는 것은 백엔드이므로 백엔드가 운영자 프론트에 요청할 방안을 만들어두면 되겠다고 생각했다.

원래 생각한 방안은 이렇게 nginx 쪽에 설정을 추가해서 local로 보내면 되게 하는 것이었다.
그러나 생각해보니 백엔드는 컨테이너 내부에 있기에 이쪽으로 요청을 보내는 것이 쉽지 않다.
그러다 문득 든 생각이, 애초에 우리 서비스의 네트워크 모드가 host면 어떻게 되나하는 것.
일단 얻는 이점을 생각해보자.

• 운영자의 서버와의 연결이 매끄러워진다.
  • 지금도 운영자의 서버와 연결하는 이슈로 인해 각종 이슈들이 존재했다.
  • 운영자의 nginx는 어떻게 우리 서비스에 접근하는가?
    • 현재는 우리 네트워크에 connect시키는 것으로 해결했다.
  • 운영자의 nginx에 어떻게 접근하는가?
    • 현재는 단순하게 도메인 이름을 명시하는 것으로 해결했다.
    • 그런데 이건 사실 좋지 않은 것이, 한 os 안에서 오고가는 통신이 바깥까지 나갔다 와야만 한다.
• 운영자 서버에 임의의 요청을 날릴 수 있게 된다.
  • 이걸 통해 지표 테스트 같은 것이 가능해진다.
  • 부하 테스트를 진행하는 것도 불가능한 것은 아닐 것이다.
    • 물론 좋진 않을 것 같다.
• 앱 간의 통신이 간편해진다.
  • 현재는 팀원들이 업데이트를 진행하면 내가 일일히 통신하는 구조를 수정해준다.
  • 그러나 이럴 필요가 없게 된다.

우려되는 사항

• 모든 포트들이 겹치지 않게 새로 세팅해줘야 한다.
  • 확인해보니 겹치는 것이 없기는 하다.
  • 그러나 문제가 발생한다면, 이걸 다 고쳐야 하고, 이것은 적지 않은 작업이 될 수도 있다.
    
  • 당장 이런 문제가 발생하고 있다.
• 스케일 아웃을 고려한다면, 컴포즈의 자동 로드밸런싱을 기대할 수 없게 된다.
  
  • 쉽게 확인이 가능했다.
• 확인해보니, 서비스 이름을 통한 접근이 성립하지 않는다.
  • 컨테이너 내부에서도, 호스트에서도 불가능했다.

오픈비두에서는 자신들의 서비스를 이용하기 위해서 아예 몇몇 포트는 쓰지 말라고 말한다.
지네가 써야 한다, 이것이다.
우리도 그런 노선을 선택해야 하는 것일까.

이런 방법도 있다?

그러나 그렇게 하더라도, 내부에서 소통하는 것은 여전히 불가능하다.
nginx의 어떤 서버블록을 거치는지 모르겠다.
nginx에서 172.17.0.1로 요청이 올 때 처리하는 코드를 넣었는데 제대로 동작하지 않는 모양이다.
그런데 이건 왜 이렇게 되는지 모르겠다.
어떤 상황이길래 요청이 돌아오지 않는 것일까?
신기한 것은..

이건 또 받아온다는 것이다.

이건 또 아무 값도 없이 온다.
이건 host 환경에서도 마찬가지인 것을 확인했고, 그게 옳은 동작이라 생각된다.
그럼 어떻게 해야 저렇게 돌아오지 않는 동작 상태를 만들 수 있는 거지?