Η προσάρτηση τόμου του Docker αποτυγχάνει μετά τη σύνδεση VPN: ελέγξτε τον δαίμονα

Σχεδόν κάθε κείμενο για αυτό το πρόβλημα κατηγορεί τον τόμο, και γι' αυτό ακριβώς η διόρθωση παίρνει τόσο πολύ χρόνο. Είχατε ένα bind mount που δούλευε, το εταιρικό VPN συνδέθηκε και docker compose up τώρα αποτυγχάνει με μια διαδρομή προέλευσης που λείπει, έναν κενό κατάλογο ή μια προσάρτηση που ο μηχανισμός αρνείται να δημιουργήσει. Στα περιβάλλοντα που καθάρισα, το αρχείο Compose δεν είχε αλλάξει και η διαδρομή ήταν σωστή. Αυτό που άλλαξε ήταν ποιος δαίμονας έλαβε το αίτημα, και το σφάλμα προσάρτησης ήταν απλώς το πρώτο σημείο όπου αυτή η διαφορά έγινε ορατή.

Ο τόμος δεν μετακινήθηκε ποτέ· το αίτημα μετακινήθηκε

Μια -v /srv/app:/app δεν είναι αντιγραφή καταλόγου που εκτελεί το shell σας. Ο πελάτης τη μετατρέπει σε αίτημα API, και ο δαίμονας που απαντά επιλύει /srv/app στο δικό του σύστημα αρχείων. Όταν και οι δύο πλευρές τρέχουν στον ίδιο πυρήνα, αυτή η διαδρομή είναι αυτή που βλέπετε στον διαχειριστή αρχείων. Όταν το endpoint αλλάζει, το ίδιο αλφαριθμητικό αναζητείται σε ένα μηχάνημα που δεν έχει ακούσει ποτέ για τον κατάλογο του έργου σας, και ο δαίμονας είτε αναφέρει την προέλευση ως απούσα είτε δημιουργεί ήσυχα έναν κενό κατάλογο στη θέση της.

Γι' αυτό επίσης ένας επώνυμος τόμος συνεχίζει να λειτουργεί ενώ ένα bind mount όχι. -v appdata:/app ονομάζει αποθήκευση που ανήκει στον δαίμονα, οπότε καμία διαδρομή υποδοχής δεν χρειάζεται να υπάρχει σε συγκεκριμένο σημείο. Αν η αλλαγή μιας υπηρεσίας από bind mount σε επώνυμο τόμο κάνει το σφάλμα να εξαφανιστεί, δεν έχετε διορθώσει το πρόβλημα. Έχετε επιβεβαιώσει ότι ο πελάτης και ο δαίμονας διαφωνούν για το ποιο σύστημα αρχείων ανήκει η διαδρομή, και αυτή η διαφωνία επιστρέφει τη στιγμή που θα χρειαστείτε ξανά έναν πραγματικό κατάλογο υποδοχής.

Εκτυπώστε το endpoint πριν αγγίξετε την προσάρτηση

Πολλές ρυθμίσεις μπορούν να κατευθύνουν τον πελάτη σε ένα endpoint, και δεν συμφωνούν πάντα: μια --context σημαία, DOCKER_CONTEXT, DOCKER_HOST στο τρέχον shell, και το context που είναι αποθηκευμένο στη διαμόρφωση του πελάτη. Αντί να συλλογίζεστε για την προτεραιότητα, εκτυπώστε τα όλα και συγκρίνετε τις απαντήσεις.

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

Η διαμόρφωση του πελάτη βρίσκεται στο ~/.docker/config.json σε Linux και macOS και στο %USERPROFILE%\.docker\config.json σε Windows, και μια τιμή που εξάγεται στο τρέχον τερματικό υπερισχύει της αποθηκευμένης μόνο για αυτή τη συνεδρία. Αν το endpoint είναι όνομα υποδοχής αντί για τοπικό socket, η επίλυση ονομάτων και οι διαδρομές αποφασίζουν πού θα προσγειωθεί, και αυτά ακριβώς ξαναγράφει ένας πελάτης VPN. Μια σήραγγα που προσθέτει διαδρομή ή αλλάζει τον resolver μπορεί να στείλει ένα όνομα που κάποτε σήμαινε αυτό το φορητό σε μια διεύθυνση μέσα στο εταιρικό δίκτυο.

Συγκρίνετε κατάσταση αντί για διαμόρφωση. Εκτελέστε docker ps -a και docker images με τη σήραγγα κάτω, και μετά ξανά με αυτήν πάνω. Μια διαφορετική λίστα κοντέινερ είναι ισχυρότερη απόδειξη από οποιοδήποτε αρχείο διαμόρφωσης, γιατί δείχνει ότι ένας διαφορετικός δαίμονας απάντησε στο αίτημά σας.

