docker pull ले कन्टेनरको प्रोक्सी सेटिङ किन मान्दैन?

docker pull असफल भए Docker डेमन वा Docker Desktop कन्फिगर गर्नुहोस्। एप्लिकेसन कन्टेनरले आफ्ना प्रोक्सी भेरिएबल पढ्नुअघि नै इमेज डाउनलोड हुन्छ।

नेटिभ Docker Engine

यो भाग विद्यमान डेमन प्रोक्सी कन्फिगरेसनमा मिलाउनुहोस्, कागजातको एन्डपोइन्ट बदल्नुहोस् र असम्बन्धित सेटिङ राख्नुहोस्। सार्वजनिक प्रोक्सी अनुमति भएको सार्वजनिक इमेज परीक्षणका लागि HTTP प्रोक्सी सूचीले उम्मेदवार दिन्छ:

{
  "proxies": {
    "http-proxy": "http://203.0.113.10:8080",
    "https-proxy": "http://203.0.113.10:8080",
    "no-proxy": "localhost,127.0.0.1,registry.example.internal"
  }
}

डेमनका हाइफन भएका की Docker क्लाइन्टको ~/.docker/config.json का camelCase कीभन्दा फरक हुन्। क्लाइन्टको प्रोक्सी भागले नयाँ कन्टेनर र बिल्डलाई वातावरण भेरिएबल दिन्छ; डेमनको डाउनलोड वा पहिलेका कन्टेनरको वातावरण कन्फिगर गर्दैन।

इन्स्टलेसनको कागजातअनुसार डेमन पुनः सुरु गरी चालु काममा पर्ने असर योजना गर्नुहोस्। डेमनले सुरुआती वातावरणमा पनि प्रोक्सी भेरिएबल लिन सक्छ; पछिको टर्मिनलमा export गर्दा चलिरहेको सेवा अद्यावधिक हुँदैन।

Docker Desktop

Desktop का आफ्नै प्रोक्सी सेटिङ प्रयोग गर्नुहोस्। Docker कागजातअनुसार Desktop ले daemon.json का प्रोक्सी प्रविष्टि बेवास्ता गर्छ, त्यसैले नेटिभ Engine उदाहरण बारम्बार बदल्दा यस उत्पादनको बाटो कन्फिगर हुँदैन।

सही भाग अद्यावधिक गरेपछि इमेज फेरि तान्नुहोस्। रजिस्ट्री पहुँच, प्रमाणीकरण, रिडाइरेक्ट वा लेयर डाउनलोडमध्ये के असफल भयो पढ्नुहोस्। विद्यमान कन्टेनरभित्र सफल HTTP अनुरोधले त्यस एपको बाटो मात्र जाँच्छ। साझा स्क्रिनसट वा कमिट फाइलमा प्रोक्सी लगइन विवरण नराख्नुहोस्; डेमन कन्फिगरेसन र कन्टेनरको वातावरण गोप्य भण्डार होइनन्।