개발자
류준열

폐쇄망에서 겪은 서버컴포넌트 문제

로컬에서는 문제가 없었는데, 배포환경의 서버 컴포넌트에서는 api url을 찾을 수 없다는 에러가 떴다.

문제의 원인과 해결책을 설명하기에 앞서, 선행학습되어야 하는 브라우저에서 IP를 찾는 순서를 알아보자.

브라우저에서 IP를 찾는 순서를 보면 다음과 같다.

1. 브라우저 로컬 캐시

2. OS의 hosts 파일 확인

   터미널을 켜서 vi /etc/hosts 명령어를 입력하면 특정 ip주소에 등록된 도메인을 확인 할 수 있다. 아래 이미지는 127.0.0.1 이라는 ip주소에 localhost 라는 도메인을 연결했다는 뜻이다. 브라우저는 이를 바탕으로 localhost 를 입력했을때 127.0.0.1로 요청을 전송해준다.

3. PC내에서 찾을 수 없다면 DNS를 찾아간다.
   폐쇄망은 폐쇄되어있기 때문에 DNS를 고려할필요가 없다.

폐쇄망을 구성하는 인프라 환경에서 hosts파일에 아래 이미지와 같이 서버 ip, dev.api.com을 등록해줘야한다.

하지만 이 작업이 되어있지 않아서 폐쇄망 속 모든 서버(서버 컴포넌트, 젠킨스 등등)에서 dev.api.com에 접근이 불가능했다.

예를들어서 Jenkins file 안에 http://175.153.0.3.168/openapi.json으로 작성하면 CI가 잘 작동하지만, dev.api.com/openapi.json으로 작성하면 CI가 터진다.

이를 해결하려면 인프라에 api url과 ip를 등록하거나, 쿠버네티스에서 만들어주는 프록시 역할의 클러스터 url을 사용해야한다. 실제로 클러스터 url을 사용하니 문제가 해결되었다.

그렇다면 인프라 hosts 파일에 api url이 등록되어있지 않은데, 어떻게 클라이언트 컴포넌트에 작성한 api call은 잘 작동했던걸까?

이유는 앞서 언급한 브라우저에서 IP를 찾는 방식에 나와있다.

클라이언트 컴포넌트는 브라우저에서 작동한다.

브라우저에서는 로컬 PC의 /etc/hosts 파일에서 도메인에 등록된 ip주소를 찾는다. 즉, 브라우저가 켜진 내 로컬 PC의 /etc/hosts 설정이 적용되어 dev.api.com 에 접근이 가능했고, 로컬 빌드 후 되었던 이유도 내 로컬 PC의 /etc/hosts 설정이 적용되었기 때문이다.

어딘가에 도메인을 연결하는 포인트가 있을것이라 생각했는데, 그게 내 로컬PC에 있을줄이야..

• 문제: 배포환경의 서버컴포넌트에서 api url을 못찾음

• 원인: 인프라단에 api url이 등록되어있지 않았기 때문

• 궁금증: 폐쇄망의 인프라에 비공개 url과 ip주소를 등록하지 않았기 때문에 서버 컴포넌트에서 api url에 접근하지 못하는 건 이해가 됨. 그런데 왜 클라이언트 컴포넌트에서는 api url에 접근이 가능할까?

• 답: 클라이언트 컴포넌트가 동작하는 브라우저는 내 로컬의 /etc/hosts의 설정을 따르기 때문.

언제부턴가 이론에 불과하다고 했던 내용들이 버그의 원인이 되는 상황을 마주하게 된다. 이번에도 브라우저가 IP를 찾는 방식과 관련된 버그였다. 왜 면접질문에서 주소창에 구글을 치면 무슨일이 일어나는지 설명하라는 질문이 끊이지 않는지 알 것 같다.

리액트 어플리케이션 코드만 치는걸로는 살아남지 못할것임을 느낀다.