curl, .NET आणि कंटेनरमध्ये NO_PROXY सुसंगतता
सामायिक थेट-मार्गनिर्देशन धोरणाला थोड्या प्रातिनिधिक गंतव्यांचा वापर करून क्लायंट-विशिष्ट संरचनेत बदला.
एक संघ सामायिक environment फाइलमध्ये एक बायपास स्ट्रिंग ठेवतो. curl थेट जातो, दुसरे अनुप्रयोग प्रॉक्सी वापरतात, आणि कंटेनर पुन्हा वेगळे वागतो. सामायिक फाइलने तीच अक्षरे वितरित केली. तिने एक सामायिक पार्सर वितरित केला नाही.
टिकाऊ वस्तू धोरण आहे: कोणती गंतव्ये थेट असावीत, कोणत्या अटींनुसार? ते प्रत्येक कार्यक्रमाला लागणाऱ्या स्ट्रिंगपासून वेगळे ठेवा.
प्रथम अपेक्षित मार्ग लिहा
फक्त सोपे यश नव्हे, तर सीमा प्रकरणे समाविष्ट करून प्रातिनिधिक पत्ते वापरा:
| गंतव्याचा आकार | धोरण मालकासाठी प्रश्न |
|---|---|
| पालक डोमेन | ते बायपास व्हावे की फक्त त्याची मुले? |
| उपडोमेन | ते तोच मार्ग वारसा घेते का? |
| शब्दशः खाजगी IP | तो पत्ता या क्लायंटवरून थेट पोहोचण्यायोग्य आहे का? |
| होस्टनावाखालील तीच सेवा | नाव-आधारित आणि पत्ता-आधारित विनंत्या जुळल्या पाहिजेत का? |
| दुसरे सेवा पोर्ट | अपवाद होस्टला लागू होतो की एका श्रोत्याला? |
मग ग्राहक ओळखा: प्रतिमा ओढणारा डेमन, कंटेनरमधील कार्यक्रम, भाषेची HTTP लायब्ररी आणि संवादी ब्राउझर हे सर्व स्वतंत्र नोंदी असू शकतात. Docker क्लायंट प्रॉक्सी संरचना कंटेनरची environment मूल्ये भरू शकते, आतल्या प्रत्येक क्लायंटला तेच जुळणी नियम लागू करावे लागत नाहीत.
आंधळेपणे कॉपी करण्याऐवजी भाषांतर करा
वास्तविक फरकाचे एक नोंदवलेले उदाहरण म्हणजे पालक-डोमेन सीमा. curl चे डोमेन वगळणे नामांकित डोमेन आणि जुळणारी मुले यांना व्यापते. .NET चे environment धोरण कोरे नाव आणि आघाडीच्या बिंदूसह उपडोमेन स्वरूप यात फरक करते. „नेहमी आघाडीचा बिंदू जोडा“ हा सार्वत्रिक नियम दोन्ही धोरणे विश्वासार्हपणे व्यक्त करू शकत नाही.
IP-श्रेणी समर्थन देखील ग्राहक आणि त्याच्या आवृत्तीवर अवलंबून असते. नवीन स्वतंत्र curl असलेले यंत्र जुन्या libcurl शी जोडलेला अनुप्रयोग किंवा पूर्णपणे दुसरी लायब्ररी वापरणारा क्लायंट चालवू शकते. ऑपरेटिंग सिस्टमची आवृत्ती संपूर्ण क्लायंट यादी नाही.
प्रत्येक ग्राहकासाठी, त्याचा समर्थित संरचना इंटरफेस आणि इच्छित मार्गांची सर्वात लहान अभिव्यक्ती नोंदवा. ज्याचा अर्थ कोणीही समजावू शकत नाही अशा हुशार नमुन्यापेक्षा छोटी स्पष्ट होस्ट यादी चांगली असू शकते.
संरचना पुरावा कनेक्शन पुराव्यापासून वेगळा ठेवा
विश्लेषित सेटिंग किंवा मार्गनिर्णय API कार्यक्रमाने काय निवडले हे दाखवू शकते. विनंतीचा निकाल नंतर तो मार्ग वापरण्यायोग्य होता का हे दाखवतो. .NET मध्ये, HttpClient.DefaultProxy.IsBypassed जेव्हा डीफॉल्ट प्रॉक्सी वापरातील धोरण असते तेव्हा ती संरचना-बाजूची तपासणी पुरवते. विनंतीची वेळ संपली या एकाच कारणाने पोहोच न येणाऱ्या थेट सेवेचे निदान बायपास-पार्सर अपयश म्हणून करू नका.
क्लायंट किंवा बेस इमेज अद्ययावत करताना सीमा गंतव्ये ठेवा. फाइलमध्ये दोन सारख्याच दिसणाऱ्या डोमेन नोंदी का आहेत हे संपूर्ण संघाला पुन्हा शोधावे लागणार नाही अशा प्रकारे ती भविष्यातील सुसंगतता बदल दृश्यमान करतात.