उम्मीद है, आपको वास्तव में इस लेख को पढ़ने की कभी आवश्यकता नहीं पड़ेगी, और आप केवल यहां हैं क्योंकि आप ऊब गए हैं या गलत प्रकार की खोज की है। या आप वास्तव में एक ऐसे मुद्दे का सामना कर रहे होंगे जहां आपके डॉकर कंटेनरों में अब इंटरनेट एक्सेस नहीं है, भले ही वे हाल ही में अच्छी तरह से काम कर रहे थे, और आपने अपने वातावरण में कोई बदलाव नहीं किया है।
यह एक बहुत ही अस्पष्ट समस्या कथन की तरह लगता है, लेकिन यह वही है जिसका मैं अचानक सामना कर रहा था। मेरे कंटेनरों में नेटवर्क एक्सेस नहीं था, Temporary failure resolving URL जैसी त्रुटि के साथ। यह नाम रिज़ॉल्यूशन के साथ एक मुद्दे की तरह लग रहा था, और इसने मुझे अतिरिक्त परेशान किया, क्योंकि ऐसा नहीं होना चाहिए था। लेकिन हम खुद से आगे बढ़ रहे हैं। टेस्ट होस्ट: systemd के साथ Ubuntu - बाद के लिए महत्वपूर्ण। आइए धीरे-धीरे आगे बढ़ें।
समस्या का विस्तार
आपने अपने सिस्टम पर डॉकर कॉन्फ़िगर किया है। यह अच्छी तरह से काम कर रहा है। आपके पास कई इमेज, कई कंटेनर हैं, और आपने उन्नत नेटवर्क नियमों का भी उपयोग किया है, और सब कुछ सही क्रम में लगता है। फिर, आप देखते हैं कि आप अब अपने कंटेनरों में कुछ गतिविधियां नहीं कर सकते, जैसे अपडेट या पैकेज इंस्टॉलेशन। इसे डीबग करने का सबसे अच्छा तरीका एक रनिंग कंटेनर इंस्टेंस से शेल अटैच करना है, जैसा कि मैंने परिचय गाइड में समझाया है। वास्तव में, एक रनिंग कंटेनर के अंदर, आप कुछ ऐसा देखते हैं:
# apt-get update Err:1 https://archive.ubuntu.com/ubuntu bionic InRelease Temporary failure resolving 'archive.ubuntu.com' 0% [Connecting to security.ubuntu.com]
यह एक DNS समस्या (नाम रिज़ॉल्यूशन) की तरह दिखता है। कंटेनर यह पता लगाने में असमर्थ है कि डोमेन नामों को IP पतों में कैसे हल किया जाए, और इसलिए यह डेटा हथियाने के लिए सर्वर से कनेक्ट नहीं कर सकता, जैसे अपडेट। यहां दो मुद्दे हैं। एक, समस्या अचानक क्यों आई? दो, हमें वास्तव में नेटवर्क को ठीक करने की आवश्यकता है। अब, मैं आपको दिखाना चाहता हूं कि इसे एक सुंदर तरीके से कैसे समस्या निवारण करें।
समाधान
पहले, आइए समझते हैं कि मुद्दा क्यों हुआ। यहां कोई तत्काल उत्तर नहीं है, लेकिन कुछ चीजें जिन पर गौर किया जा सकता है उनमें आपके तत्काल वातावरण से अधिक शामिल हो सकते हैं। उदाहरण के लिए, आपका होस्ट नहीं बदला हो सकता है, लेकिन नेटवर्क बदल सकता है - राउटर, नेटवर्क नीतियां, DNS सर्वर स्वयं। चूंकि आप आमतौर पर अपने तत्काल सेटअप के बाहर क्या हो रहा है इसे नियंत्रित नहीं कर सकते, समस्या का पता लगाने का सबसे अच्छा तरीका समस्या का चरण-दर-चरण अलगाव करना है।
- यदि आपके होस्ट सिस्टम में नेटवर्क है और URL हल नहीं कर सकता, तो आपको पहले इसे सुलझाना होगा। आपके होस्ट और गंतव्य के बीच, और बीच में मौजूद किसी भी नेटवर्क बुनियादी ढांचे के साथ कोई समस्या होने की सबसे अधिक संभावना है।
- यदि आपके होस्ट सिस्टम में नेटवर्क है और सही ढंग से URL हल कर सकता है, तो समस्या विशेष रूप से इस बात में है कि डॉकर कंटेनर URL को कैसे हल करते हैं। यह वह जगह है जहां हमें आगे ध्यान केंद्रित करने की आवश्यकता है।
- जांचें कि डॉकर नेटवर्क इंटरफ़ेस चालू और चल रहा है (ip या ifconfig जैसे कमांड के साथ)। यदि नहीं, तो आपको अगले चरण पर जाने से पहले पहले इसे ठीक करना होगा।
ifconfig docker0
- जांचें कि कंटेनर इंस्टेंस का IP पता है या नहीं। यदि नहीं, तो आपको इसे ठीक करना होगा।
docker inspect| grep -i "ipaddr"
- यदि संभव हो तो कंटेनर के अंदर वही परिणाम प्राप्त करें (ip या ifconfig)। यदि परिणाम पिछली कमांड में आपने जो देखा उससे मेल नहीं खाता, तो आपको इसे ठीक करना होगा।
- जांचें कि क्या आप बाहर से कंटेनर को पिंग कर सकते हैं (और इसके विपरीत, यदि पिंग कमांड उपलब्ध है)। यदि पिंग काम करता है, तो यह शायद एक अच्छा संकेत है कि नेटवर्क सही ढंग से कॉन्फ़िगर किया गया है, और कोई फ़ायरवॉल नियम ट्रैफ़िक को ब्लॉक नहीं कर रहे हैं (सबसे अधिक संभावना)।
नाम रिज़ॉल्यूशन
यदि ये सभी जांच कोई अजीब समस्या या त्रुटि नहीं लौटाती हैं, तो अगला कदम DNS रिज़ॉल्यूशन पर ध्यान केंद्रित करना है। उसके लिए कॉन्फ़िगरेशन /etc/resolv.conf कॉन्फ़िगरेशन फाइल में उपलब्ध होगा। यह भौतिक लिनक्स इंस्टेंस के साथ-साथ वर्चुअल मशीन और कंटेनर दोनों के लिए सही है। आप शायद नोटिस करेंगे कि कंटेनर कुछ ऐसा उपयोग करता है:
... # See man:systemd-resolved.service(8) for details about the supported modes # of operation for /etc/resolv.conf. search xyz nameserver X.Y.Z.W ...
nameserver IP पते सबसे अधिक संभावना एक बाहरी IP पता (आपके ISP की तरह) या लोकलहोस्ट (127.0.0.X) होगा। सवाल है: क्या ये आपके होस्ट के /etc/resolv.conf फाइल से मेल खाते हैं?
उत्तर है, आपके होस्ट के /etc/resolv.conf फाइल में लोकलहोस्ट परिभाषित होने की सबसे अधिक संभावना है। अब, अपने कंटेनर में इसे आज़माएं। resolv.conf फाइल को संपादित करें और nameserver लाइन में IP पते को उस मान से बदलें जो होस्ट के मूल्य = लोकलहोस्ट से मेल खाता है। यदि यह आपकी समस्या हल करता है, तो बढ़िया। लेकिन सबसे अधिक संभावना है, यह नहीं करेगा।
लेकिन फिर, इस बिंदु पर, आपके होस्ट पर नेटवर्क कनेक्टिविटी के साथ कोई समस्या नहीं है। इसलिए हमें आपके वातावरण में DNS सर्वर के असली पते का पता लगाने की आवश्यकता है। और यह इस तथ्य से और जटिल है कि अधिकांश आधुनिक लिनक्स वितरण systemd का उपयोग करते हैं। प्लॉट गाढ़ा होता है।
systemd के साथ DNS पता करें
तो हां। हमें यह पता लगाने की आवश्यकता है कि nameserver क्या है, और हमें उसके लिए एक systemd कमांड का उपयोग करना होगा। सबसे अधिक संभावना है, यदि आपके सिस्टम में systemd है, तो आप systemd-resolve, नेटवर्क नाम रिज़ॉल्यूशन मैनेजर और सेवा का भी उपयोग कर रहे हैं। कॉन्फ़िगरेशन /etc/systemd/resolved.conf के तहत संग्रहीत है। लेकिन आप कमांड लाइन पर systemd-resolve कमांड के साथ परिणाम भी प्राप्त कर सकते हैं:
systemd-resolve --status
Link 3 (wlp59s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 10.50.34.1
2001:64c:1462:b023::1
DNS Domain: dedoimedo
यहां हमारे पास क्या है? बहुत दिलचस्प सामान। लेकिन जो वास्तव में मायने रखता है वह वह लाइन है जो DNS Servers पढ़ती है। यह वही है जो हम चाहते हैं। इस IP पते को कंटेनर /etc/resolv.conf फाइल में रखें और फिर से प्रयास करें। आपके पास नेटवर्क फिर से काम करना चाहिए।
यह समस्या क्यों?
अब, हम फिर से क्यों पर चर्चा कर सकते हैं। यदि आप systemd-resolve दस्तावेज़ीकरण को देखते हैं, तो यह संभव है कि आपके सिस्टम में कुछ परिवर्तन हुआ हो (संभवतः नियमित अपडेट के कारण भी) जिससे ऑपरेशन का चयनित मोड नाम रिज़ॉल्यूशन के साथ कुछ संघर्ष का कारण बनता है। विशेष रूप से, यदि हम इस बात को देखते हैं कि /etc/resolv.conf को कैसे संभाला जाता है, तो पहला मोड बताता है:
systemd-resolved पारंपरिक लिनक्स प्रोग्राम के साथ संगतता के लिए /run/systemd/resolve/stub-resolv.conf फाइल को बनाए रखता है। इस फाइल को /etc/resolv.conf से सिमलिंक किया जा सकता है। यह फाइल 127.0.0.53 DNS स्टब (ऊपर देखें) को एकमात्र DNS सर्वर के रूप में सूचीबद्ध करती है। इसमें सर्च डोमेन की एक सूची भी होती है जो systemd-resolved द्वारा उपयोग में होती है। सर्च डोमेन की सूची हमेशा अद्यतित रखी जाती है। ध्यान दें कि /run/systemd/resolve/stub-resolv.conf को अनुप्रयोगों द्वारा सीधे उपयोग नहीं किया जाना चाहिए, बल्कि केवल /etc/resolv.conf से एक सिमलिंक के माध्यम से। इस फाइल को /etc/resolv.conf से सिमलिंक किया जा सकता है ताकि स्थानीय DNS API को बायपास करने वाले सभी स्थानीय क्लाइंट को सही सर्च डोमेन सेटिंग्स के साथ systemd-resolved से जोड़ा जा सके। ऑपरेशन का यह मोड अनुशंसित है।
यदि इस समीकरण में लिंक में से एक टूट गया है, या कुछ बदल गया है, तो यह संभव है कि डॉकर सेवा वास्तव में यह निर्धारित नहीं कर सकती कि क्या हो रहा है, और आप बिना नाम रिज़ॉल्यूशन के समाप्त होते हैं। तो समाधान [sic] वास्तविक नेटवर्क DNS पते को प्रदान करना है, जिसे कंटेनर समझ और उपयोग कर सकते हैं। यह मेरी तरफ से थोड़ा सट्टा है, लेकिन मुझे लगता है कि यह काफी सही है।
निष्कर्ष
यहां हम जाते हैं, एक और रहस्य सुलझा, एक और विंडस्क्रीन रहस्यमय। या कुछ। मुझे आधे-जादू समाधान पसंद नहीं हैं, लेकिन जब आपके पास एक सुपर-जटिल, स्तरित प्रणाली बुनियादी ढांचा होता है, तो कभी-कभी समाधान समस्या जितने ही खराब होते हैं। नहीं कि वे इस मायने में खराब हैं कि वे मुद्दे को ठीक नहीं करते - इसमें कि आपके पास सम्मानजनक रूप से कम दृश्यता और नियंत्रण है। लेकिन यह लिनक्स का भविष्य है - और सब कुछ IT - अंतहीन अमूर्तता।
विषय पर, उम्मीद है कि यह छोटा गाइड आपके कंटेनर रोमांच के लिए अपेक्षाकृत त्वरित और दर्द रहित फिक्स प्रदान करेगा। यदि आप डॉकर का उपयोग कर रहे हैं, और कंटेनर इंस्टेंस के अंदर नाम रिज़ॉल्यूशन अब काम नहीं करता है, तो शायद आपको ऊपर लिखे सुझावों और तरकीबों का परीक्षण करना चाहिए - और फिर सही फिक्स के साथ अपनी खुद की इमेज बनाएं, ताकि आपको इससे फिर से न लड़ना पड़े। और वहां आप जाते हैं, अंत।
Cheers.