კონტეინერიზებული Distribution რეესტრისთვის, რომელიც იყენებს გარემოს გაცნობიერებულ HTTP ტრანსპორტს, გადასცეთ S3 მარშრუტი რეესტრის კონტეინერს:

services:
  registry:
    environment:
      HTTP_PROXY: http://proxy.example.internal:8080
      HTTPS_PROXY: http://proxy.example.internal:8080
      NO_PROXY: localhost,127.0.0.1

გააერთიანეთ ეს არსებულ image-თან, საცავთან, ავთენტიფიკაციასთან და volumes-ებთან. ეს ფრაგმენტი სრული რეესტრი არ არის. პროქსის სახელი უნდა იყოს ხელმისაწვდომი ამ კონტეინერიდან, ხოლო სქემა უნდა შეესაბამებოდეს პროქსის მსმენელს.

დაადასტურეთ განლაგებული S3 დრაივერი და ტრანსპორტი. Distribution 2.8.3-ის მოხსენიებული წყარო იყენებს AWS SDK სესიას; მორგებულ დრაივერს ან ტრანსპორტს შეიძლება სჭირდებოდეს სხვა მხარდაჭერილი კონფიგურაცია.

კავშირივინ აწესრიგებს ან იკვლევს
კლიენტი → რეესტრირეესტრის შემავალი HTTP მსმენელი და კლიენტის მარშრუტი
Daemon → image-ის წყაროDocker daemon-ის პროქსის პარამეტრები
რეესტრი → S3რეესტრის პროცესის საცავის HTTP ტრანსპორტი

კლიენტის წარმატებული შესვლა მხოლოდ პირველ მარშრუტს ადასტურებს. საცავის დრაივერი S3-ს საკუთარ მოთხოვნებს უგზავნის; daemon, რომელმაც ადრე რეესტრის image ჩამოტვირთა, ამ გამოძახებებს არ აკეთებს.

შეამოწმეთ გადამისამართებიც blob-ების ჩამოტვირთვის დროს. Distribution-ს შეუძლია მომხმარებლის ობიექტურ საცავში გადამისამართება, რაც ამ კლიენტს პირდაპირი S3 ხელმისაწვდომობის მოთხოვნას უქმნის. რეესტრის პროქსის კონფიგურაცია მომხმარებელს არ აკონფიგურირებს. გადამისამართების ქცევის შეცვლა ცვლის blob ტრაფიკის მიმართულებას, ამიტომ დაასახელეთ წარუმატებელი გამომგზავნი და ოპერაცია სანამ ამ პარამეტრს შეცვლიდეთ.

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