Docker کا طے شدہ پول بدلنے سے نیٹ ورک دوبارہ شمار نہیں ہوتے

default-address-pools بدلنے سے آپ کے پاس پہلے سے موجود نیٹ ورک دوبارہ شمار نہیں ہوتے، اور اسی کی توقع کرنا ہی وہ طریقہ ہے جس سے ایک محتاط منصوبہ اچانک رکاوٹ میں بدل جاتا ہے۔ یہ ترتیب ڈیمون کے نئی کنفیگریشن کے ساتھ دوبارہ شروع ہونے کے بعد بننے والے نیٹ ورک کے لیے خودکار تقسیم کو کنٹرول کرتی ہے۔ پہلے سے چل رہی ہر چیز کو دیا گیا سب نیٹ برقرار رہتا ہے، کیونکہ وہ سب نیٹ نیٹ ورک کی محفوظ تعریف کا حصہ ہے۔ افسانہ سہولت بخش ہے کیونکہ یہ تجویز کرتا ہے کہ ایک ہی ترمیم ہر اوورلیپ ٹھیک کر دیتی ہے، اور حقیقت دو حصوں کا کام ہے: واقعی خالی رینج منتخب کریں، پھر وہ نیٹ ورک منتقل کریں جو خالی نہیں ہیں۔

افسانہ: پول کی ایک تبدیلی اوورلیپ ٹھیک کر دیتی ہے

افسانے کی ایک مخصوص شکل ہے۔ کوئی پڑھتا ہے کہ Docker کا طے شدہ پول بدلا جا سکتا ہے، اسے بدلتا ہے، ڈیمون دوبارہ شروع کرتا ہے اور نتیجہ نکالتا ہے کہ کنٹینر نیٹ ورک اب دفتر کے VPN سے نہیں ٹکراتا۔ پرانا نیٹ ورک اب بھی وہیں ہے، اب بھی جڑا ہوا ہے، اور ٹکرانے والا پتہ اب بھی رکھے ہوئے ہے۔

جو بدلا وہ تقسیم کرنے والے کا مستقبل کا رویہ ہے، جو واقعی مفید اور واقعی محدود ہے۔ واضح --subnet کے بغیر بنائے گئے نئے نیٹ ورک نئے پول سے کاٹے جاتے ہیں؛ موجودہ کبھی اس پول میں نہیں تھے۔ دوبارہ شروع کرنا نیٹ ورک دوبارہ نہیں بناتا اور کنٹینر ان کے درمیان منتقل نہیں کرتا۔ اگر تبدیلی کے بعد بھی علامت برقرار رہے تو تبدیلی حقیقی تھی اور تشخیص نامکمل تھی۔

بنیادی رینج اور تقسیم شدہ سابقہ

کنفیگریشن میں دو فیلڈ ہیں جنہیں آپس میں ملانا آسان ہے۔ base وہ رینج ہے جس سے تقسیم کرنے والا کاٹتا ہے، اور size ہر تقسیم شدہ نیٹ ورک کے سابقے کی لمبائی ہے، اس لیے 10.10.0.0/16 بنیاد اور 24 حجم اس /16 کے اندر /24 تقسیم کرتا ہے۔ کردار الٹنے سے ایسا تقسیمی نمونہ بنتا ہے جو آپ نہیں چاہتے تھے، عام طور پر ایک بہت بڑا نیٹ ورک یا خالی ہو چکا پول۔

پول ایک تحفظ ہے، ثبوت نہیں۔ Docker میزبان کی روٹنگ جدول میں نظر آنے والے تصادم سے بچتا ہے، اور جس VPN سے آپ ابھی جڑے نہیں اسے نہیں دیکھ سکتا۔

یہی حد جان بوجھ کر انتخاب کرنے کی پوری وجہ ہے۔ موازنے کی رینج وہ ہیں جہاں میزبان کو پہنچنا ہے: دفتر کا LAN، کارپوریٹ VPN کے اندرونی سب نیٹ، لیب یا staging کے سابقے، اور اسی overlay پر کوئی بھی دوسرا کنٹینر میزبان۔ ڈیمون کو چھونے سے پہلے انہیں CIDR کے طور پر لکھیں، کیونکہ ذہن کی فہرست ٹھیک وہی ایک چھوڑ دے گی جو اہم ہے۔ پھر ایسی بنیاد چنیں جو ان میں سے کسی سے اوورلیپ نہ ہو، اور فہرست کو تعیناتی کے ساتھ رکھیں تاکہ اگلا شخص یہ مشق یاد سے نہ دہرائے۔

