तपाईंको कर्पोरेट प्रोक्सीले 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 नाम सिकाउन सकिँदैन।
अभिप्रेत विभाजन कायम राख्नुहोस्: आन्तरिक अनुरोधहरूले आफ्नो आन्तरिक मार्ग प्रयोग गर्छन्; बाह्य अनुरोधहरूले स्वीकृत प्रोक्सी राख्छन्। प्रोक्सीलाई विश्वव्यापी रूपमा असक्षम गर्नाले यो एउटा विफलता लुकाउन सक्छ र अर्को बाह्य अनुरोधका लागि आवश्यक मार्ग हटाउन सक्छ।