VPN üzerinden docker pull: daemon'un kendi ağı vardır

Dizüstü bilgisayarınız kurumsal VPN'de, curl dahili registry'ye ulaşıyor ama docker pull hâlâ EOF ile ölüyor. Bu kombinasyon bir çelişki değil. Yazdığınız komut kabuğunuzda çalışıyor, ancak aktarım Docker CLI'nin seçtiği daemon içinde çalışıyor ve o daemon tamamen başka bir ana bilgisayarda olabilir. Çalışması gereken onun ağ yoludur ve geçerli olan onun proxy ayarlarıdır.

Yol değil, motoru tanımlayarak başlayın

docker context show ve docker version komutlarını çalıştırın. Sürüm çıktısı bir istemci bölümü ve bir sunucu bölümü yazdırır ve sunucu bloğu neyin yanıt verdiğini söyler: yerel yerleşik bir motor, Docker Desktop sanal makinesi veya uzak bir makinedeki daemon. Emin olmak istiyorsanız docker context inspect seçili bağlamın uç noktasını gösterir ve bu komutların hiçbiri hiçbir şeyi değiştirmez.

DOCKER_HOST gibi bir ortam değişkeni CLI'yi sessizce varsaydığınızdan farklı bir motora yönlendirebilir ve bu, dizüstü bilgisayar VPN'de görünürken çekmenin başka bir yere gitmesinin olağan açıklamasıdır.

Daemon'un kendi ağ kimliği vardır

Uzak motorun özel registry'ye kendi onaylı yolu gerekir. Dizüstü bilgisayarınızın VPN istemcisini bağlamak o bilgisayara bir yol verir; laboratuvarda veya bulut alt ağında oturan bir daemon'a aynı özel adresi vermez. Motor Docker Desktop ise çekme onun sanal makinesi içinde gerçekleşir ve bu makinenin kabuğunuzun ortamından ayrı kendi ağ ve proxy yapılandırması vardır.

Bu yüzden ana bilgisayarda başarılı bir curl yalnızca ana bilgisayar hakkında kanıttır, daha fazlası değil.

Registry ile hangi alışverişin sona erdiğini bulun

İmaj çekme bir dizidir: kimlik doğrulama, manifestin alınması ve ardından sıklıkla nesne depolamaya veya bir CDN uç noktasına yönlendirilen blob aktarımları. Başarılı bir docker login yalnızca ilk adımı kanıtlar ve yönlendirilen blob ana bilgisayarı daemon'un ağından erişilemezken belirteç tamamen geçerli olabilir. Bir şeyi değiştirmeden önce tam zamanı, imaj referansını ve daemon veya istemci günlüğündeki ilk yararlı olayı not edin.

EOF tek başına hiçbir neden belirtmez. Kesilmiş bir bağlantı, akışı düşüren bir proxy, zaman aşımı veya MTU sorunu olabilir ve zaman damgalı olay olmadan bunlar arasında tahmin yürütmek insanların sağlıklı bir motoru yeniden inşa etmesine yol açar. İstemci çıktısındaki bayt kaymasını veri olarak ele alın, çünkü her seferinde aynı boyutta duran bir aktarım hiç başlamayan bir aktarımdan tamamen farklı bir hayvandır. İki sonucu da kaydedin ve denemeler arasında karşılaştırın.

Aktarımı yapan bileşeni yapılandırın

Yerleşik bir Linux motoru için proxy kabuğunuzda değil, hizmet ortamında yer alır. /etc/systemd/system/docker.service.d/ altında HTTP_PROXY, HTTPS_PROXY ve NO_PROXY girdileri olan bir drop-in dosyası ve ardından systemctl daemon-reload ile yeniden başlatma, belgelenmiş düzenlemedir. Docker Desktop aynı değerleri kendi ayarları üzerinden sunar ve bir kabuk profili düzenlemek ikisine de dokunmaz.

Registry'ye doğrudan VPN üzerinden ulaşılması gerekiyorsa daemon'un bir çözümleyiciye, bir yola ve kasıtlı bir proxy istisnasına ihtiyacı vardır; yalnızca istisnaya değil. NO_PROXY eşleşmesi bileşen başına bir dize karşılaştırmasıdır ve altında yol olmayan bir muafiyet proxy sorunu gibi görünen bir hataya yol açar.

Kurumsal TLS denetimi onaylı yolda olduğunda, doğrulanmış kökünü motorun veya Desktop'un iş akışı üzerinden kurun. Registry'yi insecure-registries listesine eklemek doğrulamayı kapatan başka bir değişikliktir ve bir güven deposu yapılandırması değildir.

Tek bir kontrollü çekmeyi tekrarlayın ve neyin değiştiğini kontrol edin

Bir sınırı değiştirin, ona sahip olan bileşeni yeniden başlatın ve aynı bağlamdan aynı çekmeyi tekrarlayın. Hatasının olmamasını değil, elde edilen imaj referansını ve digest'i doğrulayın, çünkü önbelleğe alınmış bir katman ikinci denemenin yoldan birinciden çok daha azını geçmesine neden olabilir. Gerçekten gerçekleşen aktarımları kayıtta tutun, çünkü yeniden denemenin gerçekte neyi sınadığının tek kaydı onlardır.

Build adımları ve çalışan konteynerler kendi ağ bağlamlarına sahiptir, bu yüzden çekme kendisi çalıştıktan sonra onları ayrı sorular olarak ele alın.