Docker സേവനത്തിന്റെ DNS ഉം no_proxy ഉപയോഗിച്ചുള്ള പ്രോക്സി ബൈപ്പാസും
പുറം HTTP പ്രോക്സിക്ക് ആ നെറ്റ്വർക്ക് റിസോൾവ് ചെയ്യാനോ എത്തിച്ചേരാനോ കഴിയാത്തപ്പോൾ ഉദ്ദേശിച്ച ആന്തരിക സേവനത്തിന് no_proxy ഉപയോഗിക്കുക.
പുറം HTTP പ്രോക്സിക്ക് Docker-ന്റെ api സേവനനാമം അറിയേണ്ടതില്ല. http://api:8080/ എന്നതിന് പ്രോക്സി അടുത്ത കണക്ഷൻ തുറക്കുന്നു, അതിനാൽ ആപ്പ് കണ്ടെയ്നറിനുള്ളിലെ വിജയകരമായ ലുക്കപ്പ് പ്രോക്സിയുടെ DNS കാഴ്ച തെളിയിക്കുന്നില്ല.
ഉദ്ദേശിച്ച നേരിട്ടുള്ള ആക്സസിനായി, ആ കണ്ടെയ്നറിന്റെ എൻവയോൺമെന്റിൽ ഒഴിവ് ചേർക്കുക:
environment:
http_proxy: http://proxy.example:8080
https_proxy: http://proxy.example:8080
no_proxy: apiapi ലേക്കുള്ള നേരിട്ടുള്ള അഭ്യർത്ഥനകൾ കണ്ടെയ്നറിന്റെ റൂട്ടും അതിലെ ഉൾച്ചേർത്ത റിസോൾവറും ഉപയോഗിക്കുന്നു. രണ്ട് കണ്ടെയ്നറുകൾക്കും ഇപ്പോഴും ഉപയോക്താവ് നിർവചിച്ച പങ്കിട്ട നെറ്റ്വർക്ക് ആവശ്യമാണ്, സേവനം 8080-ൽ കേൾക്കണം. യോഗ്യമായ പുറം അഭ്യർത്ഥനകൾ പ്രോക്സി നിലനിർത്തുന്നു. ആ പൊതു ലക്ഷ്യസ്ഥാനങ്ങൾക്ക് പൊതു ഇടനിലക്കാരനെ ഉപയോഗിക്കാമെങ്കിൽ, HTTP പ്രോക്സി പട്ടിക അക്കൗണ്ടില്ലാത്ത പ്രോക്സി URL-കൾക്ക് സ്ഥാനാർത്ഥികൾ നൽകുന്നു; api നേരിട്ടുള്ള ഒഴിവുകളിൽ നിലനിർത്തുക.
വീണ്ടും സൃഷ്ടിച്ച കണ്ടെയ്നറുകൾ അപ്രതീക്ഷിത വേരിയബിളുകൾ നിലനിർത്തുന്നുവെങ്കിൽ, Docker ക്ലയന്റിന്റെ config.json proxies വിഭാഗം പരിശോധിക്കുക, അത് എൻവയോൺമെന്റ് മൂല്യങ്ങൾ കുത്തിവയ്ക്കാം. ഉദ്ദേശിച്ച എൻട്രി മാറ്റി, സാധാരണ ഒഴുക്കിലൂടെ ബാധിത കണ്ടെയ്നറുകൾ വീണ്ടും സൃഷ്ടിക്കുക, ബന്ധമില്ലാത്ത കോൺഫിഗറേഷൻ സംരക്ഷിച്ചുകൊണ്ട്.