Ρωτήστε τον δαίμονα αν η διαδρομή υπάρχει εκεί

Μόλις μάθετε ποιον δαίμονα προσεγγίσατε, κάντε τον να κοιτάξει τον κατάλογο. Η μορφή --mount αποτυγχάνει με σαφέστερο μήνυμα από τη σύντομη σημαία, γιατί επικυρώνει την προέλευση πριν ξεκινήσει το κοντέινερ:

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

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

Μια ακόμη διαδρομή τρέχει σε εντελώς άλλο σημείο: το τράβηγμα ενός image είναι δουλειά του δαίμονα, όχι του πελάτη. Ένα επιτυχές τράβηγμα αποδεικνύει μόνο ότι ο δαίμονας φτάνει σε ένα registry, και ένα bind mount που δουλεύει μόνο ότι μια διαδρομή επιλύθηκε. Δοκιμάστε κάθε διαδρομή εκεί όπου εκτελείται πραγματικά, αλλιώς θα περάσετε ένα απόγευμα με τη λάθος.

Τα ονόματα intranet αποτυγχάνουν για διαφορετικό λόγο

Το δεύτερο μισό της ίδιας αναφοράς είναι συνήθως ότι το κοντέινερ δεν μπορεί να φτάσει στο intranet.corp.example. Αυτός είναι ξεχωριστός μηχανισμός, όχι δεύτερο πρόβλημα τόμου. Ένα κοντέινερ παίρνει το /etc/resolv.conf όταν ξεκινά, παραγόμενο από τις ρυθμίσεις resolver του δαίμονα, οπότε ένας διακομιστής DNS που πρόσθεσε το VPN αφού δημιουργήθηκε το κοντέινερ δεν θα εμφανιστεί εκεί μέχρι να αναδημιουργηθεί το κοντέινερ.

Ο ενσωματωμένος resolver του Docker σε ένα δίκτυο ορισμένο από τον χρήστη προωθεί τα εξωτερικά ερωτήματα στους διαμορφωμένους διακομιστές του υποδοχέα, κάτι που βοηθά όταν το VPN ξαναγράφει τον resolver του υποδοχέα και βλάπτει όταν το split DNS στέλνει μια εσωτερική ζώνη σε έναν διακομιστή που ο δαίμονας δεν βλέπει πια. Μια στενή, ρητή αντιστοίχιση παρακάμπτει τη διαφωνία για ονόματα που δεν αλλάζουν ποτέ:

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

Αυτό γράφει μια καταχώριση στο αρχείο hosts του κοντέινερ, ώστε το κοντέινερ να μη μαθαίνει τίποτα για τη σήραγγα, και επίσης παγώνει τη διεύθυνση. Όταν ο εσωτερικός υποδοχέας μετακινηθεί, η καταχώριση μένει λάθος μέχρι κάποιος να επεξεργαστεί το αρχείο Compose. Χρησιμοποιήστε το για σταθερή συσκευή ή καρφιτσωμένη βάση δεδομένων, και αφήστε το DNS να χειρίζεται ονόματα που κινούνται.

Τι αλλάζει πραγματικά μια επανεγκατάσταση

Η επανεγκατάσταση του Docker Desktop αναδημιουργεί το VM, το socket και τη λίστα context, και η προσάρτηση αρχίζει να δουλεύει ξανά. Αυτό το αποτέλεσμα είναι πραγματικό και δεν διδάσκει τίποτα, γι' αυτό η ίδια αποτυχία επιστρέφει μετά την επόμενη ενημέρωση VPN. Η επανεγκατάσταση αντικατέστησε το endpoint που χρησιμοποιούσε ο πελάτης· δεν συμφιλίωσε τη διαδρομή που ονομάζει το έργο σας με το σύστημα αρχείων που διαβάζει πραγματικά ο δαίμονας.

Η σειρά εργασίας μου είναι σύντομη. Επιβεβαιώστε ποιο endpoint θα χρησιμοποιήσει ο πελάτης. Επιβεβαιώστε ποιος δαίμονας απάντησε συγκρίνοντας λίστες κοντέινερ. Ζητήστε από αυτόν τον δαίμονα να απαριθμήσει τη διαδρομή προέλευσης. Μόνο τότε επεξεργαστείτε την προσάρτηση, προσθέστε καταχώριση hosts ή αλλάξτε τύπο τόμου. Αν συντηρείτε το αρχείο Compose για μια ομάδα που εργάζεται μέσω VPN, προτιμήστε επώνυμους τόμους για δεδομένα που πρέπει να ανήκουν στον δαίμονα, ώστε μια διαδρομή υποδοχέα να μην γίνει ποτέ μέρος της σύμβασης.