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 नेटवर्क अभिलेख ले स्वचालित सबनेट बाँडफाँट र पूलका फिल्डहरू वर्णन गर्छ। दायरा सफा देखिन्छ कि भन्ने आधारमा नभई तपाईंले पुग्नुपर्ने ठाउँका आधारमा छान्नुहोस्।