Cambiar o pool predeterminado de Docker non renumera as redes

Cambiar default-address-pools non renumera as redes que xa ten, e esperalo é xusto como un plan coidadoso se converte nunha caída inesperada. O axuste goberna a asignación automática das redes creadas despois de que o daemon se reinicie coa nova configuración. Todo o que xa funciona conserva a subrede que se lle deu, porque esa subrede forma parte da definición gardada da rede. O mito é cómodo porque suxire que unha soa edición arranxa cada solapamento, e a realidade é un traballo en dúas partes: escolla un rango que estea realmente libre e despois migre as redes que non o están.

O mito: un só cambio de pool arranxa o solapamento

O mito ten unha forma concreta. Alguén le que o pool predeterminado de Docker se pode cambiar, cámbiao, reinicia o daemon e conclúe que a rede de contedores xa non choca coa VPN da oficina. A rede antiga segue aí, segue conectada e segue tendo o enderezo que choca.

O que cambiou é o comportamento futuro do asignador, que é realmente útil e realmente limitado. As redes novas creadas sen un --subnet explícito córtanse do pool novo; as existentes nunca estiveron nese pool. Un reinicio non reconstrúe redes nin move contedores entre elas. Se o síntoma persiste despois do cambio, o cambio foi real e o diagnóstico estaba incompleto.

Rango base e prefixo asignado

A configuración ten dous campos que é fácil confundir. base é o rango do que corta o asignador, e size é a lonxitude de prefixo de cada rede asignada, así que unha base 10.10.0.0/16 con tamaño 24 reparte /24 dentro dese /16. Inverter os papeis produce un patrón de asignación que non pretendía, normalmente unha rede enorme ou un pool esgotado.

Un pool é unha reserva, non unha proba. Docker evita os conflitos que ve na táboa de encamiñamento do host e non pode ver unha VPN á que aínda non se conectou.

Esa limitación é todo o motivo para elixir con deliberación. Os rangos cos que comparar son os que o host debe alcanzar: a LAN da oficina, as subredes internas da VPN corporativa, os prefixos do laboratorio ou de staging e calquera outro host de contedores no mesmo overlay. Anóteos como CIDR antes de tocar o daemon, porque unha lista na cabeza vai saltar xusto a que importa. Logo elixa unha base que non se solape con ningún e garde a lista xunto ao despregamento para que a seguinte persoa non repita o exercicio de memoria.

Inventaríe antes de elixir

Primeiro inventaríe o que existe. docker network ls lista as redes, e docker network inspect bridge -f '{{.IPAM.Config}}' imprime a subrede que usa unha concreta. Repítao para cada rede definida polo usuario, porque os proxectos Compose crean as súas e un --subnet explícito nun ficheiro compose salta o pool por completo.

Ese último punto é o que sobrevive á migración. Un cambio de pool non impide que un compañeiro fixe 172.18.0.0/16 nun ficheiro compose, e o conflito volve con outro autor.

Migrar o que xa existe

Migrar as redes existentes é unha operación aparte e compatible. Cada rede afectada debe recrearse coa subrede nova, o que significa desconectar e volver conectar os contedores que a usan, e recrear unha rede elimina as súas conexións de contedores en lugar de movelas. Conserve os volumes e a configuración e trate a recreación como un despregamento, non como un reinicio de datos. Faga o traballo nunha xanela de mantemento, porque os contedores dunha rede recreada reinícianse tanto se o planificou como se non.

Siga a configuración do daemon e o procedemento de reinicio documentados, e coordine a interrupción. Nun host cun só daemon, systemctl restart docker reinicia os contedores segundo as súas políticas de reinicio, e ese é un comportamento que convén coñecer antes e non despois.

Logo verifique as dúas cousas que o cambio debía arranxar. Inspeccione a subrede nova con docker network inspect e confirme que está dentro da base elixida, e despois comprobe a ruta cara a un destino VPN representativo con ip route get 10.20.30.40 e confirme que vai onde espera e non cara a unha ponte. Probe tamén o descubrimento de servizos e a comunicación entre contedores, porque unha rede recreada con outro enderezo pode romper a resolución de nomes de formas que parecen un erro da aplicación.

Que segue rompéndose despois

A parte duradeira é o rexistro. Garde a lista de asignacións, a base e o tamaño elixidos e as redes recreadas no mesmo lugar que o despregamento.

Que un rango sexa privado non o fai seguro para reutilizar. 10.0.0.0/8 é privado e tamén o máis probable que xa estea en uso nalgún punto do camiño, por iso a resposta é unha reserva concreta e non unha preferencia por un bloque. A documentación de redes de Docker describe a asignación automática de subredes e os campos do pool. Elixa o rango polo que debe alcanzar, non polo que parece ordenado.