VPN ulangandan keyin Docker jildini ulash muvaffaqiyatsiz tugaydi: daemonni tekshiring

Bu muammo haqidagi deyarli har bir yozuv jildni ayblaydi va tuzatishning bunchalik uzoq davom etishining sababi ham shu. Sizda ishlayotgan bind mount bor edi, korporativ VPN ulandi va docker compose up endi manba yo'li yo'qligi, bo'sh katalog yoki dvigatel yaratishdan bosh tortadigan ulash bilan muvaffaqiyatsiz tugaydi. Men tartibga solgan muhitlarda Compose fayli o'zgarmagan va yo'l to'g'ri edi. O'zgargan narsa qaysi daemon so'rovni olgani edi va ulash xatosi bu farq birinchi marta ko'ringan joy edi.

Jild hech qachon ko'chmadi; so'rov ko'chdi

Bayroq -v /srv/app:/app sizning shell bajaradigan katalog nusxasi emas. Mijoz uni API so'roviga aylantiradi va javob beruvchi daemon /srv/app ni o'zining fayl tizimiga nisbatan hal qiladi. Ikkala tomon ham bir yadroda ishlaganda, o'sha yo'l fayl menejerida ko'rgan yo'lingizdir. Endpoint o'zgarganda, xuddi shu satr sizning loyiha katalogingiz haqida hech eshitmagan mashinada qidiriladi va daemon yo manbani yo'q deb xabar qiladi yoki uning o'rniga jimgina bo'sh katalog yaratadi.

Nomlangan jild ishlashda davom etib, bind mount bunday qilmasligining sababi ham shu. -v appdata:/app daemonga tegishli saqlashni nomlaydi, shuning uchun hech qanday host yo'li ma'lum bir joyda bo'lishi shart emas. Bitta xizmatni bind mount-dan nomlangan jildga almashtirish xatoni yo'q qilsa, siz muammoni tuzatmadingiz. Siz mijoz va daemon yo'l qaysi fayl tizimiga tegishli ekanida kelishmasligini tasdiqladingiz va bu kelishmovchilik yana haqiqiy host katalogi kerak bo'lgan paytda qaytadi.

Ulashga tegishdan oldin endpoint-ni chop eting

Bir nechta sozlama mijozni endpoint-ga yo'naltirishi mumkin va ular har doim ham bir fikrda emas: --context bayroq, DOCKER_CONTEXT, DOCKER_HOST joriy shell-da va mijoz konfiguratsiyasida saqlangan context. Ustuvorlik haqida fikr yuritish o'rniga hammasini chop eting va javoblarni solishtiring.

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

Mijoz konfiguratsiyasi quyidagi joyda: ~/.docker/config.json Linux va macOS-da, va quyidagi joyda: %USERPROFILE%\.docker\config.json Windows-da, va joriy terminalda eksport qilingan qiymat saqlangan qiymatni faqat shu sessiya uchun bekor qiladi. Agar endpoint mahalliy socket emas, balki host nomi bo'lsa, nom hal qilish va marshrutlar uning qayerga tushishini belgilaydi va VPN mijozi aynan shularni qayta yozadi. Marshrut qo'shadigan yoki resolver-ni almashtiradigan tunnel avval bu noutbukni bildirgan nomni korporativ tarmoq ichidagi manzilga yuborishi mumkin.

Konfiguratsiyani emas, holatni solishtiring. Tunnel o'chirilganda docker ps -a va docker images ni ishga tushiring, keyin tunnel yoniq holda yana. Boshqa konteyner ro'yxati har qanday konfiguratsiya faylidan kuchliroq dalil, chunki u sizning so'rovingizga boshqa daemon javob berganini ko'rsatadi.

Yo'l o'sha yerda bormi, daemondan so'rang

Qaysi daemonga yetganingizni bilganingizdan so'ng, unga katalogni ko'rishni buyuring. --mount shakl qisqa bayroqqa qaraganda aniqroq xabar bilan muvaffaqiyatsiz tugaydi, chunki konteynerni ishga tushirishdan oldin manbani tekshiradi:

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

