Зміна пулу 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 описує автоматичне виділення підмереж і поля пулу. Виберіть діапазон за тим, до чого вам треба дотягнутися, а не за тим, що виглядає охайно.