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 नेटवर्क दस्तऐवज स्वयंचलित सबनेट वाटप आणि पूल फील्डांचे वर्णन करते. श्रेणी नीटनेटकी दिसते यावरून नाही, तुम्हाला पोहोचायचे आहे त्यावरून निवडा.