curl, .NET और कंटेनर में NO_PROXY संगतता
एक साझा सीधे-रूटिंग नीति को छोटे प्रतिनिधि गंतव्यों के समूह का उपयोग करके क्लाइंट-विशिष्ट कॉन्फ़िगरेशन में बदलें।
एक टीम साझा पर्यावरण फ़ाइल में एक बायपास स्ट्रिंग रखती है। curl सीधे जाता है, दूसरा एप्लिकेशन प्रॉक्सी का उपयोग करता है, और कंटेनर फिर से अलग व्यवहार करता है। साझा फ़ाइल ने वही अक्षर वितरित किए। लेकिन उसने एक साझा पार्सर वितरित नहीं किया।
स्थायी वस्तु नीति है: कौन-से गंतव्य सीधे होने चाहिए, किन शर्तों के अंतर्गत? इसे उस स्ट्रिंग से अलग रखें जिसकी हर प्रोग्राम को आवश्यकता है।
पहले अपेक्षित रूट लिखें
केवल आसान सफलताओं के बजाय सीमाओं सहित प्रतिनिधि पते उपयोग करें:
| गंतव्य का आकार | नीति के स्वामी के लिए प्रश्न |
|---|---|
| मूल डोमेन | क्या इसे बायपास करना चाहिए, या केवल इसके बच्चों को? |
| एक सबडोमेन | क्या यह वही रूट विरासत में लेता है? |
| एक शाब्दिक निजी IP | क्या वह पता इस क्लाइंट से सीधे पहुँचा जा सकता है? |
| होस्टनाम के अंतर्गत वही सेवा | क्या नाम-आधारित और पता-आधारित अनुरोध सहमत होने चाहिए? |
| दूसरा सेवा पोर्ट | क्या अपवाद होस्ट को कवर करता है या एक श्रोता को? |
फिर उपभोक्ताओं की पहचान करें: इमेज खींचने वाला डेमॉन, कंटेनर के अंदर का प्रोग्राम, किसी भाषा की HTTP लाइब्रेरी और एक इंटरैक्टिव ब्राउज़र सभी अलग प्रविष्टियाँ हो सकते हैं। Docker क्लाइंट प्रॉक्सी कॉन्फ़िगरेशन कंटेनर पर्यावरण मान भर सकता है, बिना अंदर के हर क्लाइंट को वही मिलान नियम लागू करने की आवश्यकता के।
अंधाधुंध नकल करने के बजाय अनुवाद करें
वास्तविक अंतर का एक प्रलेखित उदाहरण मूल-डोमेन सीमा है। curl का डोमेन बहिष्करण नामित डोमेन और मेल खाने वाले बच्चों को कवर करता है। .NET की पर्यावरण नीति नंगे नाम को अग्रणी बिंदु वाले सबडोमेन रूप से अलग करती है। हमेशा अग्रणी बिंदु जोड़ें जैसा सार्वभौमिक नियम दोनों नीतियों को विश्वसनीय रूप से व्यक्त नहीं कर सकता।
IP श्रेणी समर्थन भी उपभोक्ता और उसके संस्करण पर निर्भर करता है। नए स्टैंडअलोन curl वाली मशीन अभी भी पुरानी libcurl से जुड़ा एप्लिकेशन, या पूरी तरह से दूसरी लाइब्रेरी उपयोग करने वाला क्लाइंट चला सकती है। ऑपरेटिंग सिस्टम का संस्करण पूरी क्लाइंट सूची नहीं है।
प्रत्येक उपभोक्ता के लिए उसका समर्थित कॉन्फ़िगरेशन इंटरफ़ेस और इच्छित रूट की सबसे छोटी अभिव्यक्ति दर्ज करें। एक छोटी स्पष्ट होस्ट सूची ऐसे चतुर पैटर्न से बेहतर हो सकती है जिसका अर्थ कोई समझा न सके।
कॉन्फ़िगरेशन साक्ष्य को कनेक्शन साक्ष्य से अलग रखें
एक पार्स किया गया सेटिंग या रूटिंग-निर्णय API दिखा सकता है कि प्रोग्राम ने क्या चुना। फिर अनुरोध का परिणाम दिखाता है कि वह रूट उपयोगी था या नहीं। .NET में, HttpClient.DefaultProxy.IsBypassed वह कॉन्फ़िगरेशन-पक्ष जाँच प्रदान करता है जब डिफ़ॉल्ट प्रॉक्सी ही उपयोग की जाने वाली नीति हो। केवल इस कारण से कि अनुरोध का समय समाप्त हो गया, किसी अगम्य सीधी सेवा को बायपास-पार्सर विफलता के रूप में निदान न करें।
क्लाइंट या बेस इमेज अपडेट करते समय सीमा गंतव्यों को बनाए रखें। वे भविष्य के संगतता परिवर्तनों को दृश्यमान बनाते हैं, बिना पूरी टीम को फिर से यह खोजने की आवश्यकता के कि फ़ाइल में दो समान दिखने वाली डोमेन प्रविष्टियाँ क्यों हैं।