curl, .NET, 컨테이너 간 NO_PROXY 호환성

한 팀이 하나의 우회 문자열을 공유 환경 파일에 넣습니다. curl은 직접 연결하고, 다른 애플리케이션은 프록시를 사용하며, 컨테이너는 또 다르게 동작합니다. 공유 파일은 같은 문자를 배포했습니다. 하지만 하나의 공유 파서를 배포한 것은 아닙니다.

지속되는 대상은 정책입니다. 어떤 목적지가 어떤 조건에서 직접 연결되어야 하는가? 그것을 각 프로그램에 필요한 문자열과 분리하십시오.

먼저 예상 경로를 적으십시오

쉬운 성공 사례만이 아니라 경계를 포함한 대표 주소를 사용하십시오.

다음으로 소비자를 식별하십시오. 이미지를 가져오는 데몬, 컨테이너 내부 프로그램, 언어의 HTTP 라이브러리, 대화형 브라우저는 모두 별개의 항목일 수 있습니다. Docker 클라이언트 프록시 구성은 내부의 각 클라이언트가 같은 일치 규칙을 구현하지 않아도 컨테이너 환경 값을 채울 수 있습니다.

맹목적으로 복사하지 말고 번역하십시오

실제 차이에 대한 문서화된 한 예는 상위 도메인 경계입니다. curl의 도메인 제외는 지정된 도메인과 일치하는 하위 도메인을 포함합니다. .NET의 환경 정책은 맨 이름과 앞 점이 붙은 하위 도메인 형식을 구분합니다. 항상 앞 점을 붙이라는 보편 규칙은 두 정책을 모두 안정적으로 표현할 수 없습니다.

IP 범위 지원도 소비자와 그 버전에 따라 달라집니다. 새 독립형 curl이 있는 기계에서도 이전 libcurl에 연결된 애플리케이션이나 전혀 다른 라이브러리를 쓰는 클라이언트를 실행할 수 있습니다. 운영 체제 릴리스는 완전한 클라이언트 목록이 아닙니다.

각 소비자에 대해 지원되는 구성 인터페이스와 의도한 경로의 가장 작은 표현을 기록하십시오. 짧고 명시적인 호스트 목록이 아무도 의미를 설명할 수 없는 교묘한 패턴보다 나을 수 있습니다.

구성 증거와 연결 증거를 분리해 두십시오

파싱된 설정이나 라우팅 결정 API는 프로그램이 무엇을 선택했는지 보여 줄 수 있습니다. 그러면 요청 결과가 그 경로를 사용할 수 있었는지 보여 줍니다. .NET에서는 HttpClient.DefaultProxy.IsBypassed 가 기본 프록시가 사용 중인 정책일 때 그 구성 측 검사를 제공합니다. 요청 시간이 초과되었다는 이유만으로 도달할 수 없는 직접 서비스를 우회 파서 실패로 진단하지 마십시오.

클라이언트나 기본 이미지를 업데이트할 때 경계 목적지를 유지하십시오. 그것들은 파일에 왜 비슷해 보이는 도메인 항목이 두 개 있는지 팀 전체가 다시 알아낼 필요 없이 향후 호환성 변경을 보이게 합니다.