docker pull കണ്ടെയ്നറിന്റെ പ്രോക്സി ക്രമീകരണം അവഗണിക്കുന്നതെന്തുകൊണ്ട്?

docker pull പരാജയപ്പെട്ടാൽ Docker ഡീമണോ Docker Desktop-ഓ ക്രമീകരിക്കുക. ആപ്ലിക്കേഷൻ കണ്ടെയ്നർ സ്വന്തം പ്രോക്സി വേരിയബിളുകൾ വായിക്കുന്നതിനുമുമ്പ് ഇമേജ് ഡൗൺലോഡ് ചെയ്യപ്പെടുന്നു.

നേറ്റീവ് Docker Engine

ഈ ഭാഗം നിലവിലെ ഡീമൺ പ്രോക്സി ക്രമീകരണത്തിൽ ചേർത്ത് ഡോക്യുമെന്റേഷൻ എൻഡ്‌പോയിന്റ് മാറ്റുകയും ബന്ധമില്ലാത്ത ക്രമീകരണങ്ങൾ നിലനിർത്തുകയും ചെയ്യുക. പൊതു പ്രോക്സികൾ അനുവദിച്ച പൊതു ഇമേജ് പരീക്ഷണങ്ങൾക്ക് HTTP പ്രോക്സി പട്ടിക സ്ഥാനാർഥികളെ നൽകുന്നു:

{
  "proxies": {
    "http-proxy": "http://203.0.113.10:8080",
    "https-proxy": "http://203.0.113.10:8080",
    "no-proxy": "localhost,127.0.0.1,registry.example.internal"
  }
}

ഡീമണിന്റെ ഹൈഫനുള്ള കീകൾ Docker ക്ലയന്റിന്റെ ~/.docker/config.json-ലെ camelCase കീകളിൽനിന്ന് വ്യത്യസ്തമാണ്. ക്ലയന്റിന്റെ പ്രോക്സി ഭാഗം പുതിയ കണ്ടെയ്നറുകൾക്കും ബിൽഡുകൾക്കും എൻവയൺമെന്റ് വേരിയബിളുകൾ നൽകുന്നു; ഡീമണിന്റെ ഡൗൺലോഡോ നിലവിലുള്ള കണ്ടെയ്നറിന്റെ എൻവയൺമെന്റോ ക്രമീകരിക്കുന്നില്ല.

ഇൻസ്റ്റലേഷനുള്ള ഡോക്യുമെന്റേഷൻ പ്രകാരം ഡീമൺ പുനരാരംഭിച്ച് നിലവിലെ ജോലികളിലുള്ള പ്രഭാവം ആസൂത്രണം ചെയ്യുക. ഡീമണിന് തുടക്കത്തിലെ എൻവയൺമെന്റിലും പ്രോക്സി വേരിയബിളുകൾ ലഭിക്കാം; പിന്നീടുള്ള ടെർമിനലിൽ export ചെയ്താൽ പ്രവർത്തിക്കുന്ന സേവനം പുതുക്കില്ല.

Docker Desktop

Desktop-ന്റെ പ്രോക്സി ക്രമീകരണം ഉപയോഗിക്കുക. Docker രേഖകൾപ്രകാരം Desktop daemon.json-ലെ പ്രോക്സി എൻട്രികൾ അവഗണിക്കുന്നു; അതിനാൽ നേറ്റീവ് Engine ഉദാഹരണം വീണ്ടും വീണ്ടും മാറ്റിയാൽ ഈ ഉൽപ്പന്നത്തിന്റെ പാത ക്രമീകരിക്കില്ല.

യഥാർഥ ഘടകം പുതുക്കിയ ശേഷം ഇമേജ് വീണ്ടും എടുക്കുക. രജിസ്ട്രി പ്രവേശനം, പ്രാമാണീകരണം, തിരിച്ചുവിടൽ, ലെയർ ഡൗൺലോഡ് എന്നിവയിൽ ഏതു പരാജയപ്പെട്ടെന്നു വായിക്കുക. നിലവിലെ കണ്ടെയ്നറിനുള്ളിലെ വിജയകരമായ HTTP അഭ്യർഥന ആ ആപ്പിന്റെ പാത മാത്രമാണ് പരിശോധിക്കുന്നത്. പങ്കിടുന്ന സ്ക്രീൻഷോട്ടിലോ കമ്മിറ്റ് ചെയ്ത ഫയലിലോ പ്രോക്സി പ്രവേശനവിവരം ഇടരുത്; ഡീമൺ ക്രമീകരണവും കണ്ടെയ്നർ എൻവയൺമെന്റും രഹസ്യസംഭരണികളല്ല.