Docker: یو کانټینر د VPN له لارې روان کړئ او بل یې مستقیم وساتئ
تونل ته خپل کانټینر ورکړئ، یوازې هغو خدماتو ته اجازه ورکړئ چې د دې اړتیا لري دغه نوم فضا شریکه کړي، بیا د مالک وروسته څه ته پام وکړئ: پورټونه، localhost، DNS.
یو کوربه، دوه کاري بارونه او یوه اړتیا چې دوی بېلوي: یو ډاونلوډ کلاینټ چې باید د سوداګریز VPN له لارې راووځي، او یو مدیریتي انټرفیس چې باید د کوربه اړیکه وکاروي. په کوربه باندې د VPN کلاینټ نصبول اړتیا سمدلاسه پوره نه کوي، ځکه چې بیا دواړه کاري بارونه یوه خروجي شریکوي. هغه نمونه چې واقعاً کار کوي دا ده چې تونل خپل کانټینر ته یوسو او یوازې هغو کاري بارونو ته اجازه ورکړو چې ورته اړتیا لري د دې کانټینر شبکې نوم فضا ته ورننوځي. نور هر څه عادي Docker لاره ساتي، او هغه تفصیلات چې ورپسې راځي د دې پایله ده چې نوم فضا چا لري.
ولې شریکه نوم فضا قواعد بدلوي
هغه کانټینر چې د بل نوم فضا ته ورننوځي خپل شبکه یی سټیک نه ترلاسه کوي. هغه هماغه انټرفیسونه، هماغه د لارښوونې جدول او هماغه loopback ویني چې هغه کانټینر یې لري چې ورته ورننوتی، او همدا لامل دی چې نمونه ګټوره ده: کاري بار په عادي ډول حل او نښلوي، او لاندې تونل ترافیک نیسي پرته له دې چې اپلیکیشن پوه شي. بیه دا ده چې هر شبکه یی تنظیم اوس یو مالک لري، او ننوتونکی کانټینر هغه نه دی.
دا د مالکیت قاعده د ډېرو کنفیګریشن پوښتنو ځواب ورکوي مخکې له دې چې وپوښتل شي. که تنظیم په شبکه یی سټیک کې ژوند کوي، هغه د څنګ کانټینر دی. که هغه بهیر تشریح کوي، هغه د کاري بار سره پاتې کیږي.
loopback هغه برخه ده چې خلک حیرانوي. د ننوتونکي کانټینر دننه، localhost د څنګ کانټینر loopback ته حل کیږي، نه خپل شخصي یوه ته، نو هغه خدمت چې 127.0.0.1 ته تړل کیږي او جلاوالی تمه لري اوس هغه پته د تونل کانټینر سره شریکوي.
پورټونه په هغه کانټینر کې خپاره کړئ چې نوم فضا لري
د پورټ نقشه د نوم فضا مالک ده، حتی کله چې اورېدونکی بهیر په بل کانټینر کې روان وي. نقشه په څنګ کانټینر کې اعلان کړئ، او کاري بار خپله بهیر کنفیګریشن بې بدله وساتي. د ننوتونکي خدمت په نقشه باندې اثر نه شي کولی، که انجن یې رد کړي یا د کانټینر د پیلېدو پر بنسټ یې په خاموشۍ کې له پامه وغورځوي، او همدا لامل دی چې یو انټرفیس چې یوه شېبه مخکې د لاسرسي وړ و، نمونه چې تطبیق شي سمدلاسه ورک شي.
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]دا بلاک درې پرېکړې ولولئ نه درې خدمتونه. څنګ کانټینر تونل او خپور شوی پورټ لري؛ ننوتونکی کلاینټ هیڅ شبکه نه اعلانوي؛ مستقیم کلاینټ په اصلي شبکه کې خپله نقشه ساتي. وړتیا NET_ADMIN هغه څه ده چې څنګ کانټینر ته اجازه ورکوي انټرفیسونه جوړ کړي او لارې بدلې کړي، او همدا لامل دی چې دا کانټینر له هغو کاري بارونو څخه چې خدمت یې کوي ډېر امتیازات غواړي.
هغه خدمت چې مستقیم پاتې کیږي خپله شبکه ساتي
هغه کاري بار چې باید د تونل له لارې نه تېر شي اصلي پل یا خپله کاروونکي-تعریف شوې شبکه د خپل خپور شوي پورټ او خپلې خروجي سره ساتي. هڅوونکی دی چې دا د څنګ کانټینر شبکې سره ونښلوو څو دواړه کانټینرونه په نوم خبرې وکړي، خو هماغه یوه ګام د هغه ترافیک په خاموشۍ کې تونل ته لېږدوي. که دوی باید یو بل ته ورسیږي، جلا کاروونکي-تعریف شوې شبکه جوړه کړئ، دواړه ورباندې ونښلوئ، او څنګ کانټینر یوازینی بهرنی لار پرېږدئ.
دوه پوښتنې جلا وساتئ: کوم کانټینرونه یو بل ته رسېدلی شي، او کوم له کومه ځایه راوځي. د دوی یوځای کول هماغه تر ټولو عامه لاره ده چې دا ډیزاین بیا د ټول کوربه VPN ته بدل شي.
د لومړي ساعت لپاره د ناکامۍ میټریکس
ډېری لومړني هڅې د څلورو لارو په یوه ناکامه کیږي، او هر یو بېل لامل لري. دا په دې ترتیب وګورئ، ځکه لومړني دوه تقریباً هر راپور تشریح کوي.
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
څلورمه کرښه هغه ده چې خلک په غلطۍ سره د اپلیکیشن بګ په توګه تشخیص کوي. هغه ازموینه چې د کاري بار خپل loopback په وړاندې لیکل شوې وه اوس د تونل کانټینر ازمویي، نو یا ناکامه کیږي یا په بشپړه توګه غلط خدمت راپور کوي.
کله چې یو کوربه نوم تونل ته اړتیا ولري
کله ناکله بشپړ تونل ډېر وي: یو داخلي نوم باید د کارپوریټ VPN له لارې تېر شي پداسې حال کې چې یو ځایي ساکټ یا ډیسپلې اړیکه روانه وي. د کانټینر دننه بشپړ تونل هغه لار او هر هغه څه ماتوي چې کوربه ته адریس شوي، نو یوازې هغه مخکینۍ برخه ولارښوونه کړئ چې ورته اړتیا لري. د کلاینټ شاوخوا وېشل شوې لارښوونې پوښ دا کوي، نومول شوی کوربه د تونل له لارې لېږي او پخوانۍ لار د نورو ټولو لپاره بې بدله پرېږدي.
دا هغه وخت غوره کړئ چې یوازې یو خدمت ته رسېدو ته اړتیا لرئ او د کانټینر ټول ترافیک لېږدولو هڅه نه کوئ. دا د څنګ کانټینر څخه بېل وسیله ده او بېلې پوښتنې ځواب ورکوي.
تصدیق کړئ، بیا یې د بیا پیلېدو لپاره ټینګ کړئ
له هر کانټینر وپوښتئ چې له کومې پتې څخه راځي. د تونل دننه باید د برابرونکي پته چاپ کړي او مستقیم باید د کوربه خروجي. ورته ځوابونه معنا دا ده چې مستقیم خدمت غلط نوم فضا میراث واخیست یا د کوربه کچې VPN لا هم هر څه نیسي، او هغه دوه سمونې بېلې دي. د هر compose سمون وروسته ازموینه بیا چل کړئ، ځکه یو کاپي شوی خدمت بلاک د ستونزې بیرته راوستلو لپاره بس دی.
درې شیان وروسته ماتېدو ته تمایل لري. DNS د نوم فضا مالک تعقیبوي، نو د حل کوونکي او پلټنې ډومین تنظیمات باید په کوربه نه، بلکې په څنګ کانټینر کې وي. د پورټ-فارورډ VPN د بیا نښلېدو پر مهال خپل اورېدونکی پورټ بدلوي، نو د برابرونکي فارورډ شوی پورټ او د کانټینر اړخ اورېدونکی پورټ باید په کلاینټ کنفیګریشن یا پورټ نقشه کې بیرته ولیکل شي، معمولاً د یوه کوچني تازه کوونکي لخوا چې د برابرونکي API لولي. او localhost په وړاندې لیکل شوې هرې ازموینه اوس د کاري بار پرځای د تونل کانټینر څخه پوښتنه کوي.
نمونه ولیکئ، په دې کې چې کوم کانټینر نوم فضا لري او کوم پورټونه ورته اړه لري. بل کس به یو خدمت اضافه کړي، غلط بلاک کاپي کړي او د دې مقالې لومړنۍ ناکامي بیا تولید کړي.