Obiectul JSON pare promițător: o hartă proxies cu o intrare default și chei de adresă suplimentare. Este tentant să pui acolo un nume de gazdă de registry și să te aștepți ca cererile către acel registry să folosească alt proxy.

Acele chei identifică daemonii Docker la care se conectează clientul. Nu identifică site-urile pe care le va solicita un container.

Configurația clientului Docker poate furniza noilor containere variabile de mediu proxy și noilor build-uri argumente de build proxy. O intrare specifică daemonului modifică acea configurație furnizată pentru contextul daemonului corespunzător.

Nu configurează conexiunea de ieșire proprie a daemonului prin proxy. Nici nu transformă clientul HTTP al containerului într-un evaluator PAC.

Dacă sarcina ta este să menții un registry intern direct în timp ce daemonul accesează alte servicii printr-un proxy, examinează configurația de proxy și de ocolire acceptată de daemon. Dacă aplicația are nevoie de proxy-uri amonte diferite pentru destinații diferite, acea politică aparține unei aranjamente adecvate de client sau de redirecționare.

Înainte de a edita harta, notează ce adresă reprezintă cheia și ce proces face cererea care eșuează. Același nume de gazdă poate apărea într-o conexiune la daemon, într-un URL de registry și într-un URL de proxy, dar acestea sunt trei roluri diferite.

Articole similare