Docker இன் இயல்புநிலைக் குளத்தை மாற்றுவது வலையமைப்புகளை மறுஎண்ணிடாது

default-address-pools மாற்றுவது உங்களிடம் ஏற்கனவே உள்ள வலையமைப்புகளை மறுஎண்ணிடாது, அதை எதிர்பார்ப்பதே கவனமான திட்டத்தை எதிர்பாராத இடைநிறுத்தமாக மாற்றும் வழி. இந்த அமைப்பு புதிய கட்டமைப்புடன் டீமன் மீண்டும் தொடங்கிய பிறகு உருவாக்கப்படும் வலையமைப்புகளுக்கான தானியங்கி ஒதுக்கீட்டைக் கட்டுப்படுத்துகிறது. ஏற்கனவே இயங்கும் அனைத்தும் தனக்கு வழங்கப்பட்ட துணை வலையமைப்பைத் தக்கவைத்துக்கொள்கிறது, ஏனெனில் அந்த துணை வலையமைப்பு வலையமைப்பின் சேமிக்கப்பட்ட வரையறையின் பகுதியாகும். ஒரே திருத்தம் ஒவ்வொரு மேலோட்டத்தையும் சரிசெய்கிறது எனப் பரிந்துரைப்பதால் புராணம் வசதியாக உள்ளது, உண்மையோ இரண்டு பகுதிகளின் வேலை: உண்மையிலேயே காலியாக உள்ள வரம்பைத் தேர்ந்தெடுத்து, பின்னர் காலியாக இல்லாத வலையமைப்புகளை இடமாற்றுங்கள்.

புராணம்: ஒரு குள மாற்றம் மேலோட்டத்தைச் சரிசெய்கிறது

புராணத்திற்கு ஒரு குறிப்பிட்ட வடிவம் உண்டு. Docker இன் இயல்புநிலைக் குளத்தை மாற்றலாம் என ஒருவர் படித்து, அதை மாற்றி, டீமனை மீண்டும் தொடங்கி, கொண்டெய்னர் வலையமைப்பு இனி அலுவலக VPN உடன் மோதாது என முடிவெடுக்கிறார். பழைய வலையமைப்பு இன்னும் அங்கேயே உள்ளது, இன்னும் இணைக்கப்பட்டுள்ளது, மோதும் முகவரியையும் இன்னும் வைத்திருக்கிறது.

மாறியது ஒதுக்கீட்டாளரின் எதிர்கால நடத்தை, அது உண்மையிலேயே பயனுள்ளதும் உண்மையிலேயே வரம்புடையதும் ஆகும். வெளிப்படையான --subnet இல்லாமல் உருவாக்கப்படும் புதிய வலையமைப்புகள் புதிய குளத்திலிருந்து வெட்டப்படுகின்றன; ஏற்கனவே உள்ளவை அந்தக் குளத்தில் ஒருபோதும் இருந்ததில்லை. மீண்டும் தொடங்குவது வலையமைப்புகளை மீண்டும் கட்டமைக்காது, கொண்டெய்னர்களை அவற்றுக்கிடையே நகர்த்தாது. மாற்றத்திற்குப் பிறகும் அறிகுறி தொடர்ந்தால், மாற்றம் உண்மையானது, நோயறிதல் முழுமையற்றது.

அடிப்படை வரம்பும் ஒதுக்கப்பட்ட முன்னொட்டும்

கட்டமைப்பில் குழப்பிக்கொள்ள எளிதான இரண்டு புலங்கள் உள்ளன. base என்பது ஒதுக்கீட்டாளர் வெட்டும் வரம்பு, size என்பது ஒதுக்கப்பட்ட ஒவ்வொரு வலையமைப்பின் முன்னொட்டு நீளம், எனவே 10.10.0.0/16 அடிப்படையும் 24 அளவும் அந்த /16 இற்குள் /24 பங்கிடுகிறது. பங்குகளைத் தலைகீழாக்கினால் நீங்கள் கருதாத ஒதுக்கீட்டு முறை உருவாகும், பொதுவாக ஒரு பெரிய வலையமைப்பு அல்லது தீர்ந்த குளம்.

குளம் ஒரு முன்பதிவு, ஆதாரம் அல்ல. Docker ஹோஸ்ட்டின் வழித்தட அட்டவணையில் காணும் மோதல்களைத் தவிர்க்கிறது, நீங்கள் இன்னும் இணைக்காத VPN ஐ அது காண முடியாது.

இந்த வரம்பே உணர்வுப்பூர்வமாகத் தேர்ந்தெடுப்பதற்கான முழுக் காரணம். ஒப்பிட வேண்டிய வரம்புகள் ஹோஸ்ட் அடைய வேண்டியவை: அலுவலக LAN, நிறுவன VPN இன் உள் துணை வலையமைப்புகள், ஆய்வகம் அல்லது staging முன்னொட்டுகள், அதே overlay இல் உள்ள வேறு எந்த கொண்டெய்னர் ஹோஸ்ட்டும். டீமனைத் தொடுவதற்கு முன் அவற்றை 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 வலையமைப்பு ஆவணம் தானியங்கி துணை வலையமைப்பு ஒதுக்கீட்டையும் குளப் புலங்களையும் விவரிக்கிறது. வரம்பை நீங்கள் அடைய வேண்டியதன் அடிப்படையில் தேர்ந்தெடுங்கள், ஒழுங்காகத் தெரிவதன் அடிப்படையில் அல்ல.