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 अनुरोध सिर्फ उसी ऐप का रास्ता जाँचता है। साझा स्क्रीनशॉट और कमिट की गई फ़ाइलों में प्रॉक्सी क्रेडेंशियल न रखें; डेमन कॉन्फ़िगरेशन और कंटेनर एनवायरनमेंट सीक्रेट स्टोर नहीं हैं।