Ændring af Dockers standardpulje omnummererer ikke netværk

Ændring af default-address-pools omnummererer ikke de netværk, du allerede har, og at forvente det er netop, hvordan en omhyggelig plan bliver til et uventet afbrud. Indstillingen styrer automatisk tildeling for netværk, der oprettes, efter at daemonen genstarter med den nye konfiguration. Alt, der allerede kører, beholder det undernet, det fik, fordi det undernet er en del af netværkets gemte definition. Myten er bekvem, fordi den antyder, at én rettelse løser enhver overlapning, og virkeligheden er et arbejde i to dele: vælg et interval, der faktisk er frit, og migrer derefter de netværk, der ikke er.

Myten: én ændring af puljen løser overlapningen

Myten har en bestemt form. Nogen læser, at Dockers standardpulje kan ændres, ændrer den, genstarter daemonen og konkluderer, at containernetværket ikke længere støder sammen med kontorets VPN. Det gamle netværk er der stadig, stadig tilsluttet og holder stadig den adresse, der støder sammen.

Det, der ændrede sig, er tildelerens fremtidige adfærd, som er virkelig nyttig og virkelig begrænset. Nye netværk oprettet uden en eksplicit --subnet skæres ud af den nye pulje; de eksisterende har aldrig været i den pulje. En genstart genopbygger ikke netværk og flytter ikke containere mellem dem. Hvis symptomet fortsætter efter ændringen, var ændringen reel, og diagnosen var ufuldstændig.

Basisinterval og tildelt præfiks

Konfigurationen har to felter, der er lette at forveksle. base er det interval, tildeleren skærer fra, og size er præfikslængden for hvert tildelt netværk, så en base på 10.10.0.0/16 med størrelse 24 uddeler /24 inde i det /16. Bytter man rollerne om, får man et tildelingsmønster, man ikke havde tænkt sig, normalt et enkelt kæmpenetværk eller en udtømt pulje.

En pulje er en reservation, ikke et bevis. Docker undgår konflikter, som den kan se i værtens routingtabel, og den kan ikke se en VPN, du endnu ikke har tilsluttet.

Denne begrænsning er hele grunden til at vælge bevidst. De intervaller, der skal sammenlignes med, er dem, som værten skal kunne nå: kontorets LAN, den interne VPN's undernet, laboratoriets eller stagingens præfikser og enhver anden containerhost på samme overlay. Skriv dem ned som CIDR, før du rører daemonen, for en liste i hovedet vil overse netop det, der betyder noget. Vælg derefter en base, der ikke overlapper nogen af dem, og opbevar listen sammen med udrulningen, så den næste person ikke gentager øvelsen fra hukommelsen.

Kortlæg, før du vælger

Kortlæg først, hvad der findes. docker network ls viser netværkene, og docker network inspect bridge -f '{{.IPAM.Config}}' udskriver det undernet, et bestemt netværk bruger. Gentag for hvert brugerdefineret netværk, fordi Compose-projekter opretter deres egne, og en eksplicit --subnet i en compose-fil omgår puljen helt.

Den sidste pointe er den, der overlever migreringen. En ændring af puljen forhindrer ikke en kollega i at fastlåse 172.18.0.0/16 i en compose-fil, og konflikten vender tilbage med en anden forfatter.

Migrering af det, der allerede findes

Migrering af eksisterende netværk er en separat, understøttet operation. Hvert berørt netværk skal genskabes med det nye undernet, hvilket betyder at afkoble og gentilslutte de containere, der bruger det, og genskabelse af et netværk fjerner dets containertilknytninger i stedet for at flytte dem. Bevar volumener og konfiguration, og behandl genskabelsen som en udrulning i stedet for en datanulstilling. Udfør arbejdet i et vedligeholdelsesvindue, fordi containerne på et genskabt netværk genstarter, uanset om du havde planlagt det.

Følg den dokumenterede daemonkonfiguration og genstartsprocedure, og koordiner afbrydelsen. På en vært med én daemon genstarter systemctl restart docker containere efter deres genstartsregler, og det er en adfærd, det er værd at kende før i stedet for efter.

Bekræft derefter de to ting, som ændringen skulle rette. Undersøg det nye undernet med docker network inspect, og bekræft, at det ligger inden for den valgte base, og kontroller derefter ruten til en repræsentativ VPN-destination med ip route get 10.20.30.40 og bekræft, at den går, hvor du forventer, og ikke ind i en bro. Test også tjenesteopdagelse og kommunikation mellem containere, fordi et netværk, der er genskabt med en anden adressering, kan ødelægge navneopløsning på måder, der ligner en programfejl.

Hvad der stadig bryder sammen bagefter

Den holdbare del er registreringen. Opbevar tildelingslisten, den valgte base og størrelse og de genskabte netværk samme sted som udrulningen.

At et interval er privat gør det ikke sikkert at genbruge. 10.0.0.0/8 er privat og samtidig det mest sandsynlige, der allerede er i brug et sted på ruten, og derfor er svaret en konkret reservation i stedet for en forkærlighed for én blok. Dockers netværksdokumentation beskriver automatisk undernetstildeling og puljefelterne. Vælg intervallet ud fra, hvad du skal kunne nå, ikke ud fra hvad der ser pænt ud.