Промяната на стандартния пул на Docker не преномерира мрежите
Промяната на default-address-pools управлява само новите автоматични мрежи. Направете опис на диапазоните, които вече използвате, и после планирайте миграцията на това, което вече работи.
Промяната на default-address-pools не преномерира мрежите, които вече имате, и точно това очакване превръща внимателния план в неочакван престой. Настройката управлява автоматичното разпределяне за мрежи, създадени след рестартирането на демона с новата конфигурация. Всичко, което вече работи, запазва дадената му подмрежа, защото тази подмрежа е част от запазеното определение на мрежата. Митичното е удобно, защото подсказва, че една промяна поправя всяко застъпване, а реалността е работа в две части: изберете диапазон, който наистина е свободен, и после мигрирайте мрежите, които не са.
Митичното: една промяна на пула поправя застъпването
Митичното има конкретна форма. Някой прочита, че пулът по подразбиране на Docker може да се промени, променя го, рестартира демона и заключава, че контейнерната мрежа вече не се сблъсква с офис VPN. Старата мрежа все още е там, все още е свързана и все още държи адреса, който се сблъсква.
Променило се е бъдещото поведение на разпределителя, което е наистина полезно и наистина ограничено. Новите мрежи, създадени без явен --subnet, се изрязват от новия пул; съществуващите никога не са били в този пул. Рестартирането не преизгражда мрежи и не мести контейнери между тях. Ако симптомът остане след промяната, промяната е била истинска, а диагнозата — непълна.
Базов диапазон и разпределен префикс
Конфигурацията има две полета, които лесно се бъркат. base е диапазонът, от който разпределителят изрязва, а size е дължината на префикса на всяка разпределена мрежа, така че база 10.10.0.0/16 с размер 24 раздава /24 в рамките на този /16. Обърнатите роли дават схема на разпределение, която не сте искали, обикновено една огромна мрежа или изчерпан пул.
Пулът е резервация, не доказателство. Docker избягва конфликтите, които вижда в маршрутната таблица на хоста, и не може да види VPN, към който още не сте се свързали.
Това ограничение е цялата причина да избирате съзнателно. Диапазоните за сравнение са тези, до които хостът трябва да достига: офис LAN, вътрешните подмрежи на корпоративния 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 описва автоматичното разпределяне на подмрежи и полетата на пула. Избирайте диапазона от това, до което трябва да достигате, а не от това, което изглежда подредено.