Docker sējuma montāža neizdodas pēc VPN savienojuma: pārbaudiet dēmonu

Gandrīz katrs šīs problēmas apraksts vaino sējumu, un tieši tāpēc labojums aizņem tik daudz laika. Jums bija strādājoša bind mount, uzņēmuma VPN savienojās, un docker compose up tagad neizdodas ar trūkstošu avota ceļu, tukšu direktoriju vai montāžu, kuru dzinējs atsakās izveidot. Vidēs, ko esmu sakārtojis, Compose fails nebija mainīts un ceļš bija pareizs. Mainījās tas, kurš dēmons saņēma pieprasījumu, un montāžas kļūda bija tikai pirmā vieta, kur šī atšķirība kļuva redzama.

Sējums nekad nepārvietojās; pārvietojās pieprasījums

Karodziņš -v /srv/app:/app nav direktorijas kopija, ko veic jūsu shell. Klients to pārvērš API pieprasījumā, un atbildošais dēmons atrisina /srv/app pret savu failu sistēmu. Kad abas puses darbojas uz viena kodola, šis ceļš ir tas, ko redzat failu pārvaldniekā. Kad endpoint mainās, tā pati virkne tiek meklēta mašīnā, kas nekad nav dzirdējusi par jūsu projekta direktoriju, un dēmons vai nu ziņo, ka avots trūkst, vai klusi izveido tukšu direktoriju tā vietā.

Tāpēc arī nosauktais sējums turpina darboties, bet bind mount ne. -v appdata:/app nosauc krātuvi, kas pieder dēmonam, tāpēc nevienam resursdatora ceļam nav jāpastāv noteiktā vietā. Ja vienas pakalpojuma pārslēgšana no bind mount uz nosauktu sējumu likvidē kļūdu, jūs problēmu neesat novērsis. Jūs esat apstiprinājis, ka klients un dēmons nepiekrīt, kurai failu sistēmai ceļš pieder, un šī nesaskaņa atgriežas mirklī, kad atkal vajadzīga īsta resursdatora direktorija.

Izdrukājiet endpoint pirms montāžas aizskaršanas

Vairāki iestatījumi var norādīt klientu uz endpoint, un tie ne vienmēr saskan: --context karodziņš, DOCKER_CONTEXT, DOCKER_HOST pašreizējā shell, un klienta konfigurācijā saglabātais konteksts. Tā vietā, lai spriestu par prioritāti, izdrukājiet visus un salīdziniet atbildes.

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

Klienta konfigurācija atrodas ~/.docker/config.json failā Linux un macOS sistēmās, un %USERPROFILE%\.docker\config.json failā Windows, un pašreizējā terminālī eksportētā vērtība aizstāj saglabāto tikai šai sesijai. Ja endpoint ir resursdatora nosaukums, nevis lokāls socket, nosaukumu izšķiršana un maršruti izlemj, kur tas nokļūs, un tieši to pārraksta VPN klients. Tunelis, kas pievieno maršrutu vai nomaina resolveri, var nosūtīt vārdu, kas agrāk nozīmēja šo klēpjdatoru, uz adresi uzņēmuma tīklā.

Salīdziniet stāvokli, nevis konfigurāciju. Palaidiet docker ps -a un docker images ar izslēgtu tuneli, pēc tam atkal ar ieslēgtu. Atšķirīgs konteineru saraksts ir spēcīgāks pierādījums par jebkuru konfigurācijas failu, jo tas parāda, ka uz jūsu pieprasījumu atbildēja cits dēmons.

Pajautājiet dēmonam, vai ceļš tur pastāv

Kad zināt, kuru dēmonu sasniedzāt, lieciet tam apskatīt direktoriju. --mount forma neizdodas ar skaidrāku ziņojumu nekā īsais karodziņš, jo tā validē avotu pirms konteinera palaišanas:

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

Ja tā ziņo, ka avots trūkst, izveidojiet to mašīnā, kas atbildēja, vai norādiet pakalpojumu uz nosauktu sējumu un nokopējiet datus tur. Ko jums nevajadzētu darīt, ir no jauna veidot sējumus un pārinstalēt dzinēju pirms šīs pārbaudes. Šīs darbības pietiekami maina vidi, lai paslēptu neatbilstību, vienlaikus atstājot to vietā.

Vēl viens ceļš iet pavisam citur: image vilkšana ir dēmona, nevis klienta darbs. Veiksmīga vilkšana pierāda tikai to, ka dēmons sasniedz registry, un strādājoša bind mount tikai to, ka ceļš tika atrisināts. Pārbaudiet katru ceļu tur, kur tas faktiski tiek izpildīts, citādi pavadīsiet pēcpusdienu ar nepareizo.

Intraneta nosaukumi neizdodas cita iemesla dēļ

Tā paša ziņojuma otrā puse parasti ir tā, ka konteiners nevar sasniegt intranet.corp.example. Tas ir atsevišķs mehānisms, nevis otra sējuma problēma. Konteiners iegūst savu /etc/resolv.conf palaišanas brīdī, ģenerētu no dēmona resolvera iestatījumiem, tāpēc DNS serveris, ko VPN pievienoja pēc konteinera izveides, tur neparādīsies, kamēr konteiners netiks izveidots no jauna.

Docker iebūvētais resolveris lietotāja definētā tīklā pārsūta ārējos vaicājumus uz resursdatorā konfigurētajiem serveriem, kas palīdz, kad VPN pārraksta resursdatora resolveri, un kaitē, kad sadalītais DNS sūta iekšējo zonu uz serveri, kuru dēmons vairs neredz. Šaura, skaidra kartēšana apiet strīdu par nosaukumiem, kas nekad nemainās:

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

Tas ieraksta ierakstu konteinera hosts failā, tāpēc konteiners neko neuzzina par tuneli, un tas arī iesaldē adresi. Kad iekšējais resursdators pārvietojas, ieraksts paliek nepareizs, līdz kāds rediģē Compose failu. Izmantojiet to fiksētai iekārtai vai piespraustai datubāzei, un ļaujiet DNS apstrādāt nosaukumus, kas pārvietojas.

Ko pārinstalēšana faktiski maina

Docker Desktop pārinstalēšana no jauna izveido VM, socket un kontekstu sarakstu, un montāža atkal sāk darboties. Šis rezultāts ir īsts un neko neiemāca, tāpēc tā pati kļūme atgriežas pēc nākamā VPN atjauninājuma. Pārinstalēšana aizstāja endpoint, ko klients izmantoja; tā nesaskaņoja ceļu, ko nosauc jūsu projekts, ar failu sistēmu, ko dēmons faktiski lasa.

Mana darba kārtība ir īsa. Apstipriniet, kuru endpoint klients izmantos. Salīdzinot konteineru sarakstus, apstipriniet, kurš dēmons atbildēja. Palūdziet tam dēmonam uzskaitīt avota ceļu. Tikai tad rediģējiet montāžu, pievienojiet hosts ierakstu vai mainiet sējuma tipu. Ja uzturat Compose failu komandai, kas strādā caur VPN, dodiet priekšroku nosauktiem sējumiem datiem, kas dēmonam jāpārvalda, lai resursdatora ceļš nekad nekļūtu par līguma daļu.