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 файлыг арчлах бол демоны эзэмших ёстой өгөгдлийн хувьд нэртэй эзлэхүүнийг илүүд үз, ингэснээр хост зам хэзээ ч гэрээний хэсэг болохгүй.