Docker കണ്ടെയ്നറുകൾ VPN-ന്റെ DNS റിസോൾവർ അവഗണിക്കുന്നത് എന്തുകൊണ്ട്

VPN ഓണാണ്, ബ്രൗസർ ആന്തരിക സൈറ്റുകളിൽ എത്തുന്നു, എന്നാൽ കണ്ടെയ്നറിന് ഇപ്പോഴും അതേ പേരുകൾ പരിഹരിക്കാനാകുന്നില്ല. EAI_AGAIN പോലുള്ള ഒരു പേര്-പരിഹാര പിശകോടെ പാക്കേജ് ഇൻസ്റ്റാളേഷൻ മരിക്കുന്നു, അല്ലെങ്കിൽ ഹോസ്റ്റ് യന്ത്രം ഒരു പരാതിയുമില്ലാതെ പരിഹരിക്കുന്ന ഒരു ഡാറ്റാബേസ് ഹോസ്റ്റ് ഒരു ആപ്ലിക്കേഷനും കണ്ടെത്താനാകുന്നില്ല. കണ്ടെയ്നർ VPN ഇൻസ്റ്റാൾ ചെയ്ത റിസോൾവർ ഉപയോഗിക്കുന്നില്ല. കണ്ടെയ്നർ നിർമ്മിച്ചപ്പോൾ Docker ഹോസ്റ്റിന്റെ റിസോൾവർ കോൺഫിഗറേഷൻ പകർത്തി, അതിനുശേഷം ഒന്നും അത് വീണ്ടും പകർത്തിയില്ല.

ഒരേ യന്ത്രത്തിൽ റിസോൾവറിന്റെ രണ്ട് കാഴ്ചകൾ

Linux-ൽ, നിർമ്മാണ സമയത്ത് Docker ഓരോ കണ്ടെയ്നറിനും ഹോസ്റ്റിന്റെ റിസോൾവർ കോൺഫിഗറേഷന്റെ ഒരു പകർപ്പ് നൽകുന്നു, loopback വിലാസങ്ങൾ ഫിൽട്ടർ ചെയ്യുന്നു, കൂടാതെ 127.0.0.11-ൽ ഒരു എംബെഡഡ് DNS സെർവർ പ്രവർത്തിപ്പിക്കുന്നു, അത് ക്വറികൾ പുറത്തേക്ക് അയയ്ക്കുന്നു. കണ്ടെയ്നർ ആരംഭിച്ചതിനുശേഷം /etc/resolv.conf മാറ്റിയെഴുതുന്ന VPN ക്ലയന്റ് അതിനുള്ളിൽ ഒന്നും മാറ്റുന്നില്ല. ആ നിമിഷത്തിൽ ഹോസ്റ്റ് റിസോൾവർ യാദൃച്ഛികമായി ശരിയാണെങ്കിൽ മാത്രമേ കണ്ടെയ്നർ വീണ്ടും ആരംഭിക്കുന്നത് സഹായിക്കൂ.

macOS അല്ലെങ്കിൽ Windows-ൽ Docker Desktop ഒരു പാളി കൂട്ടിച്ചേർക്കുന്നു, കാരണം ഡീമൺ ഒരു വെർച്വൽ യന്ത്രത്തിലാണ് ജീവിക്കുന്നത്. ഹോസ്റ്റിന്റെ VPN റിസോൾവർ ആ VM-ന് ഒരിക്കലും ദൃശ്യമാകണമെന്നില്ല, അതിനാൽ വീണ്ടും ആരംഭിക്കുന്നത് ഒന്നും മാറ്റുന്നില്ല. ഒരു പരിഹാരം തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് രണ്ട് കാഴ്ചകളും താരതമ്യം ചെയ്യുക: ഹോസ്റ്റിന്റെ റിസോൾവർ പട്ടികയ്ക്കൊപ്പം docker exec mycontainer cat /etc/resolv.conf.

