ப்ராக்ஸி கொள்கலன் DNS கொள்கலனை தானாகப் பயன்படுத்தாதது ஏன்

ஒரே Docker ஹோஸ்ட்டில் ப்ராக்ஸியையும் DNS சேவையகத்தையும் இயக்குவது அவற்றின் DNS பாதைகளை இணைக்காது. மூன்று தனித்தனி உறவுகள் முக்கியம்:

• வலையமைப்பு அணுகல். தனி Compose திட்டங்களுக்கு பொதுவாக தனி இயல்புநிலை வலையமைப்புகள் உள்ளன. சேவைகளை ஒரு திட்டத்திற்குள் அல்லது திட்டங்களுக்கிடையே வெளிப்படையாகப் பங்கிடப்பட்ட வலையமைப்பின் வழியாக ஏற்ற பொது வலையமைப்பில் வைக்கவும்.
• சேவைக் கண்டறிதல். தனிப்பயன் Docker வலையமைப்பின் உள்ளமைந்த DNS கொள்கலன் பெயர்களைத் தீர்க்க முடியும். அது ஒரு பயன்பாட்டிற்கு அண்டை சேவையைக் கண்டறிய உதவுகிறது; ஆனால் அந்த அண்டையை தானாக அதன் DNS தீர்வியாகத் தேர்ந்தெடுக்காது.
• தீர்வி தேர்வு. ப்ராக்ஸி கொள்கலனுக்குள் பயன்படுத்தப்படும் தீர்வியை அடையாளம் காணவும். Compose இன் dns புலம் DNS சேவையக முகவரிகளை ஏற்கிறது. ஒரு பயன்பாட்டில் தீர்க்கப்படும் dns.local போன்ற பெயர் அதை அந்தப் புலத்திற்கு செல்லுபடியாகும் மதிப்பாக ஆக்காது.

வினவலை ப்ராக்ஸி கொள்கலனில் இருந்து அதன் உள்ளமைக்கப்பட்ட தீர்வி முகவரி வரை பின்தொடரவும். அந்த முகவரியில் ஒரு பாதையும் DNS கேட்பானும் இருப்பதை உறுதிப்படுத்தவும். ஹோஸ்ட் துறைமுகம் 53 ஐ வெளியிடுவது ஹோஸ்ட் பக்கத்தில் அணுகல் பாதையை உருவாக்குகிறது; ஆனால் அதைப் பயன்படுத்த கொள்கலன்களுக்குச் சொல்லாது. வலையமைப்பைப் பங்கிடும் கொள்கலன்கள் அதற்குப் பதிலாக நேரடியாகத் தொடர்பு கொள்ளலாம்.

உள்ளமைவு DNS கொள்கலனின் முகவரியைக் குறிப்பிட்டால், இணக்கமான IPAM உள்ளமைவின் கீழ் அதை நிலையாக வைத்திருங்கள். நேற்றைய கொள்கலனில் இருந்து நகலெடுக்கப்பட்ட மாறும் முறையில் ஒதுக்கப்பட்ட முகவரி மீண்டும் உருவாக்கும்போது தோல்வியடையலாம். தீர்வியின் மேல்நோக்குப் பாதையையும் பரிசோதிக்கவும்: பதிலளிக்கப்படாத வினவல்களை அதற்கே திருப்பி அனுப்புவது அணுக முடியாத தீர்வியிலிருந்து வேறுபட்ட தோல்வியை உருவாக்குகிறது.

இறுதியாக, இலக்கை யார் தீர்க்கிறார்கள் என்பதை அடையாளம் காணவும். CONNECT பெயரைத் தீர்க்கும் HTTP ப்ராக்ஸி இந்தக் கொள்கலன் பாதையைப் பயன்படுத்தலாம்; உள்ளூரில் தீர்க்கும் SOCKS வாடிக்கையாளர் பயன்படுத்தாமல் இருக்கலாம். ஹோஸ்ட்டில் செய்யப்படும் தேடல் ஹோஸ்ட்டின் பாதையை நிரூபிக்கிறது, ப்ராக்ஸி செயல்முறையின் பாதையை அல்ல.