നിങ്ങളുടെ കോർപ്പറേറ്റ് പ്രോക്സി ഒരു Compose സേവനനാമം പരിഹരിക്കാൻ ശ്രമിക്കുന്നത് എന്തുകൊണ്ട്

ആപ്ലിക്കേഷൻ അതിന്റെ കോർപ്പറേറ്റ് പ്രോക്സിയിലൂടെ ഇന്റർനെറ്റിൽ എത്തുന്നു, പക്ഷേ http://catalog:8080/ പരാജയപ്പെടുന്നു, പ്രോക്സിക്ക് “catalog” പരിഹരിക്കാനാകുന്നില്ല. ആ അഭ്യർത്ഥന ഒരുപക്ഷേ Docker-ന്റെ ആന്തരിക DNS ഒരിക്കലും ഉപയോഗിച്ചിട്ടുണ്ടാകില്ല.

ഒരു HTTP ക്ലയന്റിന് നേരിട്ടുള്ള കണക്ഷൻ ഉണ്ടാക്കുന്നതിന് മുമ്പ് അതിന്റെ പ്രോക്സി തിരഞ്ഞെടുക്കാം. അപ്പോൾ ബാഹ്യ പ്രോക്സിക്ക് Compose നെറ്റ്വർക്കിനുള്ളിൽ മാത്രം അർത്ഥമുള്ള ഒരു പേര് ലഭിക്കുന്നു.

1. അഭ്യർത്ഥനയിൽ ഹോസ്റ്റ്നെയിം ഉപയോഗിക്കുക. Compose സേവനങ്ങൾ ഉചിതമായ നെറ്റ്വർക്കിൽ സേവനനാമം ഉപയോഗിച്ച് കണ്ടെത്താനാകും. മാറാവുന്ന കണ്ടെയ്നർ IP ഹാർഡ്കോഡ് ചെയ്യുന്നതിന് പകരം ഉപഭോക്തൃ ക്ലയന്റിന്റെ പിന്തുണയുള്ള ബൈപ്പാസ് കോൺഫിഗറേഷനിൽ catalog ചേർക്കുക.
2. നിലവിലുള്ള ഒഴിവുകൾ സംരക്ഷിക്കുക. പരിസ്ഥിതി ബോധമുള്ള ക്ലയന്റിനായി, പ്രസക്തമായ എൻട്രികൾ സംഘടനയുടെ പട്ടികയുമായി ലയിപ്പിക്കുക:

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

ഇമേജിലെ യഥാർത്ഥ ലൈബ്രറിയോ എക്സിക്യൂട്ടബിളോ കേസ് കൈകാര്യം, പതിപ്പ്, പൊരുത്ത വ്യാകരണം എന്നിവയ്ക്കായി പരിശോധിക്കുക. സാർവത്രികമായ NO_PROXY പാഴ്സർ ഇല്ല. ചെറിയ ഇമേജിലെ wget എന്ന പ്രോഗ്രാം GNU Wget പോലെ പെരുമാറണമെന്നില്ല.

അഭ്യർത്ഥന നേരിട്ടുള്ള റൂട്ടിംഗ് തിരഞ്ഞെടുത്താൽ, വിളിക്കുന്നയാളുടെയും സേവനത്തിന്റെയും പങ്കിട്ട നെറ്റ്വർക്ക്, കേൾക്കുന്ന സേവനം, കണ്ടെയ്നർ പോർട്ട് എന്നിവ പരിശോധിക്കുക. പ്രസിദ്ധീകരിച്ച ഹോസ്റ്റ് പോർട്ട് മറ്റൊരു എൻഡ്പോയിന്റാണ്. ബൈപ്പാസിന് കാണാതായ നെറ്റ്വർക്ക് അറ്റാച്ച്മെന്റ് ചേർക്കാനാവില്ല, നെറ്റ്വർക്ക് വീണ്ടും സൃഷ്ടിച്ചാൽ ബാഹ്യ പ്രോക്സിയെ സ്വകാര്യ Compose നാമം പഠിപ്പിക്കാനാവാത്തതുപോലെ.

ഉദ്ദേശിച്ച വിഭജനം നിലനിർത്തുക: ആന്തരിക അഭ്യർത്ഥനകൾ അവയുടെ ആന്തരിക പാത ഉപയോഗിക്കുന്നു; ബാഹ്യ അഭ്യർത്ഥനകൾ അംഗീകൃത പ്രോക്സി നിലനിർത്തുന്നു. പ്രോക്സി ആഗോളമായി അപ്രാപ്തമാക്കുന്നത് ഈ ഒരു പരാജയം മറയ്ക്കുകയും അടുത്ത ബാഹ്യ അഭ്യർത്ഥനത്തിന് ആവശ്യമായ പാത നീക്കം ചെയ്യുകയും ചെയ്യാം.