JSON ობიექტი პერსპექტიულად გამოიყურება: proxies რუკა default ჩანაწერით და დამატებითი მისამართის გასაღებებით. მაცდურია იქ registry-ის ჰოსტის სახელის ჩასმა და იმის მოლოდინი, რომ ამ registry-ზე გაგზავნილი მოთხოვნები სხვა proxy-ს გამოიყენებს.

ეს გასაღებები განსაზღვრავს იმ Docker daemon-ებს, რომლებსაც კლიენტი უკავშირდება. ისინი არ განსაზღვრავენ ვებგვერდებს, რომლებსაც კონტეინერი მოითხოვს.

Docker კლიენტის კონფიგურაციას შეუძლია ახალ კონტეინერებს proxy-ის გარემოს ცვლადები მისცეს, ხოლო ახალ build-ებს — proxy-ის build არგუმენტები. daemon-ზე სპეციფიკური ჩანაწერი ცვლის მიცემულ კონფიგურაციას შესაბამისი daemon-ის კონტექსტისთვის.

ის არ აკონფიგურირებს თავად daemon-ის გამავალი proxy კავშირს. არც კონტეინერის HTTP კლიენტს აქცევს PAC შემფასებლად.

თუ თქვენი ამოცანაა შიდა registry პირდაპირ დარჩეს, სანამ daemon სხვა სერვისებს proxy-ის გავლით წვდება, ნახეთ daemon-ის მიერ მხარდაჭერილი proxy და გვერდის ავლის კონფიგურაცია. თუ აპლიკაციას სხვადასხვა დანიშნულებისთვის სხვადასხვა ზედა proxy სჭირდება, ეს პოლიტიკა შესაბამის კლიენტურ ან გადამისამართების მოწყობაში უნდა იყოს.

რუკის რედაქტირებამდე ჩაწერეთ, რომელ მისამართს წარმოადგენს გასაღები და რომელი პროცესი აკეთებს წარუმატებელ მოთხოვნას. ერთი და იგივე ჰოსტის სახელი შეიძლება გამოჩნდეს daemon-ის კავშირში, registry URL-ში და proxy URL-ში, მაგრამ ეს სამი განსხვავებული როლია.

დაკავშირებული სტატიები