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 നെറ്റ്‌വർക്ക് ഡോക്യുമെന്റേഷൻ യാന്ത്രിക സബ്‌നെറ്റ് വിഹിതവും പൂൾ ഫീൽഡുകളും വിവരിക്കുന്നു. ശ്രേണി വൃത്തിയായി കാണപ്പെടുന്നതിൽ നിന്നല്ല, നിങ്ങൾ എത്തിച്ചേരേണ്ടതിൽ നിന്ന് തിരഞ്ഞെടുക്കുക.