چننے سے پہلے فہرست بنائیں

پہلے جو موجود ہے اس کی فہرست بنائیں۔ docker network ls نیٹ ورک کی فہرست دیتا ہے، اور docker network inspect bridge -f '{{.IPAM.Config}}' کسی خاص نیٹ ورک کا استعمال کردہ سب نیٹ چھاپتا ہے۔ صارف کی متعین کردہ ہر نیٹ ورک کے لیے یہ دہرائیں، کیونکہ Compose منصوبے اپنے بناتے ہیں اور compose فائل میں واضح --subnet پول کو مکمل طور پر نظر انداز کرتا ہے۔

وہی آخری نکتہ منتقلی کے بعد بھی زندہ رہتا ہے۔ پول کی تبدیلی کسی ساتھی کو compose فائل میں 172.18.0.0/16 پن کرنے سے نہیں روکتی، اور تصادم کسی دوسرے مصنف کے ساتھ واپس آتا ہے۔

پہلے سے موجود کی منتقلی

موجودہ نیٹ ورک کی منتقلی ایک الگ، معاون کارروائی ہے۔ متاثرہ ہر نیٹ ورک کو نئے سب نیٹ کے ساتھ دوبارہ بنانا ہوگا، یعنی اسے استعمال کرنے والے کنٹینر الگ کر کے دوبارہ جوڑنے ہوں گے، اور نیٹ ورک دوبارہ بنانے سے اس کے کنٹینر جوڑ منتقل ہونے کے بجائے ہٹ جاتے ہیں۔ والیوم اور کنفیگریشن محفوظ رکھیں اور دوبارہ بنانے کو ڈیٹا ری سیٹ نہیں بلکہ تعیناتی سمجھیں۔ کام دیکھ بھال کی ونڈو میں کریں، کیونکہ دوبارہ بنے نیٹ ورک کے کنٹینر آپ نے منصوبہ بنایا ہو یا نہ ہو، دوبارہ شروع ہوتے ہیں۔

دستاویزی ڈیمون کنفیگریشن اور دوبارہ شروع کرنے کی طریقہ کار پر عمل کریں، اور رکاوٹ کو ہم آہنگ کریں۔ ایک ڈیمون والے میزبان پر، systemctl restart docker کنٹینر کو ان کی دوبارہ شروعات کی پالیسیوں کے مطابق دوبارہ شروع کرتا ہے، اور یہ ایسا رویہ ہے جو بعد میں نہیں بلکہ پہلے جاننا چاہیے۔

پھر وہ دو چیزیں تصدیق کریں جو تبدیلی کو ٹھیک کرنی تھیں۔ docker network inspect سے نیا سب نیٹ دیکھیں اور تصدیق کریں کہ وہ منتخب بنیاد کے اندر ہے، پھر ip route get 10.20.30.40 سے کسی نمائندہ VPN منزل کا راستہ دیکھیں اور تصدیق کریں کہ وہ وہاں جاتا ہے جہاں آپ توقع کرتے ہیں، پل میں نہیں۔ سروس کی دریافت اور کنٹینر سے کنٹینر رابطہ بھی جانچیں، کیونکہ مختلف پتوں کے ساتھ دوبارہ بنا نیٹ ورک ناموں کے حل کو ایسے توڑ سکتا ہے جو ایپلیکیشن کی خرابی جیسا لگتا ہے۔

اس کے بعد بھی کیا ٹوٹتا ہے

پائیدار حصہ ریکارڈ ہے۔ تقسیم کی فہرست، منتخب بنیاد اور حجم، اور دوبارہ بنے نیٹ ورک تعیناتی کی اسی جگہ رکھیں۔

رینج کا نجی ہونا اسے دوبارہ استعمال کے لیے محفوظ نہیں بناتا۔ 10.0.0.0/8 نجی ہے اور ساتھ ہی راستے میں کہیں پہلے سے استعمال میں ہونے کا سب سے زیادہ امکان رکھتا ہے، اسی لیے جواب ایک مخصوص تحفظ ہے، کسی ایک بلاک کی ترجیح نہیں۔ Docker نیٹ ورک دستاویز خودکار سب نیٹ تقسیم اور پول کے فیلڈ بیان کرتی ہے۔ رینج اس بنیاد پر چنیں کہ آپ کو کہاں پہنچنا ہے، اس بنیاد پر نہیں کہ وہ صاف ستھری لگتی ہے۔