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-а и контејнери који раде имају сопствене мрежне контексте, зато их третирајте као одвојена питања када само повлачење проради.