ప్రాక్సీ కంటైనర్ DNS కంటైనర్‌ను స్వయంచాలకంగా ఎందుకు ఉపయోగించదు

ఒకే Docker హోస్ట్‌పై ప్రాక్సీ మరియు DNS సర్వర్‌ను నడపడం వాటి DNS మార్గాలను కలపదు. మూడు వేర్వేరు సంబంధాలు ముఖ్యం:

• నెట్‌వర్క్ చేరువు. వేర్వేరు Compose ప్రాజెక్ట్‌లకు సాధారణంగా వేర్వేరు డిఫాల్ట్ నెట్‌వర్క్‌లు ఉంటాయి. సేవలను సరైన పంచుకున్న నెట్‌వర్క్‌లో ఉంచండి, ఒక ప్రాజెక్ట్ లోపల లేదా ప్రాజెక్ట్‌ల మధ్య స్పష్టంగా పంచుకున్న నెట్‌వర్క్ ద్వారా.
• సేవ అన్వేషణ. అనుకూల Docker నెట్‌వర్క్ యొక్క పొందుపరచిన DNS కంటైనర్ పేర్లను పరిష్కరించగలదు. అది అనువర్తనానికి పొరుగువాడిని కనుగొనడానికి అనుమతిస్తుంది; కానీ ఆ పొరుగువాడిని స్వయంచాలకంగా తన DNS రిజాల్వర్‌గా ఎంచుకోదు.
• రిజాల్వర్ ఎంపిక. ప్రాక్సీ కంటైనర్ లోపల ఉపయోగించే రిజాల్వర్‌ను గుర్తించండి. Compose యొక్క dns ఫీల్డ్ DNS సర్వర్ చిరునామాలను తీసుకుంటుంది. అనువర్తనంలో పరిష్కరించబడే dns.local వంటి పేరు దానిని ఆ ఫీల్డ్‌కు చెల్లుబాటు అయ్యే విలువగా చేయదు.

ప్రశ్నను ప్రాక్సీ కంటైనర్ నుండి దాని కాన్ఫిగర్ చేసిన రిజాల్వర్ చిరునామా వరకు అనుసరించండి. ఆ చిరునామాలో మార్గం మరియు DNS శ్రోత ఉన్నాయని నిర్ధారించండి. హోస్ట్ పోర్ట్ 53 ను ప్రచురించడం హోస్ట్ వైపు యాక్సెస్ మార్గాన్ని సృష్టిస్తుంది; కానీ దానిని ఉపయోగించమని కంటైనర్‌లకు చెప్పదు. నెట్‌వర్క్ పంచుకునే కంటైనర్‌లు బదులుగా నేరుగా సంభాషించగలవు.

కాన్ఫిగరేషన్ DNS కంటైనర్ చిరునామాను సూచిస్తే, సరిపోయే IPAM కాన్ఫిగరేషన్ కింద దానిని స్థిరంగా ఉంచండి. నిన్నటి కంటైనర్ నుండి కాపీ చేసిన డైనమిక్‌గా కేటాయించిన చిరునామా పునఃసృష్టి సమయంలో విఫలమవవచ్చు. రిజాల్వర్ యొక్క ఎగువ మార్గాన్ని కూడా పరిశీలించండి: సమాధానం లేని ప్రశ్నలను దాని వద్దకే తిరిగి పంపడం చేరుకోలేని రిజాల్వర్ కంటే భిన్నమైన వైఫల్యాన్ని సృష్టిస్తుంది.

చివరగా, గమ్యాన్ని ఎవరు పరిష్కరిస్తారో గుర్తించండి. CONNECT పేరును పరిష్కరించే HTTP ప్రాక్సీ ఈ కంటైనర్ మార్గాన్ని ఉపయోగించగలదు; స్థానికంగా పరిష్కరించే SOCKS క్లయింట్ ఉపయోగించకపోవచ్చు. హోస్ట్‌పై చేసిన శోధన హోస్ట్ మార్గాన్ని నిరూపిస్తుంది, ప్రాక్సీ ప్రక్రియ మార్గాన్ని కాదు.