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 सत्यापित करें, त्रुटि की अनुपस्थिति नहीं, क्योंकि कैश की गई परत दूसरे प्रयास में पहले की तुलना में बहुत कम मार्ग तय करा सकती है। जो स्थानांतरण वास्तव में हुए उन्हें टिकट में रखें, क्योंकि पुनः प्रयास ने वास्तव में क्या परखा इसका वही एकमात्र अभिलेख है।

बिल्ड चरणों और चल रहे कंटेनरों के अपने नेटवर्क कॉन्टेक्स्ट होते हैं, इसलिए पुल स्वयं काम करने के बाद उन्हें अलग प्रश्न मानें।