ഹോസ്റ്റ് ആന്തരിക റിസോൾവർ പട്ടികപ്പെടുത്തുമ്പോൾ കണ്ടെയ്നർ പൊതു റിസോൾവർ പട്ടികപ്പെടുത്തുന്നുവെങ്കിൽ അത് പൊതു പേരുകൾ പരിഹരിക്കുകയും ആന്തരിക പേരുകളിൽ പരാജയപ്പെടുകയും ചെയ്യും. ആ വിഭജനമാണ് ഈ പ്രശ്നത്തിന്റെ ഒപ്പ്.

ഓപ്ഷൻ A: ഓരോ കണ്ടെയ്നറിനും ടണൽ റിസോൾവർ നൽകുക

Docker ഓരോ കണ്ടെയ്നറിനും DNS ക്രമീകരണങ്ങൾ സ്വീകരിക്കുന്നു, അതാണ് പ്രവർത്തിക്കുന്ന ഏറ്റവും ചെറിയ മാറ്റം. ആദ്യം VPN-ന്റെ റിസോൾവർ വിലാസങ്ങൾ വായിക്കുക: macOS-ൽ scutil --dns, Linux-ൽ resolvectl status അല്ലെങ്കിൽ ക്ലയന്റിന്റെ സ്വന്തം സ്റ്റാറ്റസ് ഔട്ട്പുട്ട്. തുടർന്ന് അവയോടൊപ്പം കണ്ടെയ്നർ ആരംഭിക്കുക, ഉദാഹരണത്തിന് docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose-ൽ അതേ ക്രമീകരണം സേവനത്തിന് കീഴിലുള്ള ഒരു പട്ടികയാണ്, അവിടെ അത് ആരുടെയെങ്കിലും ഷെൽ ചരിത്രത്തിനുപകരം പതിപ്പ് നിയന്ത്രണത്തിൽ ജീവിക്കുന്നു.

/etc/docker/daemon.json-ലെ dns അറേ ഓരോ പുതിയ കണ്ടെയ്നറിനും ബാധകമാണ്, അത് കൂടുതൽ വൃത്തിയായി തോന്നുന്നു, എന്നാൽ അല്ല. ടണൽ ഓഫ് ആയിരിക്കുമ്പോഴും ഇത് ബാധകമാണ്, അപ്പോൾ VPN വഴി മാത്രം എത്താവുന്ന റിസോൾവർ സാധാരണ ഇമേജ് പുൾ ചെയ്യുന്നത് തകർക്കുന്നു. ഓരോ കണ്ടെയ്നറിനുമുള്ള ക്രമീകരണങ്ങൾ ന്യായീകരിക്കാനും പിൻവലിക്കാനും എളുപ്പമാണ്.

ഓപ്ഷൻ B: കണ്ടെയ്നർ ഹോസ്റ്റ് നെറ്റ്വർക്ക് പങ്കിടട്ടെ

ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗ് പകർപ്പിനെ പൂർണ്ണമായി ഒഴിവാക്കുന്നു, കാരണം കണ്ടെയ്നർ ഹോസ്റ്റിന്റെ റിസോൾവറും ഹോസ്റ്റിന്റെ ടണലും ഉപയോഗിക്കുന്നു. നിങ്ങൾ ഉദ്ദേശിച്ച നെറ്റ്വർക്ക് ഐസൊലേഷനും ഇത് നീക്കം ചെയ്യുന്നു, കൂടാതെ Docker Desktop-ന് കീഴിൽ ഇത് അതേ രീതിയിൽ പ്രവർത്തിക്കുന്നില്ല. Linux-ൽ ആന്തരിക പേരുകൾ പരിഹരിക്കേണ്ട ഒരു തവണത്തെ ഉപകരണത്തിന് ഇത് പ്രായോഗികമായ തിരഞ്ഞെടുപ്പാണ്.

