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 файлын ұстап отырсаңыз, демонға тиесілі болуы керек деректер үшін атаулы көлемдерді таңдаңыз, осылайша хост жолы ешқашан келісімнің бөлігіне айналмайды.