ഒരു പ്രോക്സി കണ്ടെയ്നർ DNS കണ്ടെയ്നർ സ്വയമേവ ഉപയോഗിക്കാത്തത് എന്തുകൊണ്ട്

ഒരേ Docker ഹോസ്റ്റിൽ ഒരു പ്രോക്സിയും DNS സെർവറും പ്രവർത്തിപ്പിക്കുന്നത് അവയുടെ DNS പാതകളെ ബന്ധിപ്പിക്കുന്നില്ല. മൂന്ന് വേറിട്ട ബന്ധങ്ങൾ പ്രധാനമാണ്:

• നെറ്റ്‌വർക്ക് എത്തിച്ചേരൽ. വേറിട്ട Compose പ്രോജക്ടുകൾക്ക് സാധാരണയായി വേറിട്ട ഡിഫോൾട്ട് നെറ്റ്‌വർക്കുകളുണ്ട്. സേവനങ്ങളെ അനുയോജ്യമായ പങ്കിട്ട നെറ്റ്‌വർക്കിലേക്ക് ഇടുക, ഒരു പ്രോജക്ടിനുള്ളിലോ പ്രോജക്ടുകൾക്കിടയിൽ വ്യക്തമായി പങ്കിടുന്ന നെറ്റ്‌വർക്കിലൂടെയോ.
• സേവന കണ്ടെത്തൽ. ഇഷ്ടാനുസൃത Docker നെറ്റ്‌വർക്കിന്റെ ഉൾച്ചേർത്ത DNS കണ്ടെയ്നർ പേരുകൾ പരിഹരിക്കാൻ കഴിയും. അത് ഒരു ആപ്ലിക്കേഷന് അയൽക്കാരനെ കണ്ടെത്താൻ അനുവദിക്കുന്നു; എന്നാൽ ആ അയൽക്കാരനെ സ്വയമേവ അതിന്റെ DNS റിസോൾവർ ആയി തിരഞ്ഞെടുക്കുന്നില്ല.
• റിസോൾവർ തിരഞ്ഞെടുപ്പ്. പ്രോക്സി കണ്ടെയ്നറിനുള്ളിൽ ഉപയോഗിക്കുന്ന റിസോൾവർ തിരിച്ചറിയുക. Compose-ന്റെ dns ഫീൽഡ് DNS സെർവർ വിലാസങ്ങൾ സ്വീകരിക്കുന്നു. ഒരു ആപ്ലിക്കേഷനിൽ പരിഹരിക്കുന്ന dns.local പോലുള്ള ഒരു പേര് അതിനെ ആ ഫീൽഡിന് സാധുവായ മൂല്യമാക്കുന്നില്ല.

പ്രോക്സി കണ്ടെയ്നറിൽ നിന്ന് അതിന്റെ ക്രമീകരിച്ച റിസോൾവർ വിലാസം വരെ ക്വറി പിന്തുടരുക. ആ വിലാസത്തിൽ ഒരു റൂട്ടും DNS ലിസണറും ഉണ്ടെന്ന് സ്ഥിരീകരിക്കുക. ഹോസ്റ്റ് പോർട്ട് 53 പ്രസിദ്ധീകരിക്കുന്നത് ഹോസ്റ്റ് വശത്ത് ഒരു ആക്സസ് പാത സൃഷ്ടിക്കുന്നു; എന്നാൽ അത് ഉപയോഗിക്കാൻ കണ്ടെയ്നറുകളോട് പറയുന്നില്ല. നെറ്റ്‌വർക്ക് പങ്കിടുന്ന കണ്ടെയ്നറുകൾക്ക് പകരം നേരിട്ട് ആശയവിനിമയം നടത്താം.

ക്രമീകരണം DNS കണ്ടെയ്നറിന്റെ വിലാസം പരാമർശിക്കുന്നുവെങ്കിൽ, അനുയോജ്യമായ IPAM ക്രമീകരണത്തിന് കീഴിൽ അത് സ്ഥിരമായി നിലനിർത്തുക. ഇന്നലത്തെ കണ്ടെയ്നറിൽ നിന്ന് പകർത്തിയ ചലനാത്മകമായി അനുവദിച്ച വിലാസം പുനഃസൃഷ്ടിക്കുമ്പോൾ പരാജയപ്പെടാം. റിസോൾവറിന്റെ അപ്‌സ്ട്രീം പാതയും പരിശോധിക്കുക: മറുപടിയില്ലാത്ത ക്വറികൾ അതിലേക്കു തന്നെ തിരികെ അയയ്ക്കുന്നത് എത്തിച്ചേരാനാകാത്ത റിസോൾവറിൽ നിന്ന് വ്യത്യസ്തമായ പരാജയം സൃഷ്ടിക്കുന്നു.

അവസാനം, ലക്ഷ്യസ്ഥാനം ആരാണ് പരിഹരിക്കുന്നതെന്ന് തിരിച്ചറിയുക. CONNECT നാമം പരിഹരിക്കുന്ന ഒരു HTTP പ്രോക്സിക്ക് ഈ കണ്ടെയ്നർ പാത ഉപയോഗിക്കാം; പ്രാദേശികമായി പരിഹരിക്കുന്ന ഒരു SOCKS ക്ലയന്റ് ഉപയോഗിച്ചെന്ന് വരില്ല. ഹോസ്റ്റിലെ ഒരു അന്വേഷണം ഹോസ്റ്റിന്റെ റൂട്ട് തെളിയിക്കുന്നു, പ്രോക്സി പ്രോസസ്സിന്റേതല്ല.