VPN દ્વારા docker pull: ડિમનનું પોતાનું નેટવર્ક છે

તમારું લેપટોપ કોર્પોરેટ VPN પર છે, curl આંતરિક રજિસ્ટ્રી સુધી પહોંચે છે, અને તેમ છતાં docker pull EOF સાથે નિષ્ફળ જાય છે. આ સંયોજન વિરોધાભાસ નથી. તમે લખેલો આદેશ તમારા શેલમાં ચાલે છે, પરંતુ સ્થાનાંતરણ તે ડિમનમાં ચાલે છે જે Docker CLI એ પસંદ કર્યું છે, અને તે ડિમન સંપૂર્ણપણે બીજા હોસ્ટ પર હોઈ શકે છે. તેનો નેટવર્ક માર્ગ જ કાર્ય કરવો જોઈએ, અને તેની પ્રોક્સી સેટિંગ્સ જ લાગુ પડે છે.

માર્ગ નહીં, એન્જિન ઓળખીને શરૂ કરો

docker context show અને docker version ચલાવો. વર્ઝન આઉટપુટ ક્લાયન્ટ વિભાગ અને સર્વર વિભાગ છાપે છે, અને સર્વર બ્લોક તમને કહે છે કે કોણે જવાબ આપ્યો: સ્થાનિક નેટિવ એન્જિન, Docker Desktop વર્ચ્યુઅલ મશીન, કે દૂરના મશીન પરનું ડિમન. ખાતરી કરવી હોય તો docker context inspect પસંદ કરેલા કોન્ટેક્સ્ટનું એન્ડપોઇન્ટ બતાવશે, અને આ આદેશોમાંથી કોઈ પણ કંઈ બદલતું નથી.

DOCKER_HOST જેવું એન્વાયર્નમેન્ટ વેરિયેબલ CLI ને તમે ધારો છો તેના કરતાં અલગ એન્જિન તરફ શાંતિથી નિર્દેશ કરી શકે છે, અને લેપટોપ VPN પર હોય તેમ દેખાય છતાં પુલ બીજે જાય તેની આ સામાન્ય સમજૂતી છે.

ડિમનની પોતાની નેટવર્ક ઓળખ છે

દૂરના એન્જિનને ખાનગી રજિસ્ટ્રી સુધીનો પોતાનો મંજૂર માર્ગ જોઈએ. તમારા લેપટોપના VPN ક્લાયન્ટને જોડવાથી તે લેપટોપને માર્ગ મળે છે; તે લેબ અથવા ક્લાઉડ સબનેટમાં બેઠેલા ડિમનને એ જ ખાનગી સરનામું આપતું નથી. જો એન્જિન Docker Desktop હોય, તો પુલ તેના વર્ચ્યુઅલ મશીનની અંદર થાય છે, જેની પોતાની નેટવર્કિંગ અને પ્રોક્સી રૂપરેખા તમારા શેલના એન્વાયર્નમેન્ટથી અલગ છે.

તેથી હોસ્ટ પર સફળ curl ફક્ત હોસ્ટ વિશેનો પુરાવો છે, તેનાથી વધુ કંઈ નહીં.

કયું રજિસ્ટ્રી વિનિમય પૂરો થયો તે શોધો

ઇમેજ પુલ એક ક્રમ છે: પ્રમાણીકરણ, મેનિફેસ્ટ મેળવવું, અને પછી blob સ્થાનાંતરણ જે ઘણી વાર ઓબ્જેક્ટ સ્ટોરેજ કે CDN એન્ડપોઇન્ટ પર રીડાયરેક્ટ થાય છે. સફળ docker login ફક્ત પ્રથમ પગલું સાબિત કરે છે, અને ટોકન સંપૂર્ણપણે માન્ય હોઈ શકે છે જ્યારે રીડાયરેક્ટ થયેલ blob હોસ્ટ ડિમનના નેટવર્કથી પહોંચનાર ન હોય. કંઈ પણ બદલતા પહેલાં ચોક્કસ સમય, ઇમેજ સંદર્ભ અને ડિમન કે ક્લાયન્ટ લોગની પ્રથમ ઉપયોગી ઘટના નોંધો.