ബിൽഡുകൾക്ക് രണ്ട് ഓപ്ഷനുകളിൽ ഒന്നും ബാധകമല്ല, കാരണം ബിൽഡ് ഘട്ടങ്ങൾ റൺടൈം ഫ്ലാഗുകൾ പാരമ്പര്യമായി സ്വീകരിക്കുന്നില്ല. പ്ലാറ്റ്ഫോം അനുവദിക്കുന്നിടത്ത് ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗ് ഉപയോഗിച്ച് ബിൽഡ് ചെയ്യുക, അല്ലെങ്കിൽ ആശ്രിതത്വ ഇൻസ്റ്റാളേഷൻ ടണൽ ആവശ്യമില്ലാത്ത ഒരു ഘട്ടത്തിൽ നിലനിർത്തുക.

രണ്ട് ഓപ്ഷനുകളും പരിഹരിക്കാത്തത്

കണ്ടെയ്നറിന് അവിടേക്ക് ഒരു റൂട്ട് ഇല്ലെങ്കിൽ DNS വിലാസം നിഷ്പ്രയോജനമാണ്. VPN റിസോൾവർ സാധാരണയായി ടണലിന്റെ വിലാസ സ്ഥലത്തിനുള്ളിൽ ഇരിക്കുന്നു, അതിനാൽ കണ്ടെയ്നറിന് ആ പ്രിഫിക്സിലേക്ക് ഒരു വഴി വേണം. Docker-ന്റെ സ്ഥിരസ്ഥിതി ബ്രിഡ്ജ് സാധാരണയായി ഹോസ്റ്റ് വഴി പുറത്തേക്ക് റൂട്ട് ചെയ്യുന്നു, ഹോസ്റ്റിന് ടണൽ റൂട്ട് ഉണ്ടെങ്കിൽ, ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാണെങ്കിൽ അത് മതിയാകും. സ്വന്തം വിലാസ പൂളുകളുള്ള ഇച്ഛാനുസൃത ബ്രിഡ്ജ് നെറ്റ്വർക്കുകൾ VPN സബ്നെറ്റുമായി കൂട്ടിയിടിച്ചേക്കാം, അപ്പോൾ ക്വറികൾ തികച്ചും വേറെയെങ്ങോട്ട് പോകുന്നു.

റിസോൾവർ തന്നെ ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് Docker നെറ്റ്വർക്കിന്റെ സബ്നെറ്റ് VPN സബ്നെറ്റുമായി പരിശോധിക്കുക. ഓവർലാപ്പ് കേടായ DNS സെർവറിനെ യഥാവത് സദൃശ്യമായ ഒരു പരാജയം ഉണ്ടാക്കുന്നു.

കണ്ടെയ്നറിനുള്ളിൽ പരിശോധിക്കുക

ബ്രൗസറിനോ ഭാഷാ റൺടൈമിനോ പകരം കണ്ടെയ്നറിനുള്ളിൽ getent hosts db.internal ഉപയോഗിച്ച് പരീക്ഷിക്കുക, കാരണം അവ അവരുടേതായ DNS നയവും അവരുടേതായ കാഷിംഗും പ്രയോഗിക്കുന്നു. getent പേര് പരിഹരിക്കുകയും ആപ്ലിക്കേഷൻ ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്യുന്നുവെങ്കിൽ, റിസോൾവർ ഇപ്പോൾ ശരിയാണ്, ബാക്കിയുള്ള പ്രശ്നം ആപ്ലിക്കേഷൻ തലത്തിലാണ്. അത് പരിഹരിക്കുന്നില്ലെങ്കിൽ, DNS ഘട്ടം പൂർത്തിയായിട്ടില്ല.

DNS ക്രമീകരണങ്ങൾ മാറ്റിയതിനുശേഷം കണ്ടെയ്നർ വീണ്ടും നിർമ്മിക്കുക. പ്രവർത്തിക്കുന്ന ഒരു കണ്ടെയ്നറിനുള്ളിൽ /etc/resolv.conf എഡിറ്റ് ചെയ്യുന്നത് അതോടൊപ്പം അപ്രത്യക്ഷമാകുകയും കോൺഫിഗറേഷൻ പ്രശ്നം ആരെങ്കിലും അത് വീണ്ടും ആരംഭിക്കാൻ എടുക്കുന്ന സമയം മുഴുവൻ മറയ്ക്കുകയും ചെയ്യുന്നു.