Jou Docker-verstekpoel-verandering hernommer nie netwerke nie

Om default-address-pools te verander hernommer nie die netwerke wat jy reeds het nie, en om dit te verwag is hoe 'n noukeurige plan in 'n onverwagte onderbreking verander. Die instelling beheer outomatiese toekenning vir netwerke wat geskep word nadat die daemon met die nuwe konfigurasie herbegin het. Alles wat reeds loop, behou die subnet wat dit gekry het, want daardie subnet is deel van die netwerk se gestoorde definisie. Die mite is gerieflik omdat dit voorstel dat een wysiging elke oorvleueling oplos, en die werklikheid is 'n taak in twee dele: kies 'n reeks wat werklik vry is, en migreer dan die netwerke wat dit nie is nie.

Die mite: een poelverandering los die oorvleueling op

Die mite het 'n spesifieke vorm. Iemand lees dat Docker se verstekpoel verander kan word, verander dit, herbegin die daemon, en kom tot die gevolgtrekking dat die houernetwerk nie meer met die kantoor-VPN bots nie. Die ou netwerk is steeds daar, steeds gekoppel, en hou steeds die adres wat bots.

Wat verander het, is die toekenner se toekomstige gedrag, wat werklik nuttig en werklik beperk is. Nuwe netwerke wat sonder 'n eksplisiete --subnet geskep word, word uit die nuwe poel gesny; bestaandes was nooit in daardie poel nie. 'n Herbegin bou nie netwerke opnieuw nie en skuif nie houers tussen hulle nie. As die simptoom ná die verandering voortduur, was die verandering werklik en die diagnose onvolledig.

Basisreeks en toegekende voorvoegsel

Die konfigurasie het twee velde wat maklik verwar word. base is die reeks waaruit die toekenner sny, en size is die voorvoegsellengte van elke toegekende netwerk, dus 'n basis van 10.10.0.0/16 met grootte 24 deel /24-netwerke binne daardie /16 uit. Om die rolle om te keer lewer 'n toekenningspatroon wat jy nie bedoel het nie, gewoonlik een enorme netwerk of 'n uitgeputte poel.

'n Poel is 'n bespreking, nie 'n bewys nie. Docker vermy konflikte wat hy in die gasheer se roeteringstabel kan sien, en hy kan nie 'n VPN sien wat jy nog nie gekoppel het nie.

Daardie beperking is die hele rede om doelbewus te kies. Die reekse om mee te vergelyk is die wat die gasheer moet bereik: die kantoor-LAN, die korporatiewe VPN se interne subnette, die laboratorium- of staging-voorvoegsels, en enige ander houergasheer op dieselfde overlay. Skryf hulle as CIDR's neer voordat jy aan die daemon raak, want 'n lys in jou kop sal die een mis wat saak maak. Kies dan 'n basis wat niks daarvan oorvleuel nie, en hou die lys by die ontplooiing sodat die volgende persoon die oefening nie uit die geheue herhaal nie.

Inventariseer voordat jy kies

Inventariseer eers wat bestaan. docker network ls lys die netwerke, en docker network inspect bridge -f '{{.IPAM.Config}}' druk die subnet wat 'n spesifieke een gebruik. Herhaal dit vir elke gebruikergedefinieerde netwerk, want Compose-projekte skep hul eie en 'n eksplisiete --subnet in 'n compose-lêer omseil die poel heeltemal.

Daardie laaste punt is die een wat die migrasie oorleef. 'n Poelverandering keer nie 'n kollega daarvan om 172.18.0.0/16 in 'n compose-lêer vas te pen nie, en die konflik keer terug met 'n ander outeur.

Migreer wat reeds bestaan

Om bestaande netwerke te migreer is 'n aparte, ondersteunde bewerking. Elke geaffekteerde netwerk moet met die nuwe subnet herskep word, wat beteken die houers wat dit gebruik moet losgemaak en weer gekoppel word, en om 'n netwerk te herskep verwyder sy houeraanhegsels eerder as om hulle te skuif. Bewaar volumes en konfigurasie, en behandel die herskeping as 'n ontplooiing eerder as 'n data-herstel. Doen die werk in 'n onderhoudsvenster, want die houers op 'n herskape netwerk herbegin of jy dit beplan het of nie.

Volg die gedokumenteerde daemon-konfigurasie en herbeginprosedure, en koördineer die onderbreking. Op 'n gasheer met 'n enkele daemon herbegin systemctl restart docker houers volgens hul herbeginbeleide, wat 'n gedrag is wat die moeite werd is om voor eerder as ná te ken.

Verifieer dan die twee dinge wat die verandering moes regstel. Inspekteer die nuwe subnet met docker network inspect en bevestig dat dit binne die gekose basis sit, en kyk dan na die roete na 'n verteenwoordigende VPN-bestemming met ip route get 10.20.30.40 en bevestig dat dit gaan waar jy verwag eerder as in 'n brug in. Toets ook diensontdekking en houer-tot-houer-kommunikasie, want 'n netwerk wat met ander adressering herskep is, kan naamresolusie breek op maniere wat soos 'n toepassingsfout lyk.

Wat ná die tyd steeds breek

Die duursame deel is die rekord. Hou die toekenningslys, die gekose basis en grootte, en die netwerke wat herskep is op dieselfde plek as die ontplooiing.

Dat 'n reeks privaat is, maak dit nie veilig om te hergebruik nie. 10.0.0.0/8 is privaat en ook die mees waarskynlike ding wat reeds êrens op die pad in gebruik is, en daarom is die antwoord 'n spesifieke bespreking eerder as 'n voorkeur vir een blok. Die Docker-netwerkdokumentasie beskryf outomatiese subnettoekenning en die poelvelde. Kies die reeks uit wat jy moet bereik, nie uit wat netjies lyk nie.