له VPN سره د نښلېدو وروسته د Docker حجم مونت ناکامېږي: ډیمون وګورئ

د دې ستونزې نږدې هره لیکنه حجم تورنوي، او د همدې له امله سمون دومره وخت نیسي. تاسو یو bind mount درلود چې کار یې کاوه، شرکت VPN ونښلېده، او docker compose up اوس د ورک شوي سرچینې لارې، تشې ډایرکټرۍ یا هغه مونت سره ناکامېږي چې ماشین یې له جوړولو انکار کوي. هغو چاپیریالونو کې چې ما پاک کړل، د Compose فایل نه و بدل شوی او لاره سمه وه. هغه څه چې بدل شول دا وو چې کوم ډیمون غوښتنه ترلاسه کړه، او د مونت تېروتنه یوازې لومړنی ځای و چې دا توپیر ښکاره شو.

حجم هیچېرې ونه خوځېده؛ غوښتنه وخوځېده

یو -v /srv/app:/app فلګ ستاسو shell جوړونکې ډایرکټري کاپي نه ده. کلاینټ هغه API غوښتنې ته بدلوي، او هغه ډیمون چې ځواب وایي /srv/app د خپل فایل سیسټم له مخې حل کوي. کله چې دواړه خواوې په یوه کرنل کار کوي، هغه لاره هماغه ده چې تاسو یې د فایل مدیر کې وینئ. کله چې endpoint بدل شي، هماغه تار په هغه ماشین کې لټول کېږي چې ستاسو د پروژې ډایرکټري یې هیچېرنه نه ده اورېدلې، او ډیمون یا سرچینه ورکه ښیي یا د هغې پر ځای په چوپتیا تشه ډایرکټري جوړوي.

همدا لامل دی چې نوم لرونکی حجم کار کوي خو bind mount نه. -v appdata:/app د ډیمون ملکیت ذخیره نوموي، نو هېڅ host لاره اړ نه ده چې په یو ځانګړي ځای کې وي. که یوه خدمت له bind mount څخه نوم لرونکي حجم ته بدلول تېروتنه له منځه یوسي، تاسو ستونزه نه ده سمه کړې. تاسو تایید کړه چې کلاینټ او ډیمون په دې نه یوځای کېږي چې لاره د کوم فایل سیسټم ده، او هغه اختلاف هغه ساه چې تاسو بیا ریښتینې host ډایرکټري ته اړتیا لرئ بېرته راځي.

له مونت څخه مخکې endpoint چاپ کړئ

څو تنظیمات کولای شي کلاینټ endpoint ته وروښي، او هغوی تل یو شان نه دي: --context فلګ، DOCKER_CONTEXT، DOCKER_HOST په اوسني shell کې، او هغه context چې د کلاینټ په ترتیباتو کې خوندي دی. د لومړیتوب په اړه فکر کولو پر ځای ټول چاپ کړئ او ځوابونه پرتله کړئ.

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 پر ځای د host نوم وي، د نومونو حل او لارې پرېکړه کوي چې چېرته به کښېني، او 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 ترتیباتو څخه جوړېږي، نو هغه DNS سرور چې VPN د کانټینر له جوړېدو وروسته ورزیات کړی، تر هغو به هلته نه ښکاره شي چې کانټینر بیا جوړ شي.

د کاروونکي لخوا تعریف شوې شبکې کې د Docker داخلي resolver بهرنۍ پوښتنې د host ترتیبات شوو سرورونو ته لیږي، چې کله VPN د host resolver بیا لیکي مرسته کوي او کله چې وویشل شوی DNS یوه داخلي زون هغه سرور ته لیږي چې ډیمون نور نه ویني زیان رسوي. تنګ او روښانه نقشه کول د هغو نومونو لپاره دا بحث تر څنګ کوي چې هیچېرنه نه بدلېږي:

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

دا د کانټینر hosts فایل کې یوه ننوتنه لیکي، نو کانټینر د تونل په اړه هېڅ نه زده کوي، او پته هم کنګلوي. کله چې داخلي host ځای بدلوي، ننوتنه تر هغو غلطه پاتې کېږي چې څوک د Compose فایل سم کړي. دا د ثابت وسیله یا ټینګ شوي ډاټابیس لپاره وکاروئ، او خوځېدونکي نومونه DNS ته پرېږدئ.

بیا نصب واقعاً څه بدلوي

د Docker Desktop بیا نصبول VM، socket او د context لیست بیا جوړوي، او مونت بیا کار پیلوي. هغه پایله ریښتینې ده او هېڅ نه ښیي، ځکه هماغه ناکامي د بل VPN تازه کولو وروسته بېرته راځي. بیا نصب هغه endpoint بدل کړ چې کلاینټ کاراوه؛ دا هغه لاره چې ستاسو پروژه نوموي د هغه فایل سیسټم سره یو شان نه کړه چې ډیمون واقعاً لولي.

زما کاري ترتیب لنډ دی. تایید کړئ چې کلاینټ کوم endpoint کاروي. د کانټینر لیستونو په پرتله کولو تایید کړئ چې کوم ډیمون ځواب ویلی. له هغه ډیمون څخه وغواړئ چې د سرچینې لاره ولیکي. یوازې له هغه وروسته مونت سم کړئ، hosts ننوتنه ورزیاته کړئ، یا د حجم ډول بدل کړئ. که تاسو د هغه ټیم لپاره چې په VPN کار کوي د Compose فایل ساتئ، د هغې ډاټا لپاره نوم لرونکي حجمونه غوره کړئ چې باید د ډیمون ملکیت وي، تر څو host لاره هیچېرنه د تړون برخه نه شي.