기업 프록시가 Compose 서비스 이름을 확인하려는 이유

HTTP 클라이언트는 Docker의 서비스 이름 확인을 사용하기 전에 내부 서비스 요청을 구성된 프록시로 보낼 수 있습니다. 올바른 클라이언트에 의도적인 우회를 추가하세요.

애플리케이션은 기업 프록시를 통해 인터넷에 접속하지만 http://catalog:8080/ 이 실패하고 프록시는 “catalog”를 확인할 수 없습니다. 그 요청은 Docker의 내부 DNS를 한 번도 사용하지 않았을 수 있습니다.

HTTP 클라이언트는 직접 연결을 만들기 전에 프록시를 선택할 수 있습니다. 그러면 외부 프록시는 Compose 네트워크 안에서만 의미가 있는 이름을 받습니다.

  1. 요청에 호스트 이름을 사용하세요. Compose 서비스는 적절한 네트워크에서 서비스 이름으로 검색할 수 있습니다. 변경될 수 있는 컨테이너 IP를 하드코딩하는 대신 사용하는 클라이언트가 지원하는 우회 구성에 catalog 을 추가하세요.
  2. 기존 예외를 유지하세요. 환경을 인식하는 클라이언트라면 관련 항목을 조직 목록과 병합하세요:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

이미지에 있는 실제 라이브러리나 실행 파일의 대소문자 처리, 버전, 일치 문법을 확인하세요. 보편적인 NO_PROXY 파서는 없습니다. 작은 이미지의 wget이라는 프로그램이 GNU Wget처럼 동작해야 할 필요는 없습니다.

요청이 직접 라우팅을 선택하면 호출자와 서비스의 공유 네트워크, 수신 대기 중인 서비스, 컨테이너 포트를 확인하세요. 게시된 호스트 포트는 또 다른 엔드포인트입니다. 우회는 빠진 네트워크 연결을 추가할 수 없으며, 네트워크를 다시 만들어도 외부 프록시에 사설 Compose 이름을 가르칠 수 없습니다.

의도한 분리를 유지하세요. 내부 요청은 내부 경로를 사용하고, 외부 요청은 승인된 프록시를 유지합니다. 프록시를 전역으로 비활성화하면 이 하나의 장애를 숨기는 동시에 다음 외부 요청에 필요한 경로를 제거할 수 있습니다.

관련 글