Docker-ന്റെ proxies മാപ്പ് വെബ്‌സൈറ്റിനല്ല, daemon-നെ ആശ്രയിച്ചിരിക്കുന്നു
Docker ക്ലയന്റ് പ്രോക്സി കോൺഫിഗറേഷനിലെ ഹോസ്റ്റ്-നിർദ്ദിഷ്ട എൻട്രി Docker daemon കണക്ഷനുവേണ്ടി ക്രമീകരണങ്ങൾ തിരഞ്ഞെടുക്കുന്നു. ഇത് ഓരോ ലക്ഷ്യത്തിനുമുള്ള PAC നിയമമല്ല.
JSON ഒബ്ജക്റ്റ് പ്രതീക്ഷാജനകമായി തോന്നുന്നു: proxies മാപ്പിൽ default എൻട്രിയും അധിക വിലാസ കീകളുമുണ്ട്. അവിടെ ഒരു registry ഹോസ്റ്റ്നെയിം വെച്ച് ആ registry-യിലേക്കുള്ള അഭ്യർത്ഥനകൾ മറ്റൊരു പ്രോക്സി ഉപയോഗിക്കുമെന്ന് പ്രതീക്ഷിക്കാൻ പ്രലോഭനമുണ്ട്.
ആ കീകൾ ക്ലയന്റ് ബന്ധിക്കുന്ന Docker daemons-നെ തിരിച്ചറിയിക്കുന്നു. ഒരു കണ്ടെയ്നർ അഭ്യർത്ഥിക്കുന്ന വെബ്സൈറ്റുകളെ അവ തിരിച്ചറിയിക്കുന്നില്ല.
Docker ക്ലയന്റ് കോൺഫിഗറേഷന് പുതിയ കണ്ടെയ്നറുകൾക്ക് പ്രോക്സി എൻവയോൺമെന്റ് വേരിയബിളുകളും പുതിയ builds-ന് പ്രോക്സി build ആർഗ്യുമെന്റുകളും നൽകാം. daemon-നിർദ്ദിഷ്ട എൻട്രി യോജിക്കുന്ന daemon സന്ദർഭത്തിനുവേണ്ടി ആ നൽകിയ കോൺഫിഗറേഷൻ മാറ്റുന്നു.
അത് daemon-ന്റെ സ്വന്തം പുറംതിരിഞ്ഞ പ്രോക്സി കണക്ഷൻ കോൺഫിഗർ ചെയ്യുന്നില്ല. കണ്ടെയ്നറിന്റെ HTTP ക്ലയന്റിനെ PAC മൂല്യനിർണ്ണയ ഉപകരണമാക്കുകയുമില്ല.
ആന്തരിക registry നേരിട്ട് നിലനിർത്തുകയും daemon പ്രോക്സി വഴി മറ്റ് സേവനങ്ങളിൽ എത്തുകയുമാണ് നിങ്ങളുടെ ജോലിയെങ്കിൽ, daemon പിന്തുണയ്ക്കുന്ന പ്രോക്സി, ഒഴിവാക്കൽ കോൺഫിഗറേഷൻ പരിശോധിക്കുക. വ്യത്യസ്ത ലക്ഷ്യങ്ങൾക്ക് ആപ്ലിക്കേഷന് വ്യത്യസ്ത അപ്സ്ട്രീം പ്രോക്സികൾ വേണമെങ്കിൽ, ആ നയം ഉചിതമായ ക്ലയന്റ് അല്ലെങ്കിൽ ഫോർവേഡിംഗ് ക്രമീകരണത്തിൽ വരണം.
മാപ്പ് തിരുത്തുന്നതിന് മുമ്പ് കീ ഏത് വിലാസത്തെ പ്രതിനിധീകരിക്കുന്നു, ഏത് പ്രോസസ് പരാജയപ്പെടുന്ന അഭ്യർത്ഥന നടത്തുന്നു എന്നിവ എഴുതിവെക്കുക. ഒരേ ഹോസ്റ്റ്നെയിം daemon കണക്ഷനിലും registry URL-ലും പ്രോക്സി URL-ലും പ്രത്യക്ഷപ്പെടാം, പക്ഷേ അവ മൂന്ന് വ്യത്യസ്ത വേഷങ്ങളാണ്.