Endring av standardpoolen til Docker omnummererer ikkje nettverk

Å endre default-address-pools omnummererer ikkje nettverka du alt har, og å vente det er nettopp korleis ein grundig plan blir eit uventa avbrot. Innstillinga styrer automatisk tildeling for nettverk som blir oppretta etter at daemonen startar på nytt med den nye konfigurasjonen. Alt som alt køyrer, held på undernettet det fekk, fordi det undernettet er ein del av den lagra definisjonen av nettverket. Myten er hendig fordi han antydar at éi endring rettar kvar overlapping, og røyndomen er eit arbeid i to delar: vel eit område som faktisk er ledig, og migrer deretter nettverka som ikkje er det.

Myten: éi poolendring rettar overlappinga

Myten har ein bestemt form. Nokon les at standardpoolen til Docker kan endrast, endrar han, startar daemonen på nytt og konkluderer med at containernettverket ikkje lenger kolliderer med VPN-et på kontoret. Det gamle nettverket er der framleis, framleis tilkopla og held framleis adressa som kolliderer.

Det som endra seg, er den framtidige åtferda til tildelaren, som er verkeleg nyttig og verkeleg avgrensa. Nye nettverk oppretta utan ein eksplisitt --subnet blir skorne ut av den nye poolen; dei eksisterande har aldri vore i den poolen. Ein omstart byggjer ikkje nettverk på nytt og flyttar ikkje containerar mellom dei. Viss symptomet held fram etter endringa, var endringa reell og diagnosen ufullstendig.

Grunnområde og tildelt prefiks

Konfigurasjonen har to felt som er lette å forveksle. base er området tildelaren skjer frå, og size er prefikslengda for kvart tildelte nettverk, så ein base på 10.10.0.0/16 med storleik 24 deler ut /24 inne i den /16. Byter ein om rollene, får ein eit tildelingsmønster ein ikkje hadde tenkt seg, vanlegvis eitt enormt nettverk eller ein uttømd pool.

Ein pool er ein reservasjon, ikkje eit prov. Docker unngår konfliktar det ser i rutetabellen til verten, og det kan ikkje sjå ein VPN du enno ikkje har kopla til.

Denne avgrensinga er heile grunnen til å velje medvite. Områda å samanlikne med er dei verten må nå: LAN-et på kontoret, dei interne undernetta til bedrifts-VPN-et, prefiksa til laben eller staging og kvar annan containervert på same overlay. Skriv dei ned som CIDR før du rører daemonen, for ei liste i hovudet vil oversjå nettopp den som betyr noko. Vel deretter ein base som ikkje overlappar nokon av dei, og oppbevar lista saman med utrullinga slik at neste person ikkje gjer øvinga om att frå minnet.

Kartlegg før du vel

Kartlegg først kva som finst. docker network ls listar nettverka, og docker network inspect bridge -f '{{.IPAM.Config}}' skriv ut undernettet eit bestemt nettverk brukar. Gjenta for kvart brukardefinert nettverk, fordi Compose-prosjekt lagar sine eigne, og ein eksplisitt --subnet i ei compose-fil omgår poolen heilt.

Det siste punktet er det som overlever migreringa. Ei poolendring hindrar ikkje ein kollega i å feste 172.18.0.0/16 i ei compose-fil, og konflikten kjem tilbake med ein annan forfattar.

Migrere det som alt finst

Migrering av eksisterande nettverk er ein separat, støtta operasjon. Kvart råka nettverk må gjerast på nytt med det nye undernettet, noko som betyr å kople frå og kople til containerane som brukar det, og å gjere eit nettverk på nytt fjernar containertilkoplingane i staden for å flytte dei. Ta vare på volum og konfigurasjon, og handsam gjenskapinga som ei utrulling, ikkje som ein datatilbakestilling. Gjer arbeidet i eit vedlikehaldsvindauge, fordi containerane på eit nettverk som er gjort på nytt startar på nytt uansett om du planla det.

Følg den dokumenterte daemonkonfigurasjonen og omstartprosedyren, og koordiner avbrotet. På ein vert med éin daemon startar systemctl restart docker containerar på nytt i samsvar med omstartspolicyane deira, og det er ei åtferd det er verdt å kjenne før i staden for etter.

Stadfest deretter dei to tinga endringa skulle rette. Undersøk det nye undernettet med docker network inspect og stadfest at det ligg innanfor den valde basen, og kontroller deretter ruta til ein representativ VPN-destinasjon med ip route get 10.20.30.40 og stadfest at ho går dit du ventar og ikkje inn i ei bru. Test òg tenesteoppdaging og kommunikasjon mellom containerar, fordi eit nettverk som er gjort på nytt med anna adressering kan øydeleggje namneoppslag på måtar som ser ut som ein programfeil.

Kva som framleis bryt saman etterpå

Den varige delen er registreringa. Oppbevar tildelingslista, den valde basen og storleiken, og nettverka som vart gjorde på nytt på same stad som utrullinga.

At eit område er privat gjer det ikkje trygt å bruke om att. 10.0.0.0/8 er privat og samstundes det mest sannsynlege som alt er i bruk ein stad på vegen, og difor er svaret ein konkret reservasjon og ikkje ei preferring for éin blokk. Nettverksdokumentasjonen til Docker skildrar automatisk undernettsildeling og poolfelta. Vel området ut frå kva du må nå, ikkje ut frå kva som ser ryddig ut.