डॉकर नाम समाधान नेटवर्क समस्याएं

उम्मीद है, आपको वास्तव में इस लेख को पढ़ने की कभी आवश्यकता नहीं होगी, और आप केवल इसलिए यहाँ होंगे क्योंकि आप ऊब चुके हैं या आपने गलत प्रकार की खोज की है। या आप वास्तव में एक समस्या का सामना कर रहे हैं जहां आपके डॉकटर कंटेनरों के पास अब इंटरनेट का उपयोग नहीं है, भले ही वे हाल ही में अच्छी तरह से काम करते थे, और आपने अपने वातावरण में कोई बदलाव नहीं किया है।

यह एक बहुत ही अस्पष्ट समस्या बयान की तरह लगता है, लेकिन यह वही है जो मैं अचानक सामना कर रहा था। मेरे कंटेनरों में नेटवर्क एक्सेस नहीं था, त्रुटि के साथ अस्थायी विफलता URL को हल करना। यह नाम समाधान के साथ एक समस्या की तरह लग रहा था, और इसने मुझे अतिरिक्त परेशान किया, क्योंकि ऐसा नहीं होना चाहिए था। लेकिन हम खुद से आगे निकल रहे हैं। टेस्ट होस्ट:उबंटू सिस्टमड के साथ - बाद के लिए महत्वपूर्ण। आइए धीरे-धीरे आगे बढ़ें।

समस्या के बारे में विस्तार से

आपने अपने सिस्टम पर डॉकर को कॉन्फ़िगर किया है। यह अच्छा काम कर रहा है। आपके पास कई छवियां, कई कंटेनर हैं, और आपने उन्नत नेटवर्क नियमों का भी उपयोग किया है, और सब कुछ सही क्रम में लगता है। फिर, आप देखते हैं कि अब आप अपने कंटेनर में कुछ गतिविधियाँ नहीं कर सकते हैं, जैसे अद्यतन या पैकेज स्थापना। इसे डिबग करने का सबसे अच्छा तरीका एक शेल को रनिंग कंटेनर इंस्टेंस से जोड़ना है, जैसा कि मैंने इंट्रो गाइड में बताया है। दरअसल, एक रनिंग कंटेनर के अंदर, आपको कुछ ऐसा दिखाई देता है:

# apt-get update
Err:1 https://archive.ubuntu.com/ubuntu बायोनिक इनरिलीज़
'archive.ubuntu.com' को हल करने में अस्थायी विफलता
0% [सुरक्षा से कनेक्ट हो रहा है। ubuntu.com]

यह एक DNS समस्या (नाम समाधान) जैसा दिखता है। कंटेनर यह पता लगाने में असमर्थ है कि डोमेन नामों को आईपी पतों में कैसे हल किया जाए, और इसलिए यह अपडेट जैसे डेटा प्राप्त करने के लिए सर्वर से कनेक्ट नहीं हो सकता है। यहां दो समस्याएं हैं। एक तो अचानक से समस्या क्यों आई? दो, हमें वास्तव में नेटवर्क को ठीक करने की जरूरत है। अब, मैं आपको दिखाना चाहता हूं कि कैसे एक सुंदर तरीके से इसका निवारण किया जाए।

समाधान

पहले, आइए समझें कि समस्या क्यों हुई। यहां कोई तत्काल उत्तर नहीं है, लेकिन देखने के लिए कुछ चीजों में आपके तत्काल पर्यावरण से अधिक शामिल हो सकते हैं। उदाहरण के लिए, हो सकता है कि आपका होस्ट नहीं बदला हो, लेकिन नेटवर्क में - राउटर, नेटवर्क नीतियां, डीएनएस सर्वर स्वयं हो सकते हैं। चूंकि आप सामान्य रूप से नियंत्रित नहीं कर सकते हैं कि आपके तत्काल सेटअप के बाहर क्या हो रहा है, समस्या का पता लगाने का सबसे अच्छा तरीका यह है कि समस्या का चरण-दर-चरण अलगाव करना है।

यदि आपके होस्ट सिस्टम में नेटवर्क है और URL का समाधान नहीं कर सकता है, तो आपको पहले उसे छांटना होगा। आपके होस्ट और डेस्टिनेशन के बीच और बीच में जो भी नेटवर्क इंफ्रास्ट्रक्चर मौजूद है, उसके बीच सबसे अधिक संभावना है।
यदि आपके होस्ट सिस्टम में नेटवर्क है और URL को सही ढंग से हल कर सकता है, तो समस्या विशेष रूप से यह है कि डॉकर कंटेनर URL को कैसे हल करते हैं। यह वह जगह है जहां हमें आगे ध्यान देने की जरूरत है।
जांचें कि क्या डॉकर नेटवर्क इंटरफेस चालू है और चल रहा है (आईपी या ifconfig जैसी कमांड के साथ)। यदि नहीं, तो आप अगले चरण पर जाने से पहले उसे ठीक कर देंगे।