EOF એકલું કોઈ કારણ નામ આપતું નથી. તે કપાયેલું જોડાણ, સ્ટ્રીમ છોડી દેનાર પ્રોક્સી, સમયસમાપ્તિ કે MTU સમસ્યા હોઈ શકે છે, અને સમયચિહ્નિત ઘટના વિના તેમની વચ્ચે અનુમાન કરવું એ જ રીતે લોકો સ્વસ્થ એન્જિન ફરી બનાવે છે. ક્લાયન્ટ આઉટપુટમાંના બાઇટ ઓફસેટને ડેટા તરીકે ગણો, કારણ કે દર વખતે એ જ કદ પર અટકતું સ્થાનાંતરણ ક્યારેય શરૂ ન થતાં સ્થાનાંતરણ કરતાં સાવ જુદું છે. બંને પરિણામો નોંધો અને પ્રયાસો વચ્ચે તેમની તુલના કરો.

જે ઘટક સ્થાનાંતરણ કરે છે તેને રૂપરેખાંકિત કરો

નેટિવ Linux એન્જિન માટે પ્રોક્સી સેવા એન્વાયર્નમેન્ટમાં આવે છે, તમારા શેલમાં નહીં. /etc/systemd/system/docker.service.d/ હેઠળ HTTP_PROXY, HTTPS_PROXY અને NO_PROXY એન્ટ્રીઓ સાથેની drop-in ફાઇલ, ત્યારપછી systemctl daemon-reload અને રીસ્ટાર્ટ, એ દસ્તાવેજીકૃત ગોઠવણ છે. Docker Desktop પોતાની સેટિંગ્સ દ્વારા એ જ મૂલ્યો આપે છે, અને શેલ પ્રોફાઇલ સંપાદિત કરવાથી તેમાંથી કોઈને પણ અસર થતી નથી.

જો રજિસ્ટ્રી સીધી VPN દ્વારા પહોંચવાની હોય, તો ડિમનને રિઝોલ્વર, માર્ગ અને જાણી જોઈને કરેલ પ્રોક્સી બાકાત જોઈએ, ફક્ત બાકાત નહીં. NO_PROXY મેળ એ દરેક ઘટક માટે શબ્દમાળા સરખામણી છે, અને અંતર્ગત માર્ગ વગરની છૂટ પ્રોક્સી સમસ્યા જેવી દેખાતી નિષ્ફળતા ઉત્પન્ન કરે છે.

જ્યારે એન્ટરપ્રાઇઝ TLS નિરીક્ષણ મંજૂર માર્ગ પર હોય, ત્યારે તેનું ચકાસાયેલ રૂટ એન્જિન કે Desktop વર્કફ્લો દ્વારા સ્થાપિત કરો. રજિસ્ટ્રીને insecure-registries માં ઉમેરવું એ બીજો ફેરફાર છે જે માન્યતા ચકાસણી બંધ કરે છે, અને તે ટ્રસ્ટ સ્ટોર રૂપરેખા નથી.

એક નિયંત્રિત પુલ પુનરાવર્તિત કરો અને શું બદલાયું તે તપાસો

એક સીમા બદલો, તેનો માલિક ઘટક રીસ્ટાર્ટ કરો, અને એ જ કોન્ટેક્સ્ટમાંથી એ જ પુલ પુનરાવર્તિત કરો. પરિણામી ઇમેજ સંદર્ભ અને digest ચકાસો, ભૂલની ગેરહાજરી નહીં, કારણ કે કેશ કરેલું સ્તર બીજા પ્રયાસને પહેલા કરતાં ઘણો ઓછો માર્ગ પસાર કરાવી શકે છે. ખરેખર થયેલા સ્થાનાંતરણો ટિકિટમાં રાખો, કારણ કે પુનઃપ્રયાસે ખરેખર શું પરીક્ષણ કર્યું તેનો તે જ એકમાત્ર રેકોર્ડ છે.

બિલ્ડ પગલાં અને ચાલતા કન્ટેનરની પોતાની નેટવર્ક કોન્ટેક્સ્ટ છે, તેથી પુલ પોતે કામ કરે પછી તેમને અલગ પ્રશ્નો તરીકે ગણો.