curl, .NET र कन्टेनरहरूमा NO_PROXY अनुकूलता
साझा प्रत्यक्ष-रुटिङ नीतिलाई सानो समूह प्रतिनिधि गन्तव्यहरू प्रयोग गरेर ग्राहक-विशेष कन्फिगरेसनमा बदल्नुहोस्।
एउटा टोलीले साझा environment फाइलमा एउटा बाइपास स्ट्रिङ राख्छ। curl सिधै जान्छ, अर्को अनुप्रयोगले proxy प्रयोग गर्छ, र कन्टेनर फेरि फरक व्यवहार गर्छ। साझा फाइलले एउटै अक्षरहरू वितरण गर्यो। यसले एउटै साझा parser वितरण गरेन।
टिकाउ वस्तु नीति हो: कुन गन्तव्यहरू सिधै हुनुपर्छ, कुन सर्तहरूमा? त्यसलाई प्रत्येक कार्यक्रमलाई चाहिने स्ट्रिङबाट अलग राख्नुहोस्।
पहिले अपेक्षित मार्गहरू लेख्नुहोस्
सजिलो सफलता मात्र होइन, सीमा अवस्थाहरू सहित प्रतिनिधि ठेगानाहरू प्रयोग गर्नुहोस्:
| गन्तव्यको आकार | नीति मालिकका लागि प्रश्न |
|---|---|
| अभिभावक डोमेन | यसलाई बाइपास गर्ने हो, वा यसका बच्चाहरूलाई मात्र? |
| उपडोमेन | यसले उही मार्ग पाउँछ? |
| शाब्दिक निजी IP | त्यो ठेगाना यो ग्राहकबाट सिधै पुग्न सकिन्छ? |
| एउटै सेवा hostname अन्तर्गत | नाम-आधारित र ठेगाना-आधारित अनुरोधहरू मिल्नुपर्छ? |
| अर्को सेवा पोर्ट | अपवादले host लाई समेट्छ वा एउटा सुन्नेलाई? |
त्यसपछि उपभोक्ताहरू पहिचान गर्नुहोस्: image तान्ने daemon, कन्टेनरभित्रको कार्यक्रम, भाषाको HTTP लाइब्रेरी र अन्तरक्रियात्मक ब्राउजर सबै छुट्टाछुट्टै प्रविष्टि हुन सक्छन्। Docker ग्राहक proxy कन्फिगरेसनले कन्टेनरको environment मानहरू भर्न सक्छ, भित्रको प्रत्येक ग्राहकले उही मिलान नियमहरू लागू गर्नुपर्दैन।
अन्धाधुन्ध प्रतिलिपि नगरी अनुवाद गर्नुहोस्
वास्तविक भिन्नताको एउटा अभिलेखित उदाहरण अभिभावक-डोमेन सीमा हो। curl को डोमेन बहिष्कारले नामित डोमेन र मिल्ने बच्चाहरूलाई समेट्छ। .NET को environment नीतिले खाली नाम र अगाडि बिन्दु भएको उपडोमेन रूपलाई छुट्याउँछ। „सधैं अगाडि बिन्दु थप्नुहोस्“ भन्ने सार्वभौमिक नियमले दुवै नीति भरपर्दो रूपमा व्यक्त गर्न सक्दैन।
IP-दायरा समर्थन पनि उपभोक्ता र यसको संस्करणमा निर्भर गर्छ। नयाँ स्वतन्त्र curl भएको मेसिनले पुरानो libcurl सँग जोडिएको अनुप्रयोग वा पूर्ण रूपमा अर्को लाइब्रेरी प्रयोग गर्ने ग्राहक चलाउन सक्छ। अपरेटिङ सिस्टमको रिलिज पूर्ण ग्राहक सूची होइन।
प्रत्येक उपभोक्ताका लागि, यसको समर्थित कन्फिगरेसन इन्टरफेस र इच्छित मार्गहरूको सबैभन्दा सानो अभिव्यक्ति अभिलेख गर्नुहोस्। जसको अर्थ कसैले पनि व्याख्या गर्न नसक्ने चलाख ढाँचाभन्दा छोटो स्पष्ट host सूची राम्रो हुन सक्छ।
कन्फिगरेसन प्रमाणलाई जडान प्रमाणबाट अलग राख्नुहोस्
विश्लेषण गरिएको सेटिङ वा रुटिङ-निर्णय API ले कार्यक्रमले के छान्यो देखाउन सक्छ। अनुरोधको नतिजाले त्यसपछि त्यो मार्ग प्रयोगयोग्य थियो कि थिएन देखाउँछ। .NET मा, HttpClient.DefaultProxy.IsBypassed ले पूर्वनिर्धारित proxy प्रयोगमा रहेको नीति हुँदा त्यो कन्फिगरेसन-पक्षको जाँच दिन्छ। अनुरोधको समय सकियो भनेर मात्र पुग्न नसकिने प्रत्यक्ष सेवालाई बाइपास-पार्सर असफलता ठानेर निदान नगर्नुहोस्।
ग्राहक वा आधार image अद्यावधिक गर्दा सीमा गन्तव्यहरू राख्नुहोस्। फाइलमा दुई समान देखिने डोमेन प्रविष्टि किन छन् भनी सम्पूर्ण टोलीले फेरि पत्ता लगाउनु नपरी तिनले भविष्यका अनुकूलता परिवर्तनहरू देखिने बनाउँछन्।