docker pull이 컨테이너의 프록시 설정을 무시하는 이유

컨테이너 프록시 변수가 데몬을 제어하길 기대하지 말고 실제로 이미지를 가져오는 Docker 구성 요소를 설정하세요.

docker pull이 실패하면 Docker 데몬이나 Docker Desktop을 설정해야 합니다. 이미지 다운로드는 애플리케이션 컨테이너가 자신의 프록시 변수를 읽기 전에 이뤄집니다.

네이티브 Docker Engine

이 부분을 기존 데몬 프록시 설정에 합치면서 문서용 엔드포인트를 바꾸고 무관한 설정은 유지하세요. 공개 프록시를 써도 되는 공개 이미지 가져오기 시험이라면 HTTP 프록시 목록에서 후보를 얻을 수 있습니다:

{
  "proxies": {
    "http-proxy": "http://203.0.113.10:8080",
    "https-proxy": "http://203.0.113.10:8080",
    "no-proxy": "localhost,127.0.0.1,registry.example.internal"
  }
}

하이픈이 들어간 데몬 키는 Docker 클라이언트의 ~/.docker/config.json에 쓰는 camelCase 키와 다릅니다. 클라이언트 프록시 항목은 새 컨테이너와 빌드에 환경 변수를 공급하며, 데몬 다운로드나 이미 존재하는 컨테이너 환경은 설정하지 않습니다.

해당 설치 방식의 문서에 따라 데몬을 재시작하되 현재 작업에 미칠 영향을 계획하세요. 데몬 시작 환경에 프록시 변수를 전달하는 방법도 있습니다. 나중에 다른 터미널에서 export해도 실행 중인 서비스는 바뀌지 않습니다.

Docker Desktop

Desktop 자체 프록시 설정을 사용하세요. Docker 문서에 따르면 Desktop은 daemon.json의 프록시 항목을 무시하므로 네이티브 Engine 예제를 반복해서 바꿔도 이 제품의 경로를 설정할 수 없습니다.

실제 담당 구성 요소를 수정한 후 이미지 가져오기를 재시도하세요. 레지스트리 접근, 인증, 리디렉션, 레이어 다운로드 중 어디서 실패했는지 읽어야 합니다. 기존 컨테이너 내부에서 성공한 HTTP 요청은 그 앱의 경로만 확인합니다. 공유 스크린샷이나 커밋한 파일에 프록시 인증 정보를 넣지 마세요. 데몬 설정과 컨테이너 환경은 비밀 저장소가 아닙니다.

관련 글