Canviar el pool predeterminat del Docker no renumera les xarxes

Canviar default-address-pools no renumera les xarxes que ja teniu, i esperar-ho és com un pla acurat es converteix en una caiguda inesperada. El paràmetre governa l'assignació automàtica de les xarxes creades després que el dimoni es reiniciï amb la configuració nova. Tot el que ja funciona conserva la subxarxa que se li va assignar, perquè aquesta subxarxa forma part de la definició desada de la xarxa. El mite és còmode perquè suggereix que una sola edició arregla cada solapament, i la realitat és una feina en dues parts: trieu un rang que sigui realment lliure i, després, migreu les xarxes que no ho són.

El mite: un sol canvi de pool arregla el solapament

El mite té una forma concreta. Algú llegeix que el pool predeterminat del Docker es pot canviar, el canvia, reinicia el dimoni i conclou que la xarxa de contenidors ja no xoca amb la VPN de l'oficina. La xarxa antiga encara hi és, encara està connectada i encara té l'adreça que xoca.

El que ha canviat és el comportament futur de l'assignador, que és realment útil i realment limitat. Les xarxes noves creades sense un --subnet explícit es retallen del pool nou; les existents mai no havien estat en aquest pool. Reiniciar no reconstrueix xarxes ni mou contenidors entre elles. Si el símptoma continua després del canvi, el canvi era real i el diagnòstic era incomplet.

Rang base i prefix assignat

La configuració té dos camps que és fàcil confondre. base és el rang del qual retalla l'assignador, i size és la longitud del prefix de cada xarxa assignada, de manera que una base 10.10.0.0/16 amb mida 24 reparteix /24 dins d'aquest /16. Si invertiu els papers obteniu un patró d'assignació que no volíeu, normalment una xarxa enorme o un pool esgotat.

Un pool és una reserva, no una prova. El Docker evita els conflictes que veu a la taula d'encaminament de l'amfitrió i no pot veure una VPN a la qual encara no us heu connectat.

Aquesta limitació és tot el motiu per triar amb deliberació. Els rangs amb què cal comparar són els que l'amfitrió ha d'abastar: la LAN de l'oficina, les subxarxes internes de la VPN corporativa, els prefixos del laboratori o de staging i qualsevol altre amfitrió de contenidors al mateix overlay. Anoteu-los com a CIDR abans de tocar el dimoni, perquè una llista al cap us deixarà fora justament el que importa. Després trieu una base que no se solapi amb cap d'ells i guardeu la llista amb el desplegament perquè la persona següent no repeteixi l'exercici de memòria.

Inventarieu abans de triar

Primer inventarieu el que existeix. docker network ls llista les xarxes, i docker network inspect bridge -f '{{.IPAM.Config}}' imprimeix la subxarxa que fa servir una de concreta. Repetiu-ho per a cada xarxa definida per l'usuari, perquè els projectes Compose creen les seves i un --subnet explícit en un fitxer compose passa per alt el pool del tot.

Aquest últim punt és el que sobreviu a la migració. Un canvi de pool no impedeix que un col·lega fixi 172.18.0.0/16 en un fitxer compose, i el conflicte torna amb un altre autor.

Migrar el que ja existeix

Migrar les xarxes existents és una operació separada i suportada. Cada xarxa afectada s'ha de recrear amb la subxarxa nova, cosa que vol dir desenganxar i tornar a enganxar els contenidors que la fan servir, i recrear una xarxa elimina les seves connexions de contenidors en lloc de moure-les. Preserveu els volums i la configuració i tracteu la recreació com un desplegament, no com un reinici de dades. Feu la feina en una finestra de manteniment, perquè els contenidors d'una xarxa recreada es reinicien tant si ho heu planificat com si no.

Seguiu la configuració del dimoni i el procediment de reinici documentats, i coordineu la interrupció. En un amfitrió amb un sol dimoni, systemctl restart docker reinicia els contenidors segons les seves polítiques de reinici, i aquest és un comportament que val la pena conèixer abans i no després.

Després verifiqueu les dues coses que el canvi havia d'arreglar. Inspeccioneu la subxarxa nova amb docker network inspect i confirmeu que és dins de la base triada, i després comproveu la ruta cap a una destinació VPN representativa amb ip route get 10.20.30.40 i confirmeu que va on espereu i no cap a un pont. Proveu també el descobriment de serveis i la comunicació entre contenidors, perquè una xarxa recreada amb un adreçament diferent pot trencar la resolució de noms de maneres que semblen un error de l'aplicació.

Què encara es trenca després

La part duradora és el registre. Guardeu la llista d'assignacions, la base i la mida triades i les xarxes recreades al mateix lloc que el desplegament.

Que un rang sigui privat no el fa segur per reutilitzar-lo. 10.0.0.0/8 és privat i també és el més probable que ja estigui en ús en algun punt del camí, i per això la resposta és una reserva concreta i no una preferència per un bloc. La documentació de xarxes del Docker descriu l'assignació automàtica de subxarxes i els camps del pool. Trieu el rang a partir del que heu d'abastar, no del que sembla endreçat.