تغيير مجمّع Docker الافتراضي لا يعيد ترقيم الشبكات

تغيير default-address-pools لا يعيد ترقيم الشبكات الموجودة لديك بالفعل، وتوقّع ذلك هو ما يحوّل خطة حريصة إلى انقطاع مفاجئ. الإعداد يحكم التخصيص التلقائي للشبكات التي تُنشأ بعد إعادة تشغيل الخدمة بالإعداد الجديد. كل ما يعمل بالفعل يحتفظ بالشبكة الفرعية التي أُعطيت له، لأن تلك الشبكة الفرعية جزء من تعريف الشبكة المخزَّن. الأسطورة مريحة لأنها توحي بأن تعديلاً واحداً يصلح كل تداخل، والواقع وظيفة من جزأين: اختر نطاقاً حراً فعلاً، ثم اهجر الشبكات التي ليست كذلك.

الأسطورة: تغيير واحد للمجمّع يصلح التداخل

للأسطورة شكل محدد. يقرأ أحدهم أن مجمّع Docker الافتراضي يمكن تغييره، فيغيّره ويعيد تشغيل الخدمة، ثم يستنتج أن شبكة الحاويات لم تعد تتصادم مع شبكة VPN المكتب. الشبكة القديمة لا تزال موجودة، وما زالت موصولة، وما زالت تحمل العنوان المتصادم.

ما تغيّر هو سلوك المخصِّص في المستقبل، وهو مفيد حقاً ومحدود حقاً. الشبكات الجديدة التي تُنشأ دون --subnet صريح تُقتطع من المجمّع الجديد؛ أما القائمة فلم تكن في ذلك المجمّع أصلاً. إعادة التشغيل لا تعيد بناء الشبكات ولا تنقل الحاويات بينها. إذا استمرت الأعراض بعد التغيير، فالتغيير كان حقيقياً والتشخيص كان ناقصاً.

النطاق الأساسي والبادئة المخصصة

في الإعداد حقلان يسهل الخلط بينهما. base هو النطاق الذي يقتطع منه المخصِّص، و size هو طول البادئة لكل شبكة مخصصة، لذا يوزّع أساس 10.10.0.0/16 بحجم 24 شبكات /24 داخل ذلك /16. عكس الأدوار ينتج نمط تخصيص لم تقصده، عادةً شبكة واحدة ضخمة أو مجمّع مستنفد.

المجمّع حجز، لا برهان. يتجنب Docker التعارضات التي يراها في جدول التوجيه للمضيف، ولا يمكنه رؤية شبكة VPN لم تتصل بها بعد.

هذا القيد هو السبب الكامل للاختيار المتعمد. النطاقات التي تُقارن بها هي التي يجب أن يصل إليها المضيف: شبكة المكتب المحلية، والشبكات الفرعية الداخلية لشبكة VPN المؤسسية، وبادئات المختبر أو الاختبار، وأي مضيف حاويات آخر على نفس الطبقة التراكبية. اكتبها كعناوين CIDR قبل أن تلمس الخدمة، لأن قائمة في رأسك ستغفل التي تهم. ثم اختر أساساً لا يتداخل مع أي منها، واحفظ القائمة مع النشر حتى لا يعيد الشخص التالي التمرين من الذاكرة.

احصر قبل أن تختار

احصر ما هو موجود أولاً. docker network ls يسرد الشبكات، و docker network inspect bridge -f '{{.IPAM.Config}}' يطبع الشبكة الفرعية التي تستخدمها شبكة معينة. كرّر ذلك لكل شبكة يعرّفها المستخدم، لأن مشاريع Compose تنشئ شبكاتها، و --subnet الصريح في ملف compose يتجاوز المجمّع تماماً.

تلك النقطة الأخيرة هي التي تنجو من الهجرة. تغيير المجمّع لا يمنع زميلاً من تثبيت 172.18.0.0/16 في ملف compose، ويعود التعارض بكاتب مختلف.

هجرة ما هو موجود بالفعل

هجرة الشبكات القائمة عملية منفصلة ومدعومة. يجب إعادة إنشاء كل شبكة متأثرة بالشبكة الفرعية الجديدة، وهذا يعني فصل الحاويات التي تستخدمها وإعادة وصلها، وإعادة إنشاء شبكة تزيل ارتباطات الحاويات بها بدلاً من نقلها. حافظ على الأحجام والإعداد، وتعامل مع إعادة الإنشاء كنشر لا كإعادة ضبط للبيانات. أنجز العمل في نافذة صيانة، لأن الحاويات على شبكة أُعيد إنشاؤها تعيد التشغيل سواء خططت لذلك أم لا.

اتبع إعداد الخدمة وإجراء إعادة التشغيل الموثّقين، ونسّق الانقطاع. على مضيف بخدمة واحدة، يعيد systemctl restart docker تشغيل الحاويات وفق سياسات إعادة التشغيل الخاصة بها، وهو سلوك يستحق المعرفة قبل لا بعد.

ثم تحقق من الأمرين اللذين كان التغيير يفترض أن يصلحهما. افحص الشبكة الفرعية الجديدة بـ docker network inspect وأكّد أنها داخل الأساس المختار، ثم افحص المسار إلى وجهة VPN تمثيلية بـ ip route get 10.20.30.40 و أكّد أنه يذهب حيث تتوقع لا إلى جسر. اختبر اكتشاف الخدمات والتواصل بين الحاويات أيضاً، لأن شبكة أُعيد إنشاؤها بعنونة مختلفة قد تكسر تحليل الأسماء بطرق تبدو كخطأ في التطبيق.

ما يظل معطلاً بعد ذلك

الجزء الدائم هو السجل. احفظ قائمة التخصيص، والأساس والحجم المختارين، والشبكات التي أُعيد إنشاؤها في المكان نفسه الذي فيه النشر.

كون النطاق خاصاً لا يجعله آمناً لإعادة الاستخدام. 10.0.0.0/8 خاص وأيضاً الشيء الأكثر احتمالاً أن يكون مستخدماً بالفعل في مكان ما على المسار، ولهذا فالجواب حجز محدد لا تفضيل لكتلة واحدة. توثيق شبكات Docker يصف التخصيص التلقائي للشبكات الفرعية وحقول المجمّع. اختر النطاق مما يجب أن تصل إليه، لا مما يبدو مرتباً.