Docker का डिफ़ॉल्ट पूल बदलने से नेटवर्क फिर से क्रमांकित नहीं होते

default-address-pools बदलने से आपके पास पहले से मौजूद नेटवर्क फिर से क्रमांकित नहीं होते, और ऐसी अपेक्षा करना ही वह तरीका है जिससे एक सावधान योजना अचानक रुकावट में बदल जाती है। यह सेटिंग डेमॉन के नई कॉन्फ़िगरेशन के साथ फिर से शुरू होने के बाद बनने वाले नेटवर्क के लिए स्वचालित आवंटन नियंत्रित करती है। पहले से चल रही हर चीज़ को दिया गया सबनेट बना रहता है, क्योंकि वह सबनेट नेटवर्क की संग्रहीत परिभाषा का हिस्सा है। मिथक सुविधाजनक है क्योंकि वह सुझाव देता है कि एक संपादन हर ओवरलैप ठीक कर देता है, और वास्तविकता दो हिस्सों का काम है: वह रेंज चुनें जो वास्तव में मुक्त है, फिर उन नेटवर्क का माइग्रेशन करें जो मुक्त नहीं हैं।

मिथक: पूल का एक बदलाव ओवरलैप ठीक कर देता है

मिथक का एक निश्चित रूप है। कोई पढ़ता है कि Docker का डिफ़ॉल्ट पूल बदला जा सकता है, उसे बदलता है, डेमॉन फिर से शुरू करता है और निष्कर्ष निकालता है कि कंटेनर नेटवर्क अब ऑफ़िस VPN से टकराता नहीं। पुराना नेटवर्क अब भी वहीं है, अब भी जुड़ा है, और अब भी वह पता रखता है जो टकराता है।

जो बदला है वह आवंटक का भविष्य का व्यवहार है, जो वास्तव में उपयोगी और वास्तव में सीमित है। स्पष्ट --subnet के बिना बने नए नेटवर्क नए पूल से काटे जाते हैं; मौजूदा कभी उस पूल में थे ही नहीं। फिर से शुरू करना नेटवर्क फिर से नहीं बनाता और कंटेनर को उनके बीच नहीं ले जाता। यदि बदलाव के बाद भी लक्षण बना रहे, तो बदलाव वास्तविक था और निदान अधूरा था।

आधार रेंज और आवंटित प्रीफ़िक्स

कॉन्फ़िगरेशन में दो फ़ील्ड हैं जिन्हें आसानी से भ्रमित किया जा सकता है। base वह रेंज है जिससे आवंटक काटता है, और size प्रत्येक आवंटित नेटवर्क की प्रीफ़िक्स लंबाई है, इसलिए 10.10.0.0/16 आधार और 24 आकार उस /16 के भीतर /24 बाँटता है। भूमिकाएँ उलटने से ऐसा आवंटन पैटर्न बनता है जो आप नहीं चाहते थे, आमतौर पर एक विशाल नेटवर्क या समाप्त पूल।

पूल एक आरक्षण है, प्रमाण नहीं। Docker उन टकरावों से बचता है जो उसे होस्ट की रूटिंग तालिका में दिखते हैं, और वह उस VPN को नहीं देख सकता जिससे आपने अभी जुड़ा ही नहीं है।

यही सीमा जानबूझकर चुनने का पूरा कारण है। तुलना करने वाली रेंज वे हैं जहाँ होस्ट को पहुँचना है: ऑफ़िस LAN, कॉर्पोरेट VPN के आंतरिक सबनेट, लैब या स्टेजिंग के प्रीफ़िक्स, और उसी ओवरले पर कोई भी अन्य कंटेनर होस्ट। डेमॉन को छूने से पहले उन्हें CIDR के रूप में लिखें, क्योंकि दिमाग़ की सूची ठीक उसी को छोड़ देगी जो मायने रखती है। फिर ऐसा आधार चुनें जो उनमें से किसी से ओवरलैप न हो, और सूची को परिनियोजन के साथ रखें ताकि अगला व्यक्ति यह अभ्यास स्मृति से न दोहराए।

चुनने से पहले सूची बनाएँ

पहले जो है उसकी सूची बनाएँ। docker network ls नेटवर्क सूचीबद्ध करता है, और docker network inspect bridge -f '{{.IPAM.Config}}' किसी विशेष नेटवर्क का सबनेट छापता है। उपयोगकर्ता-परिभाषित हर नेटवर्क के लिए इसे दोहराएँ, क्योंकि Compose प्रोजेक्ट अपने नेटवर्क बनाते हैं और compose फ़ाइल में स्पष्ट --subnet पूल को पूरी तरह बायपास करता है।

वही अंतिम बिंदु माइग्रेशन के बाद भी टिकता है। पूल बदलना किसी सहकर्मी को compose फ़ाइल में 172.18.0.0/16 पिन करने से नहीं रोकता, और टकराव किसी दूसरे लेखक के साथ लौट आता है।

जो पहले से मौजूद है उसका माइग्रेशन

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

प्रलेखित डेमॉन कॉन्फ़िगरेशन और पुनःआरंभ प्रक्रिया का पालन करें, और रुकावट का समन्वय करें। एकल डेमॉन वाले होस्ट पर, systemctl restart docker कंटेनर को उनकी पुनःआरंभ नीतियों के अनुसार फिर से शुरू करता है, और यह ऐसा व्यवहार है जिसे बाद में नहीं, पहले जानना चाहिए।

फिर उन दो चीज़ों को सत्यापित करें जिन्हें बदलाव को ठीक करना था। docker network inspect से नया सबनेट जाँचें और पुष्टि करें कि वह चुने गए आधार के भीतर है, फिर ip route get 10.20.30.40 से एक प्रतिनिधि VPN गंतव्य का मार्ग जाँचें और पुष्टि करें कि वह वहीं जाता है जहाँ आप अपेक्षा करते हैं, ब्रिज में नहीं। सेवा खोज और कंटेनर-से-कंटेनर संचार भी परखें, क्योंकि भिन्न एड्रेसिंग के साथ फिर से बना नेटवर्क नाम विश्लेषण को ऐसे तोड़ सकता है जो एप्लिकेशन बग जैसा दिखता है।

बाद में भी क्या टूटता है

टिकाऊ हिस्सा रिकॉर्ड है। आवंटन सूची, चुना गया आधार और आकार, और फिर से बने नेटवर्क परिनियोजन के उसी स्थान पर रखें।

रेंज का निजी होना उसे पुनः उपयोग के लिए सुरक्षित नहीं बनाता। 10.0.0.0/8 निजी है और साथ ही सबसे अधिक संभावना वाली चीज़ है जो मार्ग में कहीं पहले से उपयोग में हो, इसलिए उत्तर एक विशिष्ट आरक्षण है, किसी एक ब्लॉक का पक्ष नहीं। Docker नेटवर्क दस्तावेज़ स्वचालित सबनेट आवंटन और पूल फ़ील्ड का वर्णन करता है। रेंज उस आधार पर चुनें जहाँ आपको पहुँचना है, इस आधार पर नहीं कि वह सुव्यवस्थित दिखती है।