Менувањето на стандардниот базен на 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 го опишува автоматското доделување подмрежи и полињата на базенот. Изберете го опсегот според тоа до што мора да стигнете, а не според тоа што изгледа уредно.