network_mode: service:vpn او ورک شوی db کوربه‌نوم

تاسو اپلیکیشن ته network_mode: service:vpn ورزیاتوئ، سټک بیا پیلوئ، او اپلیکیشن مري ځکه چې db نور نه حل کیږي۔ په compose فایل کې هیڅ نوم نه دی بدل شوی، نو ښکاره شکمن DNS او ډیټابیس دي۔ ریښتینی بدلون کوچنی او عجیب دی: اپلیکیشن د هغې Compose شبکې غړیتوب پرېښود چې دا نوم پکې شته۔ تر هغه چې تاسو پریکړه ونه کړئ چې ډیټابیس باید د کوم نومونو ځای څخه ځواب ورکړي، هر کوربه‌نوم سمون یو اټکل دی۔

ولې db کوربه‌نوم حلیدل بند شول

هغه خدمت چې network_mode کاروي په Compose شبکه کې خپله پته نه لري؛ دا د نامه‌شوي خدمت د نومونو ځای په قرض اخلي۔ هغه ځای خپل انټرفیسونه، لارې، د پورټ ځای او حل کوونکی راوړي، او د اپلیکیشن هغه تړاو بدلوي چې له backend شبکې سره لري۔ db نوم هیڅکله انتزاعي نه و: دا په هماغه شبکه کې ژوند کاوه او د هغې د داخلي DNS له لارې حلیده۔ تړاو لرې کړئ او نوم به هېڅ ځای ونلري چې حل شي۔

دا له کوربه څخه نه، بلکې د کانټینرونو له داخله تایید کړئ۔ هغه پلټنه چې په اپلیکیشن کې ناکامه خو په ډیټابیس کانټینر کې بریالۍ وي، مانا دا ده چې نوم سم دی او غړیتوب نه۔ هغه پایله سمون په اپلیکیشن د حل کوونکي په تنظیماتو کې نه، بلکې په compose ټوپولوژۍ کې ځای پرځای کوي۔

د فایل له سمولو مخکې درې پوښتنې

دوی ته په ترتیب ځواب ورکړئ، ځکه هر یو ټوپولوژي تنګوي۔ ډیټابیس باید په څه ځواب ووايي: په هغه کوربه‌نوم چې نور کانټینرونه یې کاروي، یا یوازې په loopback کې اپلیکیشن ته؟ ایا اپلیکیشن باید کوربه ته پورټ خپور کړي، او کوم خدمت به یې مالک وي؟ ایا ډیټابیس باید له کوربه یا بل ماشین څخه د لاسرسي وړ وي، یا یوازې د تونل له داخله؟

که ډیټابیس خپل نوم ته اړتیا لري او اپلیکیشن هیڅ نه خپروي، دوی په جلا تړاوونو کې وساتئ۔ که اپلیکیشن باید پورټ خپور کړي او هر څه د تونل له لارې ځي، ډیټابیس په VPN نومونو ځای کې کېږدئ او loopback وکاروئ۔ دواړه یوځای کول هغه سټک جوړوي چې پاک پیل کیږي او د نښلولو پر مهال ناکام کیږي۔

ډیټابیس چېرې چې دی هماغلته پرېږدئ

کوچنی بدلون د نومونو ځای مالک هغې شبکې ته تړي چې دمخه ډیټابیس پکې دی۔ اپلیکیشن هغه تړاو په میراث اخلي ځکه چې vpn سټک شریکوي، او db سم لکه مخکې حل کیږي۔

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

اپلیکیشن ته networks هم مه ورزیاتوئ۔ Compose په هماغه خدمت کې دا ځانګړنه د network_mode ترڅنګ ردوي، او تېروتنه جوړې ته نه، بلکې فایل ته اشاره کوي۔ که VPN کلاینټ د خپل نومونو ځای دننه backend منزل فلټر کړي، د هغې ملاتړ شوې سیمه‌ای شبکه‌پالنه هم تنظیم کړئ؛ شریک تړاو لار وړاندې کوي خو هغه فلټر نه لغوه کوي۔

ډیټابیس نومونو ځای ته یوسئ

لوی بدلون ډیټابیس په هماغه نومونو ځای کې ځای پرځای کوي او اپلیکیشن د ریښتیني پورټ سره 127.0.0.1 ته اشاره کوي۔ دوه بهیرونه نشي کولی یوازې دې لپاره چې په جلا کانټینرونو کې پیل شوي، یوه پته او پورټ دواړه وتړي، نو هغه ډیټابیس چې په wildcard پته هم اوري به له هر هغه څه سره ټکر وکړي چې داسې کوي۔ له کېدو مخکې اورېدونکی وګورئ۔

خپاره شوي پورټونه د هغه خدمت دي چې نومونو ځای لري۔ اپلیکیشن ته ports ورزیاتول د network_mode ترڅنګ رد کیږي، او جلا اپلیکیشن پته جوړول هغه انټرفیس بیانوي چې شتون نه لري۔

چمتووالی، بندول او حل کوونکی

depends_on د کانټینرونو پیل ترتیبوي؛ دا د تونل د فعالیدو ثبوت نه دی او کله چې تونل ولوېږي ترافیک نه بندوي۔ لاسرسی، د تونل چمتووالی او د ناکامیو بندول درې جلا اړتیاوې وګڼئ۔ هغه سټک چې یوازې لومړی پوره کوي په ښه ورځ لاسي ازموینه بریالي کوي او په بدې ورځ تویږي۔ درې ځوابونه د compose فایل ترڅنګ ولیکئ، چېرې چې بل کس به وګوري۔

د نومونو ځای شریکول دا هم مانا لري چې اپلیکیشن د VPN کانټینر حل کوونکی په میراث اخلي, کوم چې کله تونل DNS سرورونه ټینګ کړي مرسته کوي او کله یې نه ټینګ کړي ګډوډوي۔ د دې پرځای چې فکر وکړئ د کوربه حل کوونکی پلی کیږي، وګورئ چې په نومونو ځای کې واقعاً څه دي۔ د Compose خدمتونو مرجع په یو ځای کې network_mode, ports او د تړاوونو چلند مستند کوي، په شمول د دې چې ولې network_mode خدمت خپله پته نه لري۔