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 سروس کا اپنا پتہ کیوں نہیں۔