docker pull преку VPN: daemon има сопствена мрежа

Вашиот лаптоп е на корпоративниот VPN, curl стигнува до внатрешниот registry, а docker pull сепак паѓа со EOF. Оваа комбинација не е противречност. Наредбата што ја внесовте се извршува во вашиот shell, но преносот се извршува во оној daemon што Docker CLI го избрал, а тој daemon може да биде на сосема друг хост. Неговата мрежна патека е таа што треба да работи, и неговите proxy поставки се тие што важат.

Започнете со идентификување на моторот, а не на маршрутата

Извршете docker context show и docker version. Излезот од верзијата печати дел за клиентот и дел за серверот, а блокот на серверот ви кажува кој одговори: локален нативен мотор, виртуелната машина на Docker Desktop или daemon на оддалечена машина. docker context inspect ќе ја покаже крајната точка на избраниот контекст ако сакате да бидете сигурни, и ниту една од овие наредби не менува ништо.

Променлива на околината како DOCKER_HOST може тивко да го насочи CLI кон друг мотор од оној што го претпоставувате, што е вообичаеното објаснување за лаптоп што изгледа дека е на VPN додека повлекувањето оди на друго место.

Daemon има сопствен мрежен идентитет

На оддалечен мотор му треба сопствена одобрена патека до приватниот registry. Поврзувањето на VPN клиентот на вашиот лаптоп му дава маршрута на тој лаптоп; тоа не му дава на daemon во лабораторија или облачна подмрежа истата приватна адреса. Ако моторот е Docker Desktop, повлекувањето се случува во неговата виртуелна машина, која има сопствена мрежна и proxy конфигурација, одделна од околината на вашиот shell.

Затоа успешен curl на хостот е доказ за хостот и ништо повеќе.

Откријте која размена со registry заврши

Повлекувањето на image е низа: автентикација, преземање на manifest и потоа преноси на blob што често се пренасочуваат кон објектно складиште или CDN крајна точка. Успешен docker login докажува само првиот чекор, а токенот може да биде сосема валиден додека пренасочениот blob хост е недостапен од мрежата на daemon. Пред да промените нешто, запишете го точното време, референцата на image и првиот корисен настан од дневникот на daemon или клиентот.

EOF сам по себе не именува причина. Тоа може да биде прекината врска, proxy што го испуштил текот, истекување на времето или проблем со MTU, а погодувањето меѓу нив без настанот со временска ознака е начинот на кој луѓето почнуваат да го преградуваат здравиот мотор. Третирајте го бајтното поместување во излезот на клиентот како податок, бидејќи преносот што застанува на иста големина секој пат е друго животно од оној што никогаш не почнува. Запишете ги двата исхода и споредете ги меѓу обидите.

Конфигурирајте ја компонентата што пренесува

За нативен Linux мотор, proxy припаѓа во околината на услугата, а не во вашиот shell. Drop-in датотека под /etc/systemd/system/docker.service.d/ со записи HTTP_PROXY, HTTPS_PROXY и NO_PROXY, по што следат systemctl daemon-reload и рестарт, е документираниот распоред. Docker Desktop ги изложува истите вредности преку сопствените поставки, а уредувањето на профил на shell не допира ниту еден од нив.

Ако registry треба да се достигне директно преку VPN, на daemon му треба resolver, маршрута и намерно исклучување на proxy, а не само исклучување. Совпаѓањето на NO_PROXY е споредба на низи за секоја компонента, а изземање без основна маршрута создава дефект што изгледа како проблем со proxy.

Кога корпоративната TLS инспекција е на одобрената патека, инсталирајте го нејзиниот проверен корен преку работниот тек на моторот или Desktop. Додавањето на registry во insecure-registries е друга промена што ја исклучува валидацијата, и тоа не е конфигурација на складиште за доверба.

Повторете едно контролирано повлекување и проверете што се сменило

Променете една граница, рестартирајте ја компонентата што ја поседува и повторете го истото повлекување од истиот контекст. Проверете ја добиената референца на image и digest, а не отсуството на грешка, бидејќи кеширан слој може да предизвика вториот обид да помине низ многу помал дел од патеката отколку првиот. Задржете ги во тикетот преносите што навистина се случиле, бидејќи тие се единствениот запис за тоа што повторувањето навистина го тестирало.

Build чекорите и контејнерите што работат имаат свои мрежни контексти, затоа третирајте ги како одделни прашања откако самото повлекување ќе проработи.