docker pull VPN-ით: daemon-ს აქვს საკუთარი ქსელი

თქვენი ლეპტოპი კორპორატიულ VPN-შია, curl შიდა რეესტრს აღწევს, და მაინც docker pull იშლება EOF-ით. ეს კომბინაცია წინააღმდეგობა არ არის. თქვენ მიერ აკრეფილი ბრძანება თქვენს shell-ში მუშაობს, მაგრამ გადაცემა მუშაობს იმ daemon-ში, რომელიც Docker CLI-მ აირჩია, და ეს daemon შეიძლება სრულიად სხვა ჰოსტზე იყოს. სწორედ მისი ქსელური გზა უნდა მუშაობდეს, და სწორედ მისი proxy-ის პარამეტრები მოქმედებს.

დაიწყეთ ძრავის, და არა მარშრუტის იდენტიფიცირებით

გაუშვით docker context show და docker version. ვერსიის გამოტანა ბეჭდავს კლიენტის განყოფილებას და სერვერის განყოფილებას, და სერვერის ბლოკი გეუბნებათ, ვინ უპასუხა: ლოკალური ნატიური ძრავა, Docker Desktop-ის ვირტუალური მანქანა, თუ daemon დისტანციურ მანქანაზე. docker context inspect აჩვენებს არჩეული კონტექსტის საბოლოო წერტილს, თუ დარწმუნებული უნდა იყოთ, და არც ერთი ეს ბრძანება არაფერს ცვლის.

გარემოს ცვლადმა, როგორიც DOCKER_HOST-ია, შეიძლება ჩუმად მიმართოს CLI სხვა ძრავისკენ, ვიდრე თქვენ ვარაუდობთ, და ეს არის ჩვეულებრივი განმარტება იმისა, რომ ლეპტოპი VPN-ში ჩანს, სანამ pull სხვაგან მიდის.

daemon-ს აქვს საკუთარი ქსელური იდენტობა

დისტანციურ ძრავას სჭირდება საკუთარი დამტკიცებული გზა კერძო რეესტრისკენ. თქვენი ლეპტოპის VPN კლიენტის დაკავშირება ამ ლეპტოპს აძლევს მარშრუტს; ის არ აძლევს ლაბორატორიაში ან ღრუბლოვან ქვექსელში მჯდომ daemon-ს იმავე კერძო მისამართს. თუ ძრავა Docker Desktop-ია, pull ხდება მის ვირტუალურ მანქანაში, რომელსაც აქვს საკუთარი ქსელური და proxy კონფიგურაცია, თქვენი shell-ის გარემოსგან დამოუკიდებელი.

ამიტომ ჰოსტზე წარმატებული curl მტკიცებაა ჰოსტის შესახებ და მეტი არაფერი.

გაარკვიეთ, რომელი გაცვლა დასრულდა რეესტრთან

სურათის pull არის თანმიმდევრობა: ავთენტიფიკაცია, manifest-ის მოძიება, შემდეგ blob გადაცემები, რომლებიც ხშირად გადამისამართდება ობიექტურ საცავში ან CDN-ის საბოლოო წერტილში. წარმატებული docker login ამტკიცებს მხოლოდ პირველ ნაბიჯს, და ტოკენი შეიძლება სრულად ვალიდური იყოს, სანამ გადამისამართებული blob ჰოსტი მიუწვდომელია daemon-ის ქსელიდან. არაფრის შეცვლამდე ჩაწერეთ ზუსტი დრო, სურათის მითითება და პირველი სასარგებლო მოვლენა daemon-ის ან კლიენტის ჟურნალიდან.

EOF თავისთავად არ ასახელებს მიზეზს. ეს შეიძლება იყოს მოწყვეტილი კავშირი, ნაკადის ჩამომვარდნილი proxy, დროის ამოწურვა ან MTU პრობლემა, და მათ შორის გამოცნობა დროის ნიშნის მქონე მოვლენის გარეშე სწორედ ის გზაა, რომლითაც ადამიანები ჯანსაღ ძრავას ხელახლა აშენებენ. მოეპყარით კლიენტის გამოტანაში ბაიტურ წანაცვლებას როგორც მონაცემს, რადგან ყოველ ჯერზე იმავე ზომაზე შემდგარი გადაცემა სულ სხვა ცხოველია, ვიდრე ის, რომელიც არასდროს იწყება. ჩაწერეთ ორივე შედეგი და შეადარეთ ისინი ცდებს შორის.

დააკონფიგურირეთ კომპონენტი, რომელიც გადასცემს

ნატიური Linux ძრავისთვის proxy ეკუთვნის სერვისის გარემოს, და არა თქვენს shell-ს. drop-in ფაილი /etc/systemd/system/docker.service.d/-ის ქვეშ HTTP_PROXY, HTTPS_PROXY და NO_PROXY ჩანაწერებით, რასაც მოჰყვება systemctl daemon-reload და გადატვირთვა, დოკუმენტირებული განლაგებაა. Docker Desktop იგივე მნიშვნელობებს თავისი პარამეტრებით ავლენს, და shell-ის პროფილის რედაქტირება არც ერთს არ ეხება.

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

როცა კორპორატიული TLS შემოწმება დამტკიცებულ გზაზეა, დააყენეთ მისი დადასტურებული ფესვი ძრავის ან Desktop-ის სამუშაო ნაკადით. რეესტრის insecure-registries-ში დამატება სხვა ცვლილებაა, რომელიც გამორთავს ვალიდაციას, და ეს სანდოობის საცავის კონფიგურაცია არ არის.

გაიმეორეთ ერთი კონტროლირებადი pull და შეამოწმეთ, რა შეიცვალა

შეცვალეთ ერთი საზღვარი, გადატვირთეთ კომპონენტი, რომელსაც ის ეკუთვნის, და გაიმეორეთ იგივე pull იმავე კონტექსტიდან. შეამოწმეთ მიღებული სურათის მითითება და digest და არა შეცდომის არარსებობა, რადგან ქეშირებულმა შრემ შეიძლება მეორე ცდას აიძულოს გაიაროს გზის გაცილებით ნაკლები ნაწილი, ვიდრე პირველმა. შეინახეთ ბილეთში ის გადაცემები, რომლებიც ნამდვილად მოხდა, რადგან ისინი ერთადერთი ჩანაწერია იმისა, თუ რა გამოსცადა გამეორებამ სინამდვილეში.

build-ის ნაბიჯებს და გაშვებულ კონტეინერებს აქვთ საკუთარი ქსელური კონტექსტები, ამიტომ მათ მოეპყარით როგორც ცალკეულ კითხვებს, როცა თავად pull იმუშავებს.