ولې ستاسو کارپوریټ پروکسي د Compose خدمت نوم حلولو هڅه کوي
د HTTP کلاینټ کولای شي د Docker د خدمت-نوم حلولو له کارولو دمخه خپل تنظیم شوي پروکسي ته د داخلي خدمت غوښتنه واستوي. د سم کلاینټ لپاره قصدي تېرېدل اضافه کړئ.
اپلیکیشن د خپل کارپوریټ پروکسي له لارې انټرنیټ ته رسیږي، مګر http://catalog:8080/ ناکام کیږي او پروکسي نشي کولای “catalog” حل کړي. ممکن هغه غوښتنه هیڅکله د Docker داخلي DNS نه وي کارولی.
د HTTP کلاینټ کولای شي مستقیم اړیکه جوړولو دمخه خپل پروکسي غوره کړي. بیا بهرنی پروکسي هغه نوم ترلاسه کوي چې معنی یې یوازې د Compose شبکې دننه شتون لري.
- په غوښتنه کې د کوربه نوم وکاروئ. د Compose خدمتونه په مناسب شبکه کې د خدمت نوم له مخې موندل کیدای شي. د بدلیدونکي کانټینر IP د سخت کوډ کولو پرځای
catalogد کاروونکي کلاینټ د ملاتړ شوي تېرېدل تنظیماتو ته اضافه کړئ. - موجود استثناوې وساتئ. د چاپیریال څخه خبر کلاینټ لپاره، اړوندې ننوتنې د سازمان لیست سره یوځای کړئ:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogپه عکس کې اصلي کتابتون یا د اجرا وړ فایل د لویو او کوچنیو تورو سمبالښت، نسخه او د سمون ګرامر لپاره وګورئ. هیڅ نړیوال NO_PROXY شنونکی نشته. په کوچني عکس کې د wget په نوم پروګرام اړتیا نلري چې د GNU Wget په څیر چلند وکړي.
کله چې غوښتنه مستقیم لارښوونه غوره کړي، د غوښتونکي او خدمت شریکه شبکه، اورېدونکی خدمت او کانټینر پورټ وګورئ. خپور شوی کوربه پورټ بل پای ټکی دی. تېرېدل نشي کولای ورکه شبکه اړیکه اضافه کړي، لکه څنګه چې شبکه بیا جوړول نشي کولای بهرني پروکسي ته شخصي Compose نوم ور زده کړي.
په پام کې نیول شوی وېش وساتئ: داخلي غوښتنې خپله داخلي لار کاروي؛ بهرنۍ غوښتنې تصویب شوی پروکسي ساتي. پروکسي په نړیواله توګه غیر فعالول کیدای شي دا یوه ناکامي پټه کړي او په عین وخت کې د راتلونکې بهرنۍ غوښتنې لپاره اړینه لار لرې کړي.