VPN арқылы docker pull: daemon-ның өз желісі бар

Ноутбугіңіз корпоративтік VPN желісінде, curl ішкі registry-ге жетеді, бірақ docker pull әлі де EOF-пен құлайды. Бұл комбинация қайшылық емес. Сіз терген команда shell-іңізде орындалады, ал тасымалдау Docker CLI таңдаған daemon ішінде орындалады, және ол daemon мүлде басқа хостта болуы мүмкін. Дәл оның желілік жолы жұмыс істеуі керек, және дәл оның proxy параметрлері қолданылады.

Маршруттан емес, қозғалтқышты анықтаудан бастаңыз

docker context show және docker version орындаңыз. Нұсқа шығысы клиент бөлімі мен сервер бөлімін басып шығарады, ал сервер блогы кім жауап бергенін айтады: жергілікті native қозғалтқыш, Docker Desktop виртуалды машинасы немесе қашықтағы машинадағы daemon. Сенімді болғыңыз келсе, docker context inspect таңдалған контекстің соңғы нүктесін көрсетеді, және бұл командалардың ешқайсысы ештеңені өзгертпейді.

DOCKER_HOST сияқты орта айнымалысы CLI-ді сіз болжағаннан өзге қозғалтқышқа үнсіз бағыттауы мүмкін, және бұл ноутбук VPN-де көрінгенімен pull басқа жаққа кететін жағдайдың әдеттегі түсіндірмесі.

Daemon-ның өзіндік желілік идентитеті бар

Қашықтағы қозғалтқышқа жеке registry-ге өзінің рұқсат етілген жолы қажет. Ноутбугіңіздің VPN клиентін қосу сол ноутбукке маршрут береді; ол зертханада немесе бұлттық қосымша желіде отырған daemon-ға сол жеке мекенжайды бермейді. Егер қозғалтқыш Docker Desktop болса, pull оның виртуалды машинасының ішінде жүреді, ал оның shell ортаңыздан бөлек өзіндік желілік және proxy конфигурациясы бар.

Сондықтан хостта сәтті curl тек хост туралы дәлел, одан артық емес.

Registry-мен қай алмасу аяқталғанын анықтаңыз

Image тарту — бұл реттілік: аутентификация, манифестті алу, содан кейін көбінесе объектілік қоймаға немесе CDN соңғы нүктесіне бағытталатын blob тасымалдаулары. Сәтті docker login тек бірінші қадамды дәлелдейді, ал токен толығымен жарамды болуы мүмкін, бірақ қайта бағытталған blob хосты daemon желісінен қолжетімсіз. Бірдеңені өзгерту алдында нақты уақытты, image сілтемесін және daemon немесе клиент журналындағы бірінші пайдалы оқиғаны жазып алыңыз.

EOF өздігінен ешқандай себеп атамайды. Бұл үзілген байланыс, ағынды тастаған proxy, уақыттың бітуі немесе MTU мәселесі болуы мүмкін, және уақыт белгісі бар оқиғасыз олардың арасында болжау — адамдардың сау қозғалтқышты қайта құруының жолы. Клиент шығысындағы байттық ығысуды дерек ретінде қарастырыңыз, өйткені әр жолы бірдей өлшемде тоқтайтын тасымалдау ешқашан басталмайтын тасымалдаудан мүлде басқа нәрсе. Екі нәтижені де жазып, оларды әрекеттер арасында салыстырыңыз.

Тасымалдайтын компонентті конфигурациялаңыз

Native Linux қозғалтқышы үшін proxy shell-де емес, қызмет ортасында болуы керек. /etc/systemd/system/docker.service.d/ астындағы HTTP_PROXY, HTTPS_PROXY және NO_PROXY жазбалары бар drop-in файлы, одан кейін systemctl daemon-reload және қайта іске қосу — құжатталған тәртіп. Docker Desktop бірдей мәндерді өз параметрлері арқылы ұсынады, ал shell профилін өңдеу олардың ешқайсысына тимейді.

Егер registry-ге тікелей VPN арқылы жету керек болса, daemon-ға resolver, маршрут және әдейі жасалған proxy ерекшелігі қажет, тек ерекшелік емес. NO_PROXY сәйкестендіруі әр компонент үшін жолдық салыстыру, ал астында маршруты жоқ босату proxy мәселесіне ұқсайтын ақау туғызады.

Корпоративтік TLS инспекциясы рұқсат етілген жолда болғанда, оның тексерілген түбірін қозғалтқыш немесе Desktop жұмыс ағыны арқылы орнатыңыз. Registry-ді insecure-registries тізіміне қосу — валидацияны өшіретін басқа өзгеріс, және ол сенім қоймасының конфигурациясы емес.

Бір бақыланатын pull-ды қайталап, не өзгергенін тексеріңіз

Бір шекараны өзгертіп, оған ие компонентті қайта іске қосыңыз және сол контекстен сол pull-ды қайталаңыз. Алынған image сілтемесі мен digest-ті тексеріңіз, қатенің жоқтығын емес, өйткені кэштелген қабат екінші әрекетке біріншісіне қарағанда жолдың әлдеқайда аз бөлігін жүргізуі мүмкін. Нақты болған тасымалдауларды тикетте сақтаңыз, өйткені олар қайталау шынымен нені тексергенінің жалғыз жазбасы.

Build қадамдары мен жұмыс істеп тұрған контейнерлердің өз желілік контекстері бар, сондықтан pull өзі жұмыс істегеннен кейін оларды бөлек сұрақ ретінде қарастырыңыз.