VPN туташкандан кийин Docker көлөмүн байлоо ишке ашпайт: демонду текшериңиз

Бул маселе жөнүндөгү дээрлик ар бир жазуу көлөмдү күнөөлөйт, жана оңдоонун ушунчалык узакка созулушунун себеби да ушул. Сизде иштеп турган 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 ичинде, жана кардардын конфигурациясында сакталган контекст. Артыкчылык жөнүндө ойлонуунун ордуна, баарын басып чыгарып, жоопторду салыштырыңыз.

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.corp.exampleдарегине жете албаганы. Бул өзүнчө механизм, экинчи көлөм маселеси эмес. Контейнер өзүнүн /etc/resolv.conf файлын иштеп баштаганда алат, ал демондун resolver параметрлеринен жаралат, ошондуктан контейнер түзүлгөндөн кийин VPN кошкон DNS сервери контейнер кайра түзүлмөйүнчө анда көрүнбөйт.

Колдонуучу аныктаган тармактагы Docker'дин курамындагы resolver тышкы сурамдарды хосттогу конфигурацияланган серверлерге өткөрөт, бул VPN хосттун resolver'ин кайра жазганда жардам берет жана бөлүнгөн DNS ички зонаны демон мындан ары көрбөгөн серверге жөнөткөндө зыян келтирет. Тар, ачык салыштыруу эч качан өзгөрбөгөн аттар үчүн талашты четтеп өтөт:

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

Бул контейнердин hosts файлына жазуу кошот, ошондуктан контейнер туннель жөнүндө эч нерсе билбейт, жана даректи тоңдурат. Ички хост жылганда, жазуу бирөө Compose файлын түзөткөнгө чейин туура эмес бойдон калат. Аны туруктуу түзмөк же бекитилген маалымат базасы үчүн колдонуңуз, ал эми жылып жүргөн аттарды DNS'ке калтырыңыз.

Кайра орнотуу чындап эмнени өзгөртөт

Docker Desktop'ты кайра орнотуу VM'ди, socket'ти жана контексттер тизмесин кайра түзөт, жана байлоо кайра иштей баштайт. Бул натыйжа чыныгы жана эч нерсеге үйрөтпөйт, ошондуктан кийинки VPN жаңыртуусунан кийин ошол эле бузулуу кайтат. Кайра орнотуу кардар колдонгон endpoint'ти алмаштырды; ал долбооруңуз атаган жолду демон чындап окуган файлдык система менен шайкештештирген жок.

Менин иш тартибим кыска. Кардар кайсы endpoint'ти колдонорун тастыктаңыз. Контейнер тизмелерин салыштырып, кайсы демон жооп бергенин тастыктаңыз. Ошол демонго баштапкы жолду тизмелөөнү сураныңыз. Ошондон кийин гана байлоону түзөтүңүз, hosts жазуусун кошуңуз же көлөм түрүн өзгөртүңүз. Эгер VPN аркылуу иштеген топ үчүн Compose файлын кармап жатсаңыз, демонго таандык болушу керек болгон маалыматтар үчүн аталган көлөмдөрдү тандаңыз, ошентип хост жолу эч качан келишимдин бөлүгү болуп калбайт.