ifconfig docker0

जांचें कि कंटेनर इंस्टेंस का IP पता है या नहीं। यदि नहीं, तो आपको इसे ठीक करना होगा।

डॉकर निरीक्षण <कंटेनर का नाम या आईडी> | grep -i "ipaddr"

जांचें कि यदि संभव हो तो आपको कंटेनर के अंदर वही परिणाम मिलते हैं (ip या ifconfig)। यदि परिणाम पिछले आदेश में आपने जो देखा है उससे मेल नहीं खाता है, तो आपको उसे ठीक करने की आवश्यकता होगी।
जांचें कि क्या आप कंटेनर को बाहर से पिंग कर सकते हैं (और इसके विपरीत, यदि पिंग कमांड उपलब्ध है)। यदि पिंग काम करता है, तो यह संभवतः एक अच्छा संकेत है कि नेटवर्क सही तरीके से कॉन्फ़िगर किया गया है, और ट्रैफ़िक को अवरुद्ध करने वाले कोई फ़ायरवॉल नियम नहीं हैं (सबसे अधिक संभावना है)।

नाम संकल्प

अगर इन सभी जांचों से कोई अजीब समस्या या त्रुटि नहीं मिलती है, तो अगला कदम डीएनएस समाधान पर ध्यान केंद्रित करना है। उसके लिए विन्यास /etc/resolv.conf विन्यास फाइल में उपलब्ध होगा। यह लिनक्स के भौतिक उदाहरणों के साथ-साथ आभासी मशीनों और कंटेनरों दोनों के लिए सही है। आप शायद नोटिस करेंगे कि कंटेनर कुछ इस तरह का उपयोग करता है:

...
# /etc/resolv.conf के संचालन के समर्थित मोड
# के विवरण के लिए man:systemd-resolved.service(8) देखें।

Search xyz

nameserver X.Y.Z.W
...

नेमसर्वर आईपी पते सबसे अधिक बाहरी आईपी पता (आपके आईएसपी जैसा कुछ) या लोकलहोस्ट (127.0.0.X) होंगे। प्रश्न यह है:क्या ये आपके मेजबान की /etc/resolv.conf फ़ाइल से मेल खाते हैं?

उत्तर है, आपके पास संभवतः आपके होस्ट की /etc/resolv.conf फ़ाइल में लोकलहोस्ट परिभाषित होगा। अब, इसे अपने कंटेनर में आज़माएं। resolv.conf फाइल को संपादित करें और नेमसर्वर लाइन में आईपी एड्रेस को होस्ट के मान =लोकलहोस्ट से मेल खाने वाले पते से बदलें। यदि वह आपकी समस्या का समाधान करता है, तो बढ़िया। लेकिन सबसे अधिक संभावना है, यह नहीं होगा।

लेकिन फिर, इस समय, आपको अपने होस्ट पर नेटवर्क कनेक्टिविटी के साथ कोई समस्या नहीं है। इसलिए हमें आपके परिवेश में DNS सर्वर के वास्तविक पते का पता लगाने की आवश्यकता है। और यह इस तथ्य से और जटिल है कि अधिकांश आधुनिक लिनक्स वितरण सिस्टमड का उपयोग करते हैं। प्लॉट मोटा होता है।

systemd के साथ DNS का पता लगाएं

तो हाँ। हमें यह पता लगाने की आवश्यकता है कि नेमसर्वर क्या है, और हमें उसके लिए एक सिस्टमड कमांड का उपयोग करने की आवश्यकता होगी। सबसे अधिक संभावना है, यदि आपके सिस्टम में सिस्टमड है, तो आप सिस्टमड-रिज़ॉल्यूशन, नेटवर्क नाम रिज़ॉल्यूशन मैनेजर और सेवा का भी उपयोग कर रहे हैं। कॉन्फ़िगरेशन /etc/systemd/resolved.conf के अंतर्गत संग्रहीत है। लेकिन आप सिस्टमड-रिज़ॉल्यूशन कमांड के साथ कमांड लाइन पर भी परिणाम प्राप्त कर सकते हैं:

systemd-resolve --status

Link 3 (wlp59s0)
वर्तमान स्कोप:DNS
LLMNR सेटिंग:हां
MulticastDNS सेटिंग:नहीं
DNSSEC सेटिंग:नहीं
डीएनएसएसईसी समर्थित:नहीं
डीएनएस सर्वर:10.50.34.1
2001:64c:1462:b023::1
डीएनएस डोमेन:dedoimedo

