Ändring av Dockers standardpool numrerar inte om nätverk

Att ändra default-address-pools numrerar inte om nätverken du redan har, och att förvänta sig det är precis hur en noggrann plan blir ett oväntat avbrott. Inställningen styr automatisk tilldelning för nätverk som skapas efter att daemonen startar om med den nya konfigurationen. Allt som redan körs behåller det subnät det fick, eftersom det subnätet är en del av nätverkets lagrade definition. Myten är bekväm eftersom den antyder att en enda ändring åtgärdar varje överlappning, och verkligheten är ett arbete i två delar: välj ett intervall som verkligen är ledigt och migrera sedan de nätverk som inte är det.

Myten: en pooländring åtgärdar överlappningen

Myten har en bestämd form. Någon läser att Dockers standardpool kan ändras, ändrar den, startar om daemonen och drar slutsatsen att containernätverket inte längre krockar med kontorets VPN. Det gamla nätverket finns kvar, är fortfarande anslutet och håller fortfarande adressen som krockar.

Det som ändrades är tilldelarens framtida beteende, vilket är verkligen användbart och verkligen begränsat. Nya nätverk som skapas utan en uttrycklig --subnet skärs ut ur den nya poolen; de befintliga har aldrig varit i den poolen. En omstart bygger inte om nätverk och flyttar inte containrar mellan dem. Om symptomet kvarstår efter ändringen var ändringen verklig och diagnosen ofullständig.

Basintervall och tilldelat prefix

Konfigurationen har två fält som är lätta att förväxla. base är intervallet som tilldelaren skär ur, och size är prefixlängden för varje tilldelat nätverk, så en bas på 10.10.0.0/16 med storlek 24 delar ut /24 inom det /16. Om rollerna byts får man ett tilldelningsmönster man inte avsåg, vanligtvis ett enda enormt nätverk eller en uttömd pool.

En pool är en reservation, inte ett bevis. Docker undviker konflikter som det ser i värdens routingtabell och kan inte se ett VPN som du ännu inte har anslutit till.

Den begränsningen är hela skälet att välja medvetet. Intervallen att jämföra med är de som värden måste nå: kontorets LAN, de interna subnäten i företagets VPN, prefixen för labbet eller staging och varje annan containerhost på samma overlay. Skriv ner dem som CIDR innan du rör daemonen, för en lista i huvudet missar just den som spelar roll. Välj sedan en bas som inte överlappar någon av dem, och förvara listan tillsammans med utrullningen så att nästa person inte upprepar övningen ur minnet.

Inventera innan du väljer

Inventera först vad som finns. docker network ls listar nätverken, och docker network inspect bridge -f '{{.IPAM.Config}}' skriver ut det subnät som ett visst nätverk använder. Upprepa för varje användardefinierat nätverk, eftersom Compose-projekt skapar sina egna och en uttrycklig --subnet i en compose-fil kringgår poolen helt.

Den sista punkten är den som överlever migreringen. En pooländring hindrar inte en kollega från att fästa 172.18.0.0/16 i en compose-fil, och konflikten återkommer med en annan författare.

Migrera det som redan finns

Migrering av befintliga nätverk är en separat, stödd operation. Varje berört nätverk måste återskapas med det nya subnätet, vilket innebär att koppla bort och återansluta containrarna som använder det, och att återskapa ett nätverk tar bort dess containerkopplingar i stället för att flytta dem. Bevara volymer och konfiguration och behandla återskapandet som en utrullning, inte som en dataåterställning. Gör arbetet i ett underhållsfönster, eftersom containrarna på ett återskapat nätverk startar om vare sig du planerade det eller inte.

Följ den dokumenterade daemonkonfigurationen och omstartsproceduren och samordna avbrottet. På en värd med en enda daemon startar systemctl restart docker om containrar enligt deras omstartspolicyer, och det är ett beteende som är värt att känna till före i stället för efter.

Verifiera sedan de två sakerna som ändringen skulle åtgärda. Inspektera det nya subnätet med docker network inspect och bekräfta att det ligger inom den valda basen, kontrollera sedan rutten till en representativ VPN-destination med ip route get 10.20.30.40 och bekräfta att den går dit du förväntar dig och inte in i en bro. Testa också tjänsteupptäckt och kommunikation mellan containrar, eftersom ett nätverk som återskapats med annan adressering kan bryta namnmatchningen på sätt som ser ut som ett programfel.

Vad som fortfarande går sönder efteråt

Den varaktiga delen är registreringen. Förvara tilldelningslistan, den valda basen och storleken samt de återskapade nätverken på samma plats som utrullningen.

Att ett intervall är privat gör det inte säkert att återanvända. 10.0.0.0/8 är privat och samtidigt det mest sannolika som redan används någonstans på vägen, därför är svaret en konkret reservation och inte en preferens för ett block. Dockers nätverksdokumentation beskriver automatisk subnätstilldelning och poolfälten. Välj intervallet utifrån vad du måste nå, inte utifrån vad som ser städat ut.