Agar u manbani yo'q deb xabar qilsa, uni javob bergan mashinada yarating yoki xizmatni nomlangan jildga yo'naltirib, ma'lumotlarni u yerga ko'chiring. Bu tekshiruvdan oldin jildlarni qayta yaratish va dvigatelni qayta o'rnatish — qilmasligingiz kerak bo'lgan ish. Bunday harakatlar nomuvofiqlikni yashirish uchun muhitni yetarlicha o'zgartiradi, lekin uni joyida qoldiradi.

Yana bir yo'l butunlay boshqa joyda boradi: image tortish daemon ishi, mijoz ishi emas. Muvaffaqiyatli tortish faqat daemon registry-ga yeta olishini isbotlaydi, ishlaydigan bind mount esa faqat yo'l hal qilinganini. Har bir yo'lni u haqiqatda bajariladigan joyda sinab ko'ring, aks holda noto'g'ri yo'lda yarim kun o'tkazasiz.

Intranet nomlari boshqa sabab bilan muvaffaqiyatsiz tugaydi

Xuddi shu hisobotning ikkinchi yarmi odatda konteyner intranet.corp.examplega yeta olmasligidir. Bu alohida mexanizm, ikkinchi jild muammosi emas. Konteyner o'zining /etc/resolv.conf ni ishga tushganda oladi, u daemon resolver sozlamalaridan yaratiladi, shuning uchun konteyner yaratilgandan keyin VPN qo'shgan DNS server konteyner qayta yaratilmaguncha u yerda ko'rinmaydi.

Foydalanuvchi belgilagan tarmoqdagi Docker-ning ichki resolver-i tashqi so'rovlarni host-da sozlangan serverlarga uzatadi, bu VPN host resolver-ni qayta yozganda yordam beradi va bo'lingan DNS ichki zonani daemon endi ko'rmaydigan serverga yuborganda zarar keltiradi. Tor va aniq xaritalash hech qachon o'zgarmaydigan nomlar uchun bu bahsni chetlab o'tadi:

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

Bu konteynerning hosts fayliga yozuv yozadi, shuning uchun konteyner tunnel haqida hech narsa o'rganmaydi va manzilni ham muzlatadi. Ichki host ko'chganda, kimdir Compose faylini tahrirlamaguncha yozuv noto'g'ri bo'lib qoladi. Uni qat'iy qurilma yoki mahkamlangan ma'lumotlar bazasi uchun ishlating, ko'chib yuruvchi nomlarni DNS-ga qoldiring.

Qayta o'rnatish aslida nimani o'zgartiradi

Docker Desktop-ni qayta o'rnatish VM, socket va context ro'yxatini qayta yaratadi va ulash yana ishlay boshlaydi. Bu natija haqiqiy va u hech narsa o'rgatmaydi, shuning uchun keyingi VPN yangilanishidan keyin xuddi shu nosozlik qaytadi. Qayta o'rnatish mijoz ishlatgan endpoint-ni almashtirdi; u loyihangiz nomlagan yo'lni daemon haqiqatda o'qiydigan fayl tizimi bilan moslashtirmadi.

Mening ish tartibim qisqa. Mijoz qaysi endpoint-dan foydalanishini tasdiqlang. Konteyner ro'yxatlarini solishtirib qaysi daemon javob berganini tasdiqlang. O'sha daemondan manba yo'lini ro'yxatga olishni so'rang. Shundan keyingina ulashni tahrirlang, hosts yozuvini qo'shing yoki jild turini o'zgartiring. Agar VPN orqali ishlaydigan jamoa uchun Compose faylini yuritsangiz, daemonga tegishli bo'lishi kerak bo'lgan ma'lumotlar uchun nomlangan jildlarni afzal ko'ring, shunda host yo'li hech qachon shartnomaning bir qismiga aylanmaydi.