यहाँ क्या हो रहआ हैं? बहुत सी दिलचस्प चीजें। लेकिन जो वास्तव में मायने रखता है वह लाइन है जो डीएनएस सर्वर को पढ़ती है। यह ही हम चाहते है। इस आईपी पते को कंटेनर /etc/resolv.conf फ़ाइल में रखें और पुनः प्रयास करें। आपके पास नेटवर्क फिर से काम करना चाहिए।

फिर यह समस्या क्यों?

अब, हम फिर से क्यों पर चर्चा कर सकते हैं। यदि आप सिस्टमड-रिज़ॉल्यूशन डॉक्यूमेंटेशन को देखते हैं, तो संभव है कि आपके सिस्टम में कुछ बदलाव आया हो (संभवतः एक नियमित अपडेट के कारण भी) जिससे ऑपरेशन का चयनित मोड नाम रिज़ॉल्यूशन के साथ कुछ विरोध का कारण बनता है। विशेष रूप से, यदि हम /etc/resolv.conf को नियंत्रित करने के तरीके को देखते हैं, तो पहला मोड बताता है:

systemd-resolved पारंपरिक Linux प्रोग्राम के साथ अनुकूलता के लिए /run/systemd/resolve/stub-resolv.conf फ़ाइल को बनाए रखता है। यह फ़ाइल /etc/resolv.conf से सिमलिंक की जा सकती है। यह फ़ाइल 127.0.0.53 DNS स्टब (ऊपर देखें) को केवल DNS सर्वर के रूप में सूचीबद्ध करती है। इसमें उन खोज डोमेन की सूची भी शामिल है जो सिस्टमड-सॉल्यूड द्वारा उपयोग में हैं। खोज डोमेन की सूची हमेशा अद्यतित रखी जाती है। ध्यान दें कि /run/systemd/resolve/stub-resolv.conf को अनुप्रयोगों द्वारा सीधे उपयोग नहीं किया जाना चाहिए, लेकिन केवल /etc/resolv.conf से एक सिमलिंक के माध्यम से। यह फ़ाइल /etc/resolv.conf से सिमलिंक की जा सकती है ताकि सही खोज डोमेन सेटिंग के साथ सिस्टमड-सॉल्यूड के लिए स्थानीय DNS API को बायपास करने वाले सभी स्थानीय क्लाइंट को कनेक्ट किया जा सके। संचालन के इस तरीके की अनुशंसा की जाती है।

यदि इस समीकरण में से कोई एक लिंक टूटा हुआ है, या कुछ बदल गया है, तो संभव है कि डॉकर सेवा वास्तव में यह निर्धारित नहीं कर सके कि क्या देता है, और आप बिना किसी नाम के समाधान के समाप्त हो जाते हैं। तो संकल्प [एसआईसी] वास्तविक नेटवर्क डीएनएस पता प्रदान करना है, जिसे कंटेनर समझ और उपयोग कर सकते हैं। मेरी तरफ से यह थोड़ा सट्टा है, लेकिन मुझे लगता है कि यह काफी सही है।

निष्कर्ष

यहाँ हम चलते हैं, एक और रहस्य नष्ट हो गया, एक और विंडस्क्रीन ध्वस्त हो गया। या कुछ और। मुझे अर्ध-जादुई समाधान पसंद नहीं हैं, लेकिन जब आपके पास एक अति-जटिल, स्तरित प्रणाली अवसंरचना होती है, तो कभी-कभी समाधान समस्या के समान ही खराब होते हैं। ऐसा नहीं है कि वे इस मुद्दे को ठीक नहीं करते - इसमें आपके पास कम दृश्यता और नियंत्रण है जो आपको सम्मानपूर्वक करना चाहिए। लेकिन यह लिनक्स का भविष्य है - और सब कुछ आईटी - अंतहीन अमूर्तता।

विषय पर, उम्मीद है कि यह छोटी मार्गदर्शिका आपको अपने कंटेनर रोमांच के लिए अपेक्षाकृत तेज़ और दर्द रहित समाधान प्रदान करेगी। यदि आप डॉकर का उपयोग कर रहे हैं, और नाम रिज़ॉल्यूशन अब कंटेनर इंस्टेंसेस के अंदर काम नहीं करता है, तो शायद आपको ऊपर लिखी गई युक्तियों और ट्रिक्स का परीक्षण करना चाहिए - और फिर अपनी खुद की छवियों को सही जगह पर बनाना चाहिए, इसलिए आपको इसकी आवश्यकता नहीं है यह सब फिर से लड़ो। और ये रहा, अंत।