प्रोक्सी कन्टेनरले DNS कन्टेनर किन स्वचालित रूपमा प्रयोग गर्दैन

एउटै Docker होस्टमा प्रोक्सी र DNS सर्भर चलाउँदा तिनका DNS बाटाहरू जोडिँदैनन्। तीन अलग सम्बन्ध महत्त्वपूर्ण छन्:

• नेटवर्क पहुँच। अलग Compose परियोजनाहरूसँग सामान्यतया अलग पूर्वनिर्धारित नेटवर्क हुन्छन्। सेवाहरूलाई उपयुक्त साझा नेटवर्कमा राख्नुहोस्, या त एउटै परियोजनाभित्र वा परियोजनाहरूबीच स्पष्ट रूपमा साझा गरिएको नेटवर्कमार्फत।
• सेवा पत्ता लगाउने। अनुकूलित Docker नेटवर्कको अन्तर्निहित DNS ले कन्टेनरका नामहरू समाधान गर्न सक्छ। यसले अनुप्रयोगलाई छिमेकी पत्ता लगाउन दिन्छ; तर त्यस छिमेकीलाई स्वचालित रूपमा आफ्नो DNS रिजोल्भरका रूपमा छनोट गर्दैन।
• रिजोल्भर छनोट। प्रोक्सी कन्टेनरभित्र प्रयोग हुने रिजोल्भर पहिचान गर्नुहोस्। Compose को dns फिल्डले DNS सर्भरका ठेगानाहरू लिन्छ। अनुप्रयोगमा समाधान हुने dns.local जस्तो नामले यसलाई त्यो फिल्डका लागि मान्य मान बनाउँदैन।

प्रोक्सी कन्टेनरबाट यसको कन्फिगर गरिएको रिजोल्भर ठेगानासम्म क्वेरी ट्र्याक गर्नुहोस्। त्यो ठेगानामा मार्ग र DNS श्रोता रहेको पुष्टि गर्नुहोस्। होस्ट पोर्ट 53 प्रकाशित गर्दा होस्टतर्फ पहुँच मार्ग बन्छ; तर यसले कन्टेनरहरूलाई त्यो प्रयोग गर्न भन्दैन। नेटवर्क साझा गर्ने कन्टेनरहरूले यसको सट्टा सिधै सञ्चार गर्न सक्छन्।

यदि कन्फिगरेसनले DNS कन्टेनरको ठेगाना सन्दर्भ गर्छ भने, यसलाई मिल्ने IPAM कन्फिगरेसनअन्तर्गत स्थिर राख्नुहोस्। हिजोको कन्टेनरबाट प्रतिलिपि गरिएको गतिशील रूपमा तोकिएको ठेगाना पुनः सिर्जना गर्दा असफल हुन सक्छ। रिजोल्भरको माथिल्लो मार्ग पनि जाँच्नुहोस्: जवाफ नपाएका क्वेरीहरू यसैकहाँ फर्काउँदा अगम्य रिजोल्भरभन्दा फरक विफलता उत्पन्न हुन्छ।

अन्तमा, गन्तव्य कसले समाधान गर्छ पहिचान गर्नुहोस्। CONNECT नाम समाधान गर्ने HTTP प्रोक्सीले यो कन्टेनर मार्ग प्रयोग गर्न सक्छ; स्थानीय रूपमा समाधान गर्ने SOCKS क्लाइन्टले नगर्न सक्छ। होसमा गरिएको खोजीले होस्टको मार्ग प्रमाणित गर्छ, प्रोक्सी प्रक्रियाको होइन।