VPN을 통한 docker pull: 데몬은 자체 네트워크를 가진다

노트북이 회사 VPN에 연결되어 있고 curl 은 내부 레지스트리에 닿는데도 docker pull 은 여전히 EOF로 실패합니다. 이 조합은 모순이 아닙니다. 입력한 명령은 셸에서 실행되지만, 전송은 Docker CLI가 선택한 데몬 안에서 실행되며 그 데몬은 전혀 다른 호스트에 있을 수 있습니다. 동작해야 하는 것은 그 데몬의 네트워크 경로이고, 적용되는 것은 그 데몬의 프록시 설정입니다.

경로가 아니라 엔진을 식별하는 것부터 시작하십시오

docker context show 과 docker version 을 실행하십시오. 버전 출력은 클라이언트 섹션과 서버 섹션을 표시하고, 서버 블록은 무엇이 응답했는지 알려 줍니다. 로컬 네이티브 엔진, Docker Desktop 가상 머신, 또는 원격 머신의 데몬입니다. 확실히 하려면 docker context inspect 이 선택된 컨텍스트의 엔드포인트를 보여 주며, 이 명령들은 모두 아무것도 바꾸지 않습니다.

DOCKER_HOST 같은 환경 변수는 CLI를 예상과 다른 엔진으로 조용히 향하게 할 수 있으며, 이는 노트북이 VPN에 있는 것처럼 보이는데 풀이 다른 곳으로 가는 경우의 흔한 설명입니다.

데몬은 자체적인 네트워크 정체성을 가집니다

원격 엔진에는 프라이빗 레지스트리로 가는 자체 승인 경로가 필요합니다. 노트북의 VPN 클라이언트를 연결하면 그 노트북에 경로가 생길 뿐, 실험실이나 클라우드 서브넷에 있는 데몬에 같은 프라이빗 주소가 생기는 것은 아닙니다. 엔진이 Docker Desktop이라면 풀은 그 가상 머신 안에서 일어나며, 가상 머신은 셸 환경과 분리된 자체 네트워크 및 프록시 구성을 가집니다.

그래서 호스트에서 성공한 curl 은 호스트에 대한 증거일 뿐 그 이상이 아닙니다.

어떤 레지스트리 교환이 끝났는지 찾아내십시오

이미지 풀은 일련의 과정입니다. 인증, 매니페스트 가져오기, 그리고 자주 오브젝트 스토리지나 CDN 엔드포인트로 리디렉션되는 blob 전송이 이어집니다. 성공한 docker login 은 첫 단계만 증명하며, 리디렉션된 blob 호스트에 데몬의 네트워크에서 닿을 수 없다면 토큰은 완벽하게 유효할 수 있습니다. 무엇이든 바꾸기 전에 정확한 시각, 이미지 참조, 데몬이나 클라이언트 로그의 첫 번째 유용한 이벤트를 기록하십시오.

EOF만으로는 어떤 원인도 지목하지 않습니다. 끊긴 연결, 스트림을 떨어뜨린 프록시, 시간 초과, 또는 MTU 문제일 수 있고, 타임스탬프가 있는 이벤트 없이 이들 사이를 추측하는 것이 사람들이 멀쩡한 엔진을 다시 만드는 이유입니다. 클라이언트 출력의 바이트 오프셋을 데이터로 취급하십시오. 매번 같은 크기에서 멈추는 전송은 아예 시작되지 않는 전송과는 다른 존재입니다. 두 결과를 모두 기록하고 시도 사이에서 비교하십시오.

전송을 수행하는 구성 요소를 설정하십시오

네이티브 Linux 엔진에서는 프록시가 셸이 아니라 서비스 환경에 속합니다. /etc/systemd/system/docker.service.d/ 아래에 HTTP_PROXY, HTTPS_PROXY, NO_PROXY 항목이 있는 drop-in 파일을 두고 이어서 systemctl daemon-reload 과 재시작을 하는 것이 문서화된 방식입니다. Docker Desktop은 같은 값을 자체 설정을 통해 노출하며, 셸 프로필을 편집해도 둘 중 어느 것도 건드리지 않습니다.

레지스트리에 VPN을 통해 직접 닿아야 한다면 데몬에는 리졸버, 경로, 그리고 의도적인 프록시 제외가 필요하며 제외만으로는 부족합니다. NO_PROXY 일치는 구성 요소별 문자열 비교이며, 기반 경로가 없는 예외는 프록시 문제처럼 보이는 실패를 만듭니다.

기업 TLS 검사가 승인된 경로에 있다면 엔진이나 Desktop 워크플로를 통해 검증된 루트를 설치하십시오. 레지스트리를 insecure-registries에 추가하는 것은 검증을 끄는 다른 변경이며 트러스트 스토어 구성이 아닙니다.

통제된 풀을 한 번 반복하고 무엇이 바뀌었는지 확인하십시오

경계를 하나 바꾸고, 그것을 소유한 구성 요소를 재시작하고, 같은 컨텍스트에서 같은 풀을 반복하십시오. 오류가 없다는 것이 아니라 결과로 얻은 이미지 참조와 digest를 검증하십시오. 캐시된 레이어 때문에 두 번째 시도가 첫 번째보다 훨씬 적은 경로만 지나갈 수 있습니다. 실제로 일어난 전송을 티켓에 남기십시오. 재시도가 실제로 무엇을 시험했는지 보여 주는 유일한 기록입니다.

빌드 단계와 실행 중인 컨테이너에는 자체 네트워크 컨텍스트가 있습니다따라서 풀 자체가 동작한 뒤에는 별개의 질문으로 다루십시오.