docker pull μέσω VPN: ο daemon έχει δικό του δίκτυο

Ο φορητός σας υπολογιστής είναι στο εταιρικό VPN, το curl φτάνει στο εσωτερικό registry, και όμως το docker pull εξακολουθεί να αποτυγχάνει με EOF. Αυτός ο συνδυασμός δεν είναι αντίφαση. Η εντολή που πληκτρολογήσατε εκτελείται στο shell σας, αλλά η μεταφορά εκτελείται στον daemon που έχει επιλέξει το Docker CLI, και αυτός ο daemon μπορεί να βρίσκεται σε εντελώς άλλον host. Η δική του διαδρομή δικτύου είναι αυτή που πρέπει να λειτουργεί, και οι δικές του ρυθμίσεις proxy είναι αυτές που ισχύουν.

Ξεκινήστε προσδιορίζοντας τη μηχανή, όχι τη διαδρομή

Εκτελέστε docker context show και docker version. Η έξοδος της έκδοσης εκτυπώνει ένα τμήμα πελάτη και ένα τμήμα διακομιστή, και το μπλοκ του διακομιστή σας λέει ποιος απάντησε: μια τοπική εγγενής μηχανή, η εικονική μηχανή του Docker Desktop ή ένας daemon σε απομακρυσμένο μηχάνημα. Το docker context inspect θα δείξει το τελικό σημείο του επιλεγμένου context αν θέλετε να είστε βέβαιοι, και καμία από αυτές τις εντολές δεν αλλάζει τίποτα.

Μια μεταβλητή περιβάλλοντος όπως το DOCKER_HOST μπορεί να στρέψει σιωπηλά το CLI σε διαφορετική μηχανή από αυτή που υποθέτετε, που είναι η συνήθης εξήγηση για έναν φορητό υπολογιστή που φαίνεται να είναι στο VPN ενώ το pull ταξιδεύει αλλού.

Ο daemon έχει τη δική του ταυτότητα δικτύου

Μια απομακρυσμένη μηχανή χρειάζεται τη δική της εγκεκριμένη διαδρομή προς το ιδιωτικό registry. Η σύνδεση του VPN client του φορητού σας δίνει σε αυτόν τον φορητό μια διαδρομή· δεν δίνει σε έναν daemon που βρίσκεται σε εργαστήριο ή σε υποδίκτυο cloud την ίδια ιδιωτική διεύθυνση. Αν η μηχανή είναι το Docker Desktop, το pull γίνεται μέσα στην εικονική του μηχανή, η οποία έχει δική της διαμόρφωση δικτύου και proxy, ξεχωριστή από το περιβάλλον του shell σας.

Γι' αυτό ένα επιτυχημένο curl στον host είναι απόδειξη για τον host και τίποτα περισσότερο.

Βρείτε ποια ανταλλαγή με το registry τελείωσε

Το pull μιας εικόνας είναι μια ακολουθία: έλεγχος ταυτότητας, ανάκτηση του manifest και μετά μεταφορές blob που συχνά ανακατευθύνονται σε αποθήκευση αντικειμένων ή σε τελικό σημείο CDN. Ένα επιτυχημένο docker login αποδεικνύει μόνο το πρώτο βήμα, και ένα token μπορεί να είναι απολύτως έγκυρο ενώ ο host blob στον οποίο γίνεται η ανακατεύθυνση δεν είναι προσβάσιμος από το δίκτυο του daemon. Σημειώστε την ακριβή ώρα, την αναφορά της εικόνας και το πρώτο χρήσιμο συμβάν από το log του daemon ή του client πριν αλλάξετε οτιδήποτε.

Το EOF από μόνο του δεν ονομάζει αιτία. Μπορεί να είναι μια κομμένη σύνδεση, ένας proxy που έριξε τη ροή, ένα timeout ή πρόβλημα MTU, και το να μαντεύει κανείς ανάμεσά τους χωρίς το συμβάν με χρονική σήμανση είναι ο τρόπος με τον οποίο οι άνθρωποι ξαναχτίζουν μια υγιή μηχανή. Αντιμετωπίστε τη μετατόπιση byte στην έξοδο του client ως δεδομένο, γιατί μια μεταφορά που σταματά στο ίδιο μέγεθος κάθε φορά είναι άλλο ζώο από μια που δεν ξεκινά ποτέ. Καταγράψτε και τα δύο αποτελέσματα και συγκρίνετέ τα μεταξύ των προσπαθειών.

Διαμορφώστε το στοιχείο που μεταφέρει

Για μια εγγενή μηχανή Linux, ο proxy ανήκει στο περιβάλλον της υπηρεσίας, όχι στο shell σας. Ένα αρχείο drop-in κάτω από το /etc/systemd/system/docker.service.d/ με καταχωρήσεις HTTP_PROXY, HTTPS_PROXY και NO_PROXY, ακολουθούμενο από systemctl daemon-reload και επανεκκίνηση, είναι η τεκμηριωμένη διάταξη. Το Docker Desktop εκθέτει τις ίδιες τιμές μέσω των δικών του ρυθμίσεων, και η επεξεργασία ενός προφίλ shell δεν αγγίζει καμία από τις δύο.

Αν το registry πρέπει να προσεγγίζεται απευθείας μέσω του VPN, ο daemon χρειάζεται resolver, διαδρομή και σκόπιμο αποκλεισμό proxy, όχι μόνο αποκλεισμό. Η αντιστοίχιση NO_PROXY είναι σύγκριση συμβολοσειρών ανά στοιχείο, και μια εξαίρεση χωρίς υποκείμενη διαδρομή παράγει αποτυχία που μοιάζει με πρόβλημα proxy.

Όταν η εταιρική επιθεώρηση TLS βρίσκεται στην εγκεκριμένη διαδρομή, εγκαταστήστε την επαληθευμένη ρίζα της μέσω της ροής εργασίας της μηχανής ή του Desktop. Η προσθήκη του registry στα insecure-registries είναι διαφορετική αλλαγή που απενεργοποιεί την επικύρωση, και δεν είναι διαμόρφωση αποθετηρίου εμπιστοσύνης.

Επαναλάβετε ένα ελεγχόμενο pull και ελέγξτε τι άλλαξε

Αλλάξτε ένα όριο, επανεκκινήστε το στοιχείο που το κατέχει και επαναλάβετε το ίδιο pull από το ίδιο context. Επαληθεύστε την αναφορά εικόνας και το digest που προκύπτουν, όχι την απουσία σφάλματος, γιατί ένα προσωρινά αποθηκευμένο επίπεδο μπορεί να κάνει μια δεύτερη προσπάθεια να διανύσει πολύ μικρότερο μέρος της διαδρομής από την πρώτη. Κρατήστε στο ticket τις μεταφορές που πραγματικά συνέβησαν, αφού είναι η μόνη καταγραφή του τι δοκίμασε πραγματικά η επανάληψη.

Τα βήματα build και τα containers που εκτελούνται έχουν τα δικά τους context δικτύου, οπότε αντιμετωπίστε τα ως ξεχωριστά ερωτήματα μόλις λειτουργήσει το ίδιο το pull.