docker pull VPN-en át: a daemonnak saját hálózata van

A laptopja a vállalati VPN-en van, curl eléri a belső registryt, és a docker pull mégis EOF-fal hal meg. Ez a kombináció nem ellentmondás. A beírt parancs a shelljében fut, de az átvitel abban a daemonban fut, amelyet a Docker CLI kiválasztott, és az a daemon teljesen más hoston lehet. Az ő hálózati útvonalának kell működnie, és az ő proxybeállításai érvényesek.

A motor azonosításával kezdje, nem az útvonallal

Futtassa a docker context show és a docker version parancsot. A verzió kimenete egy kliensrészt és egy szerverrészt nyomtat, a szerverblokk pedig megmondja, ki válaszolt: egy helyi natív motor, a Docker Desktop virtuális gépe vagy egy távoli gépen futó daemon. A docker context inspect megmutatja a kiválasztott kontextus végpontját, ha biztos akar lenni, és ezek a parancsok egyike sem változtat semmin.

Egy olyan környezeti változó, mint a DOCKER_HOST, csendben átirányíthatja a CLI-t egy másik motorra, mint amire számít, és ez a szokásos magyarázata annak, hogy egy laptop a VPN-en látszik, miközben a pull máshová kerül.

A daemonnak saját hálózati identitása van

Egy távoli motornak saját jóváhagyott útvonalra van szüksége a privát registry felé. A laptop VPN-kliensének csatlakoztatása útvonalat ad annak a laptopnak; nem adja meg ugyanazt a privát címet egy laboratóriumban vagy felhőalhálózatban ülő daemonnak. Ha a motor a Docker Desktop, a pull a virtuális gépében történik, amelynek saját hálózati és proxykonfigurációja van, elkülönülve a shellje környezetétől.

Ezért a hoston sikeres curl csak a hostra vonatkozó bizonyíték, és semmi több.

Derítse ki, melyik registry-csere fejeződött be

Egy image pull sorozat: hitelesítés, a manifest lekérése, majd blobátvitelek, amelyeket gyakran objektumtárolóba vagy CDN-végpontra irányítanak át. Egy sikeres docker login csak az első lépést bizonyítja, és egy token teljesen érvényes lehet, miközben az átirányított blob-host a daemon hálózatából elérhetetlen. Jegyezze fel a pontos időt, az image-referenciát és a daemon vagy a kliens naplójának első hasznos eseményét, mielőtt bármit megváltoztat.

Az EOF önmagában nem nevez meg okot. Lehet csonkolt kapcsolat, a streamet eldobó proxy, időtúllépés vagy MTU-probléma, és ezek között találgatni az időbélyeges esemény nélkül az az út, amelyen az emberek újraépítenek egy egészséges motort. Kezelje a kliens kimenetében lévő byte-eltolást adatként, mert az az átvitel, amely minden alkalommal ugyanannál a méretnél áll meg, más állat, mint az, amely soha nem indul el. Rögzítse mindkét eredményt, és hasonlítsa össze őket a kísérletek között.

Konfigurálja az átvitelt végző komponenst

Natív Linux-motor esetén a proxy a szolgáltatás környezetébe tartozik, nem a shelljébe. A /etc/systemd/system/docker.service.d/ alatti drop-in fájl HTTP_PROXY, HTTPS_PROXY és NO_PROXY bejegyzésekkel, majd a systemctl daemon-reload és egy újraindítás a dokumentált elrendezés. A Docker Desktop ugyanezeket az értékeket a saját beállításain keresztül teszi elérhetővé, és a shell-profil szerkesztése egyikhez sem nyúl.

Ha a registryt közvetlenül a VPN-en keresztül kell elérni, a daemonnak feloldóra, útvonalra és szándékos proxykizárásra van szüksége, nem csupán kizárásra. A NO_PROXY egyeztetése komponensenkénti karakterlánc-összehasonlítás, és a mögöttes útvonal nélküli mentesség olyan hibát eredményez, amely proxys problémának látszik.

Amikor a vállalati TLS-vizsgálat a jóváhagyott útvonalon van, telepítse az ellenőrzött gyökerét a motor vagy a Desktop munkafolyamatán keresztül. A registry felvétele az insecure-registries listára más változtatás, amely kikapcsolja az ellenőrzést, és nem egy bizalmi tároló konfigurációja.

Ismételjen meg egy ellenőrzött pullt, és nézze meg, mi változott

Változtasson egy határon, indítsa újra a komponenst, amely ahhoz tartozik, és ismételje meg ugyanazt a pullt ugyanabból a kontextusból. Ellenőrizze a kapott image-referenciát és digestet, ne a hiba hiányát, mert egy gyorsítótárazott réteg miatt egy második kísérlet sokkal kevesebbet járhat be az útvonalból, mint az első. Őrizze meg a jegyben azokat az átviteleket, amelyek valóban megtörténtek, mert csak ezek rögzítik, mit is tesztelt valójában az ismétlés.

A build-lépéseknek és a futó konténereknek saját hálózati kontextusuk van, ezért kezelje őket külön kérdésként, miután maga a pull működik.