ولې د پروکسي کنټينر په اتوماتيک ډول د DNS کنټينر نه کاروي
د Docker هوسټ شريکول، د شبکې شريکول او د حل کوونکي غوره کول درې جلا موضوعات دي. د DNS پوښتنه د پروکسي له دننه تعقيب کړئ.
د پروکسي او DNS سرور په يو Docker هوسټ کې چلول د دوی د DNS لارې نه نښلوي. درې جلا اړيکې مهمې دي:
- د شبکې رسېدنه. جلا Compose پروژې معمولاً جلا اصلي شبکې لري. خدمتونه په مناسبه شريکه شبکه کې ځای پرځای کړئ، که په يوه پروژه کې وي يا د پروژو ترمنځ په څرګنده توګه شريکه شبکه وي.
- د خدمت موندنه. د ځانګړي Docker شبکې دننه DNS کولی شي د کنټينر نومونه حل کړي. دا يوه اپلیکیشن ته اجازه ورکوي چې ګاونډی پيدا کړي؛ خو هغه ګاونډی په اتوماتيک ډول د خپل DNS حل کوونکي په توګه نه ټاکي.
- د حل کوونکي ټاکنه. هغه حل کوونکی وپېژنئ چې د پروکسي کنټينر دننه کارول کېږي. د Compose
dnsساحه د DNS سرور پتې اخلي. دdns.localپه څېر نوم چې په اپلیکیشن کې حل کېږي، دا د هغې ساحې لپاره سم ارزښت نه جوړوي.
پوښتنه د پروکسي کنټينر څخه تر خپل ترتيب شوي حل کوونکي پتې پورې تعقيب کړئ. تایید کړئ چې په هغې پتې کې لار او DNS اورېدونکی شته. د هوسټ پورټ 53 خپرول د هوسټ په اړخ کې د لاسرسي لار جوړوي؛ خو کنټينرو ته نه وايي چې دا وکاروي. هغه کنټينرونه چې شبکه شريکوي کولی شي په عوض کې مستقيم اړيکه وکړي.
که ترتيب د DNS کنټينر پتې ته اشاره وکړي، دا د سازګار IPAM ترتيب لاندې ثابته وساتئ. هغه پته چې په خپل سري ډول ورکړل شوې او د پرون له کنټينر څخه کاپي شوې، کېدای شي د بيا جوړولو پر مهال ناکامه شي. د حل کوونکي پورتنۍ لار هم وګورئ: بې ځوابه پوښتنې بېرته خپل ځان ته لېږل د نه رسېدونکي حل کوونکي څخه بېله ناکامي جوړوي.
په پای کې، وپېژنئ چې څوک منزل حل کوي. هغه HTTP پروکسي چې د CONNECT نوم حل کوي کولی شي دا د کنټينر لار وکاروي؛ هغه SOCKS پيرودونکی چې په سيمه کې حل کوي کېدای شي ونه کاروي. په هوسټ کې پلټنه د هوسټ لار ثابتوي، نه د پروکسي بهير لار.