تغییر استخر پیش‌فرض Docker شبکه‌ها را دوباره شماره‌گذاری نمی‌کند

تغییر default-address-pools شبکه‌هایی را که از قبل دارید دوباره شماره‌گذاری نمی‌کند، و انتظار این کار همان چیزی است که یک برنامه دقیق را به قطعی ناگهانی تبدیل می‌کند. این تنظیم تخصیص خودکار را برای شبکه‌هایی کنترل می‌کند که پس از راه‌اندازی مجدد دیمن با پیکربندی جدید ساخته می‌شوند. هر چیزی که از قبل در حال اجراست زیرشبکه‌ای را که به آن داده شده حفظ می‌کند، چون آن زیرشبکه بخشی از تعریف ذخیره‌شده شبکه است. افسانه راحت است چون پیشنهاد می‌کند یک ویرایش هر همپوشانی را درست می‌کند، و واقعیت کاری دو بخشی است: محدوده‌ای را انتخاب کنید که واقعاً آزاد است، سپس شبکه‌هایی را که آزاد نیستند مهاجرت دهید.

افسانه: یک تغییر استخر همپوشانی را درست می‌کند

افسانه شکل مشخصی دارد. کسی می‌خواند که استخر پیش‌فرض Docker را می‌توان تغییر داد، تغییرش می‌دهد، دیمن را دوباره راه‌اندازی می‌کند و نتیجه می‌گیرد که شبکه کانتینر دیگر با VPN دفتر تداخل ندارد. شبکه قدیمی هنوز آنجاست، هنوز متصل است و هنوز آدرسی را نگه داشته که تداخل دارد.

آنچه تغییر کرده رفتار آینده تخصیص‌دهنده است، که واقعاً مفید و واقعاً محدود است. شبکه‌های جدیدی که بدون --subnet صریح ساخته می‌شوند از استخر جدید بریده می‌شوند؛ شبکه‌های موجود هرگز در آن استخر نبوده‌اند. راه‌اندازی مجدد شبکه‌ها را بازنمی‌سازد و کانتینرها را بین آن‌ها جابه‌جا نمی‌کند. اگر نشانه پس از تغییر ادامه یابد، تغییر واقعی بوده و تشخیص ناقص بوده است.

محدوده پایه و پیشوند تخصیص‌یافته

پیکربندی دو فیلد دارد که اشتباه گرفتنشان آسان است. base محدوده‌ای است که تخصیص‌دهنده از آن می‌برد، و size طول پیشوند هر شبکه تخصیص‌یافته است، پس پایه 10.10.0.0/16 با اندازه 24 شبکه‌های /24 را داخل آن /16 پخش می‌کند. جابه‌جا کردن نقش‌ها الگویی از تخصیص می‌سازد که قصدش را نداشتید، معمولاً یک شبکه عظیم یا استخری تهی‌شده.

استخر یک رزرو است، نه اثبات. Docker از تداخل‌هایی که در جدول مسیریابی میزبان می‌بیند دوری می‌کند و نمی‌تواند VPN‌ای را که هنوز به آن وصل نشده‌اید ببیند.

این محدودیت تمام دلیل انتخاب آگاهانه است. محدوده‌هایی که باید با آن‌ها مقایسه شوند همان‌هایی هستند که میزبان باید به آن‌ها برسد: LAN دفتر، زیرشبکه‌های داخلی VPN سازمانی، پیشوندهای آزمایشگاه یا staging و هر میزبان کانتینر دیگر روی همان overlay. آن‌ها را پیش از دست زدن به دیمن به‌صورت 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 تخصیص خودکار زیرشبکه و فیلدهای استخر را توصیف می‌کند. محدوده را بر اساس آنچه باید به آن برسید انتخاب کنید، نه بر اساس آنچه مرتب به نظر می‌رسد.