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 तपासा, कारण कॅश केलेला स्तर दुसऱ्या प्रयत्नाला पहिल्यापेक्षा खूप कमी मार्गाने जाऊ देऊ शकतो. प्रत्यक्षात झालेली हस्तांतरणे तिकिटात ठेवा, कारण पुनर्प्रयत्नाने खरोखर काय चाचणी केली याची तीच एकमेव नोंद आहे.

बिल्ड टप्पे आणि चालू असलेल्या कंटेनरची स्वतःची नेटवर्क कॉन्टेक्स्ट असतात, म्हणून पुल स्वतः काम करू लागल्यावर त्यांना वेगळे प्रश्न माना.