docker pull د VPN له لارې: ډیمون خپله شبکه لري

ستاسو لپ‌ټاپ د شرکت په VPN کې دی، curl داخلي راجستر ته رسېږي، او بیا هم docker pull د EOF سره ناکامېږي. دا ترکیب تضاد نه دی. هغه امر چې تاسو ټایپ کړی ستاسو په شیل کې چلېږي، مګر انتقال په هغه ډیمون کې چلېږي چې Docker CLI غوره کړی، او هغه ډیمون کېدای شي په بشپړ بل هوسټ کې وي. هماغه د هغه شبکه‌يي لاره ده چې باید کار وکړي، او هماغه د هغه پراکسي تنظیمات دي چې پلي کېږي.

د لارې نه، د انجن په پېژندنې سره پیل وکړئ

docker context show او docker version چل کړئ. د نسخې پایله د کلاینټ برخه او د سرور برخه چاپوي، او د سرور بلاک تاسو ته وایي چې څوک ځواب ورکړ: سیمه‌ييز اصلي انجن، د Docker Desktop مجازي ماشین، یا په لرې ماشین کې ډیمون. که ډاډه غواړئ، docker context inspect به د غوره شوي کانټکسټ پای ټکی وښیي، او دغه امرونه هېڅ شی نه بدلوي.

د DOCKER_HOST په څېر چاپېریالي بدلونکې کولای شي CLI په غلط ډول بل انجن ته اشاره وکړي چې تاسو یې فکر کوئ، او دا هغه عادي توضیح ده چې لپ‌ټاپ د VPN په څېر ښکاري خو پل بل ځای ته ځي.

ډیمون خپله شبکه‌ييزه پېژندنه لري

لرې انجن ته خپله تصویب شوې لار د خصوصي راجستر تر څنګ اړینه ده. ستاسو د لپ‌ټاپ VPN کلاینټ نښلول هغه لپ‌ټاپ ته لار ورکوي؛ دغه کار د لابراتوار یا کلاوډ فرعي شبکې کې ناست ډیمون ته هغه ورته خصوصي پته نه ورکوي. که انجن Docker Desktop وي، پل د هغه مجازي ماشین په داخل کې پېښېږي، چې خپل شبکه‌يي او پراکسي ترتیبات لري چې ستاسو د شیل له چاپېریال جلا دي.

له همدې کبله په هوسټ کې بریالی curl یوازې د هوسټ په اړه شاهد دی او نور نه.

ومومئ چې د راجستر کوم تبادل پای ته ورسېد

د عکس پل یوه لړ ده: تصدیق، د مانیفیسټ ترلاسه کول، او بیا د blob انتقالونه چې ډېری وختونه شیټي ذخیره یا CDN پای ټکي ته لېږل کېږي. بریالی docker login یوازې لومړی ګام ثابتوي، او ټوکن کېدای شي بشپړ معتبر وي خو لېږل شوی blob هوسټ د ډیمون له شبکې نه رسېدونکی وي. د هر څه بدلولو دمخه دقیق وخت، د عکس حواله او د ډیمون یا کلاینټ لوګ کې لومړنۍ ګټوره پېښه ولیکئ.

EOF یوازې هېڅ لامل نه نوموي. کېدای شي پرې شوې اړیکه، جریان غورځولوونکی پراکسي، د وخت پای یا MTU ستونزه وي، او د وخت-نښه شوې پېښې پرته د دوی ترمنځ اټکل کول هغه لاره ده چې خلک روغ انجن بیا جوړوي. د کلاینټ په پایله کې بایټ بې‌ځایه والی د معلوماتو په توګه وګڼئ، ځکه هغه انتقال چې هر ځل په ورته اندازه ودرېږي یو بل څاروي دی له هغه چې هېڅکله نه پیلېږي. دواړه پایلې ولیکئ او د هڅو ترمنځ یې پرتله کړئ.

هغه برخه ترتیب کړئ چې انتقال کوي

د اصلي Linux انجن لپاره پراکسي د خدمت چاپېریال کې وي، نه ستاسو په شیل کې. د /etc/systemd/system/docker.service.d/ لاندې د HTTP_PROXY، HTTPS_PROXY او NO_PROXY ننوتنو سره drop-in فایل، ورپسې systemctl daemon-reload او بیا پیل، هغه مستند ترتیب دی. Docker Desktop هماغه ارزښتونه د خپلو تنظیماتو له لارې وړاندې کوي، او د شیل پروفایل سمول د دوی له هیچا سره نه لګېږي.

که راجستر باید مستقیم د VPN له لارې ورسېدل شي، ډیمون ته resolver، لاره او په قصد شوی پراکسي استثنا اړینه ده، نه یوازې استثنا. د NO_PROXY سمون د هرې برخې لپاره د تار پرتله ده، او د لاندې لارې پرته استثنا داسې ناکامي پیدا کوي چې د پراکسي ستونزې په څېر ښکاري.

کله چې د شرکت TLS پلټنه په تصویب شوې لاره وي، د هغې تصدیق شوې ریښه د انجن یا Desktop کاري بهیر له لارې نصب کړئ. راجستر insecure-registries ته زیاتول یو بل بدلون دی چې اعتبارسنجي بندوي، او دا د باور ذخیرې ترتیب نه دی.

یو کنټرول شوی پل تکرار کړئ او وګورئ څه بدل شول

یوه پوله بدله کړئ، هغه برخه چې مالک یې دی بیا پیل کړئ، او هماغه پل له هماغه کانټکسټ څخه تکرار کړئ. د ترلاسه شوي عکس حواله او digest تصدیق کړئ، نه د تېروتنې نه‌شتون، ځکه کاش شوې طبقه کولای شي دوهمه هڅه له لومړي څخه ډېره کمه لاره ووهي. هغه انتقالونه چې واقعاً پېښ شوي په ټیکټ کې وساتئ، ځکه هغوی یوازینی ریکارډ دی چې بیا هڅې واقعاً څه وازمویل.

د build ګامونه او روان کنټینرونه خپل شبکه‌يي کانټکسټونه لري، نو کله چې پل پخپله کار وکړ، دوی جلا پوښتنې وګڼئ.