Docker-ի proxies քարտեզը կապված է daemon-ի, ոչ թե կայքի հետ
Docker-ի client-ի proxy կարգավորման մեջ host-ին հատուկ գրառումը ընտրում է կարգավորումներ Docker daemon-ի միացման համար։ Սա PAC կանոն չէ յուրաքանչյուր նպատակակետի համար։
JSON օբյեկտը խոստումնալից է թվում՝ proxies քարտեզ՝ default գրառմամբ և լրացուցիչ հասցեային բանալիներով։ Գայթակղիչ է այնտեղ registry-ի hostname դնելը և սպասելը, որ այդ registry-ին ուղղված հարցումները կօգտագործեն այլ proxy։
Այդ բանալիները նույնականացնում են Docker daemon-ները, որոնց միանում է client-ը։ Դրանք չեն նույնականացնում այն կայքերը, որոնք container-ը կհարցնի։
Docker-ի client-ի կարգավորումը կարող է նոր container-ներին տալ proxy միջավայրի փոփոխականներ, իսկ նոր build-երին՝ proxy build արգումենտներ։ Daemon-ին հատուկ գրառումը փոխում է տրված այդ կարգավորումը համապատասխան daemon համատեքստի համար։
Այն չի կարգավորում daemon-ի սեփական ելքային proxy միացումը։ Այն նաև container-ի HTTP client-ը չի դարձնում PAC գնահատիչ։
Եթե ձեր խնդիրն է ներքին registry-ն ուղիղ պահել, մինչ daemon-ը այլ ծառայություններին հասնում է proxy-ով, դիտեք daemon-ի աջակցվող proxy և շրջանցման կարգավորումը։ Եթե հավելվածին տարբեր նպատակակետերի համար անհրաժեշտ են տարբեր վերին proxy-ներ, այդ քաղաքականությունը պատկանում է համապատասխան client-ի կամ փոխանցման կարգավորմանը։
Քարտեզը խմբագրելուց առաջ գրի առեք, թե որ հասցեն է ներկայացնում բանալին և որ գործընթացն է կատարում ձախողված հարցումը։ Նույն hostname-ը կարող է հայտնվել daemon միացման, registry URL-ի և proxy URL-ի մեջ, բայց դրանք երեք տարբեր դերեր են։