VPN सुरू आहे, ब्राउझर अंतर्गत साइट्सपर्यंत पोहोचतो, आणि कंटेनर अजूनही तीच नावे सोडवू शकत नाही. पॅकेज इन्स्टॉल EAI_AGAIN सारख्या नाव-सोडवणी त्रुटीने मरते, किंवा एखादे ॲप्लिकेशन असे डेटाबेस होस्ट शोधू शकत नाही जे होस्ट मशीन कोणत्याही तक्रारीशिवाय सोडवते. कंटेनर VPN ने इन्स्टॉल केलेला रिझॉल्व्हर वापरत नाही. कंटेनर तयार झाला तेव्हा Docker ने होस्टचे रिझॉल्व्हर कॉन्फिगरेशन कॉपी केले, आणि त्यानंतर कोणीही ते पुन्हा कॉपी केले नाही.

एकाच मशीनवर रिझॉल्व्हरची दोन दृश्ये

Linux वर, Docker तयार होताना प्रत्येक कंटेनरला होस्टच्या रिझॉल्व्हर कॉन्फिगरेशनची प्रत देतो, लूपबॅक पत्ते गाळतो, आणि 127.0.0.11 वर एक एम्बेडेड DNS सर्व्हर चालवतो जो क्वेरी बाहेर पाठवतो. कंटेनर सुरू झाल्यानंतर /etc/resolv.conf पुन्हा लिहिणारा VPN क्लायंट त्याच्या आत काहीही बदलत नाही. त्या क्षणी होस्ट रिझॉल्व्हर योगायोगाने बरोबर असेल तरच कंटेनर पुन्हा सुरू करणे मदत करते.

macOS किंवा Windows वर Docker Desktop एक थर जोडते, कारण डेमन व्हर्च्युअल मशीनमध्ये राहतो. होस्टचा VPN रिझॉल्व्हर त्या VM ला कधीच दिसणार नाही असे होऊ शकते, म्हणून पुन्हा सुरू करणे काहीही बदलत नाही. उपाय निवडण्यापूर्वी दोन्ही दृश्ये तुलना करा: होस्टच्या रिझॉल्व्हर यादीच्या पुढे docker exec mycontainer cat /etc/resolv.conf.

होस्ट अंतर्गत रिझॉल्व्हर सूचीबद्ध करत असताना कंटेनर सार्वजनिक रिझॉल्व्हर सूचीबद्ध करत असेल तर तो सार्वजनिक नावे सोडवेल आणि अंतर्गत नावांवर अपयशी होईल. ही विभागणी या समस्येची सही आहे.

पर्याय A: प्रत्येक कंटेनरसाठी टनल रिझॉल्व्हर पास करा

Docker प्रति-कंटेनर DNS सेटिंग्ज स्वीकारतो, आणि हा काम करणारा सर्वात लहान बदल आहे. प्रथम VPN चे रिझॉल्व्हर पत्ते वाचा: macOS वर scutil --dns, Linux वर resolvectl status किंवा क्लायंटचे स्वतःचे स्टेटस आउटपुट. नंतर त्यांच्यासह कंटेनर सुरू करा, उदाहरणार्थ docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose मध्ये तीच सेटिंग सेवेखालील यादी आहे, जिथे ती कोणाच्या शेल इतिहासाऐवजी आवृत्ती नियंत्रणात राहते.

/etc/docker/daemon.json मधील dns ॲरे प्रत्येक नवीन कंटेनरवर लागू होते, जे अधिक नीटनेटके वाटते आणि तसे नाही. टनल बंद असतानाही ते लागू होते, आणि तेव्हा केवळ VPN मधून पोहोचणारा रिझॉल्व्हर सामान्य इमेज पुल तोडतो. प्रति-कंटेनर सेटिंग्ज समजावणे सोपे आणि मागे घेणे सोपे आहे.

पर्याय B: कंटेनर होस्ट नेटवर्क सामायिक करू द्या

होस्ट नेटवर्किंग प्रत पूर्णपणे बाजूला करते, कारण कंटेनर होस्टचा रिझॉल्व्हर आणि होस्टची टनल वापरतो. ते तुम्हाला हवे असलेले नेटवर्क अलगीकरणही काढून टाकते, आणि Docker Desktop अंतर्गत ते तसे वागत नाही. Linux वर अंतर्गत नावे सोडवावी लागणाऱ्या एक-वेळच्या साधनासाठी ही व्यवहार्य निवड आहे.

बिल्डसाठी दोन्हीपैकी कोणताही पर्याय लागू होत नाही, कारण बिल्ड टप्पे रनटाइम फ्लॅग वारसा घेत नाहीत. प्लॅटफॉर्म परवानगी देतो तिथे होस्ट नेटवर्किंगसह बिल्ड करा, किंवा अवलंबित्व इन्स्टॉल टनलची गरज नसलेल्या टप्प्यात ठेवा.

दोन्ही पर्याय जे दुरुस्त करत नाहीत

कंटेनरला तिथपर्यंत मार्ग नसेल तर DNS पत्ता निरुपयोगी आहे. VPN रिझॉल्व्हर सामान्यतः टनलच्या पत्ता-जागेत बसतो, म्हणून कंटेनरला त्या प्रीफिक्सपर्यंत मार्ग हवा. Docker चा डीफॉल्ट ब्रिज सामान्यतः होस्टमार्फत बाहेर मार्गस्थ करतो, आणि होस्टकडे टनल मार्ग असेल व फॉरवर्डिंग सुरू असेल तर ते पुरेसे आहे. स्वतःच्या पत्ता-पूलसह सानुकूल ब्रिज नेटवर्क VPN सबनेटशी टकरीऊ शकतात, आणि मग क्वेरी पूर्णपणे वेगळ्या ठिकाणी जातात.

रिझॉल्व्हर स्वतः डीबग करण्यापूर्वी Docker नेटवर्कचे सबनेट VPN सबनेटशी तपासा. ओव्हरलॅप अशी अयशस्वीता निर्माण करते जी नक्की खराब DNS सर्व्हरसारखी दिसते.

कंटेनरच्या आत तपासा

ब्राउझर किंवा भाषा रनटाइमऐवजी कंटेनरच्या आत getent hosts db.internal ने चाचणी करा, कारण ते स्वतःचे DNS धोरण आणि स्वतःचे कॅशिंग लागू करतात. जर getent नाव सोडवतो आणि ॲप्लिकेशन अजूनही अपयशी होत असेल, तर रिझॉल्व्हर आता बरोबर आहे आणि उर्वरित समस्या ॲप्लिकेशन स्तरावर आहे. जर तो सोडवत नसेल, तर DNS टप्पा पूर्ण झालेला नाही.

DNS सेटिंग्ज बदलल्यानंतर कंटेनर पुन्हा तयार करा. चालू कंटेनरच्या आत /etc/resolv.conf संपादित करणे त्याच्यासोबत नाहीसे होते आणि कॉन्फिगरेशन समस्या कोणी तो पुन्हा सुरू करेपर्यंत तंतोतंत तेवढा वेळ लपवते.

संबंधित लेख