आपका कॉर्पोरेट प्रॉक्सी Compose सेवा नाम को हल करने की कोशिश क्यों कर रहा है
एक HTTP क्लाइंट Docker के सेवा-नाम रिज़ॉल्यूशन का उपयोग करने से पहले अपने कॉन्फ़िगर किए गए प्रॉक्सी को आंतरिक सेवा अनुरोध भेज सकता है। सही क्लाइंट के लिए जानबूझकर बायपास जोड़ें।
एप्लिकेशन अपने कॉर्पोरेट प्रॉक्सी के माध्यम से इंटरनेट तक पहुँचता है, लेकिन http://catalog:8080/ विफल हो जाता है और प्रॉक्सी “catalog” को हल नहीं कर सकता। वह अनुरोध शायद कभी Docker के आंतरिक DNS का उपयोग नहीं किया।
एक HTTP क्लाइंट सीधा कनेक्शन बनाने से पहले अपना प्रॉक्सी चुन सकता है। तब बाहरी प्रॉक्सी को ऐसा नाम मिलता है जिसका अर्थ केवल Compose नेटवर्क के भीतर होता है।
- अनुरोध में होस्टनाम का उपयोग करें। Compose सेवाएँ उपयुक्त नेटवर्क पर सेवा नाम से खोजी जा सकती हैं। बदल सकने वाले कंटेनर IP को हार्ड-कोड करने के बजाय उपभोक्ता क्लाइंट के समर्थित बायपास कॉन्फ़िगरेशन में
catalogजोड़ें। - मौजूदा अपवादों को सुरक्षित रखें। पर्यावरण-सजग क्लाइंट के लिए, प्रासंगिक प्रविष्टियों को संगठन की सूची के साथ मिलाएँ:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogइमेज में मौजूद वास्तविक लाइब्रेरी या निष्पादन योग्य फ़ाइल की केस हैंडलिंग, संस्करण और मिलान व्याकरण जाँचें। कोई सार्वभौमिक NO_PROXY पार्सर नहीं है। छोटी इमेज में wget नाम का प्रोग्राम ज़रूरी नहीं कि GNU Wget जैसा व्यवहार करे।
अनुरोध द्वारा सीधा रूटिंग चुनने के बाद, कॉलर और सेवा का साझा नेटवर्क, सुनने वाली सेवा और कंटेनर पोर्ट जाँचें। प्रकाशित होस्ट पोर्ट एक अन्य एंडपॉइंट है। बायपास गुम नेटवर्क अटैचमेंट नहीं जोड़ सकता, जैसे नेटवर्क फिर से बनाना किसी बाहरी प्रॉक्सी को निजी Compose नाम नहीं सिखा सकता।
इच्छित विभाजन बनाए रखें: आंतरिक अनुरोध अपना आंतरिक पथ उपयोग करते हैं; बाहरी अनुरोध स्वीकृत प्रॉक्सी बनाए रखते हैं। प्रॉक्सी को वैश्विक रूप से अक्षम करना इस एक विफलता को छिपा सकता है और साथ ही अगले बाहरी अनुरोध के लिए आवश्यक मार्ग हटा सकता है।