Endring av Dockers standardpool omnummererer ikke nettverk

Å endre default-address-pools omnummererer ikke nettverkene du allerede har, og å forvente det er nettopp hvordan en grundig plan blir et uventet avbrudd. Innstillingen styrer automatisk tildeling for nettverk som opprettes etter at daemonen starter på nytt med den nye konfigurasjonen. Alt som allerede kjører, beholder undernettet det fikk, fordi det undernettet er en del av nettverkets lagrede definisjon. Myten er bekvem fordi den antyder at én endring retter hver overlapp, og virkeligheten er et arbeid i to deler: velg et område som faktisk er ledig, og migrer deretter nettverkene som ikke er det.

Myten: én poolendring retter overlappen

Myten har en bestemt form. Noen leser at Dockers standardpool kan endres, endrer den, starter daemonen på nytt og konkluderer med at containernettverket ikke lenger kolliderer med kontorets VPN. Det gamle nettverket er der fortsatt, fortsatt tilkoblet og holder fortsatt adressen som kolliderer.

Det som endret seg, er tildelerens fremtidige oppførsel, som er virkelig nyttig og virkelig begrenset. Nye nettverk opprettet uten en eksplisitt --subnet skjæres ut av den nye poolen; de eksisterende har aldri vært i den poolen. En omstart bygger ikke nettverk på nytt og flytter ikke containere mellom dem. Hvis symptomet vedvarer etter endringen, var endringen reell og diagnosen ufullstendig.

Basisområde og tildelt prefiks

Konfigurasjonen har to felt som er lette å forveksle. base er området tildeleren skjærer fra, og size er prefikslengden for hvert tildelte nettverk, så en base på 10.10.0.0/16 med størrelse 24 deler ut /24 inne i det /16. Bytter man om rollene, får man et tildelingsmønster man ikke hadde tenkt seg, vanligvis ett enormt nettverk eller en uttømt pool.

En pool er en reservasjon, ikke et bevis. Docker unngår konflikter det ser i vertens rutetabell, og det kan ikke se en VPN du ennå ikke har koblet til.

Denne begrensningen er hele grunnen til å velge bevisst. Områdene å sammenligne med er de verten må nå: kontorets LAN, de interne undernettene til bedrifts-VPN-et, prefiksene til laben eller staging og enhver annen containervert på samme overlay. Skriv dem ned som CIDR før du rører daemonen, for en liste i hodet vil overse nettopp den som betyr noe. Velg deretter en base som ikke overlapper noen av dem, og oppbevar listen sammen med utrullingen slik at neste person ikke gjentar øvelsen fra hukommelsen.

Kartlegg før du velger

Kartlegg først hva som finnes. docker network ls lister nettverkene, og docker network inspect bridge -f '{{.IPAM.Config}}' skriver ut undernettet et bestemt nettverk bruker. Gjenta for hvert brukerdefinerte nettverk, fordi Compose-prosjekter lager sine egne, og en eksplisitt --subnet i en compose-fil omgår poolen helt.

Det siste punktet er det som overlever migreringen. En poolendring hindrer ikke en kollega i å feste 172.18.0.0/16 i en compose-fil, og konflikten kommer tilbake med en annen forfatter.

Migrere det som allerede finnes

Migrering av eksisterende nettverk er en separat, støttet operasjon. Hvert berørte nettverk må gjenskapes med det nye undernettet, noe som betyr å koble fra og tilkoble containerne som bruker det, og gjenskaping av et nettverk fjerner containertilkoblingene i stedet for å flytte dem. Bevar volumer og konfigurasjon, og behandle gjenskaping som en utrulling, ikke en tilbakestilling av data. Gjør arbeidet i et vedlikeholdsvindu, fordi containerne på et gjenskapt nettverk starter på nytt uansett om du planla det.

Følg den dokumenterte daemonkonfigurasjonen og omstartprosedyren, og koordiner avbruddet. På en vert med én daemon starter systemctl restart docker containere på nytt i henhold til deres omstartspolicyer, og det er en oppførsel det er verdt å kjenne før i stedet for etter.

Bekreft deretter de to tingene endringen skulle rette. Undersøk det nye undernettet med docker network inspect og bekreft at det ligger innenfor den valgte basen, og kontroller deretter ruten til en representativ VPN-destinasjon med ip route get 10.20.30.40 og bekreft at den går dit du forventer og ikke inn i en bro. Test også tjenesteoppdagelse og kommunikasjon mellom containere, fordi et nettverk som er gjenskapt med annen adressering kan ødelegge navneoppslag på måter som ser ut som en programfeil.

Hva som fortsatt bryter sammen etterpå

Den varige delen er registreringen. Oppbevar tildelingslisten, den valgte basen og størrelsen, og nettverkene som ble gjenskapt på samme sted som utrullingen.

At et område er privat gjør det ikke trygt å gjenbruke. 10.0.0.0/8 er privat og samtidig det mest sannsynlige som allerede er i bruk et sted på veien, og derfor er svaret en konkret reservasjon og ikke en preferanse for én blokk. Dockers nettverksdokumentasjon beskriver automatisk undernettsildeling og poolfeltene. Velg området ut fra hva du må nå, ikke ut fra hva som ser ryddig ut.