Mudar o pool padrão do Docker não renumera as redes

Mudar default-address-pools não renumera as redes que já tem, e esperar isso é precisamente como um plano cuidadoso se transforma numa falha inesperada. A definição governa a atribuição automática das redes criadas depois de o daemon reiniciar com a nova configuração. Tudo o que já está a correr mantém a sub-rede que lhe foi atribuída, porque essa sub-rede faz parte da definição guardada da rede. O mito é cómodo porque sugere que uma única alteração corrige todos os sobreposições, e a realidade é um trabalho em duas partes: escolha um intervalo que esteja realmente livre e depois migre as redes que não estão.

O mito: uma alteração ao pool corrige a sobreposição

O mito tem uma forma concreta. Alguém lê que o pool padrão do Docker pode ser alterado, altera-o, reinicia o daemon e conclui que a rede de contentores já não colide com a VPN do escritório. A rede antiga continua lá, continua ligada e continua a deter o endereço que colide.

O que mudou foi o comportamento futuro do alocador, que é realmente útil e realmente limitado. As redes novas criadas sem um --subnet explícito são cortadas do novo pool; as existentes nunca estiveram nesse pool. Um reinício não reconstrói redes nem move contentores entre elas. Se o sintoma persistir depois da alteração, a alteração era real e o diagnóstico estava incompleto.

Intervalo base e prefixo atribuído

A configuração tem dois campos fáceis de confundir. base é o intervalo de onde o alocador corta, e size é o comprimento do prefixo de cada rede atribuída, por isso uma base 10.10.0.0/16 com tamanho 24 distribui /24 dentro desse /16. Trocar os papéis produz um padrão de atribuição que não pretendia, normalmente uma rede enorme ou um pool esgotado.

Um pool é uma reserva, não uma prova. O Docker evita os conflitos que vê na tabela de encaminhamento do anfitrião e não consegue ver uma VPN à qual ainda não se ligou.

Essa limitação é todo o motivo para escolher com deliberação. Os intervalos a comparar são os que o anfitrião tem de alcançar: a LAN do escritório, as sub-redes internas da VPN corporativa, os prefixos do laboratório ou de staging e qualquer outro anfitrião de contentores no mesmo overlay. Anote-os como CIDR antes de tocar no daemon, porque uma lista na cabeça vai falhar exatamente aquele que importa. Depois escolha uma base que não se sobreponha a nenhum deles e guarde a lista junto da implementação para que a pessoa seguinte não repita o exercício de memória.

Inventarie antes de escolher

Primeiro inventarie o que existe. docker network ls lista as redes, e docker network inspect bridge -f '{{.IPAM.Config}}' imprime a sub-rede que uma rede concreta usa. Repita para cada rede definida pelo utilizador, porque os projetos Compose criam as suas e um --subnet explícito num ficheiro compose contorna o pool por completo.

Esse último ponto é o que sobrevive à migração. Uma alteração ao pool não impede um colega de fixar 172.18.0.0/16 num ficheiro compose, e o conflito regressa com outro autor.

Migrar o que já existe

Migrar redes existentes é uma operação separada e suportada. Cada rede afetada tem de ser recriada com a nova sub-rede, o que significa desligar e voltar a ligar os contentores que a usam, e recriar uma rede remove as suas ligações de contentores em vez de as mover. Preserve os volumes e a configuração e trate a recriação como uma implementação, não como um reinício de dados. Faça o trabalho numa janela de manutenção, porque os contentores de uma rede recriada reiniciam quer o tenha planeado quer não.

Siga a configuração do daemon e o procedimento de reinício documentados e coordene a interrupção. Num anfitrião com um único daemon, systemctl restart docker reinicia os contentores segundo as suas políticas de reinício, e esse é um comportamento que vale a pena conhecer antes e não depois.

Depois verifique as duas coisas que a alteração devia corrigir. Inspecione a nova sub-rede com docker network inspect e confirme que está dentro da base escolhida, e depois verifique a rota para um destino VPN representativo com ip route get 10.20.30.40 e confirme que vai onde espera e não para uma bridge. Teste também a descoberta de serviços e a comunicação entre contentores, porque uma rede recriada com outro endereçamento pode quebrar a resolução de nomes de formas que parecem um erro da aplicação.

O que ainda se parte depois

A parte duradoura é o registo. Guarde a lista de atribuições, a base e o tamanho escolhidos e as redes recriadas no mesmo local da implementação.

O facto de um intervalo ser privado não o torna seguro para reutilizar. 10.0.0.0/8 é privado e também a coisa mais provável de já estar em uso em algum ponto do caminho, e é por isso que a resposta é uma reserva concreta e não uma preferência por um bloco. A documentação de redes do Docker descreve a atribuição automática de sub-redes e os campos do pool. Escolha o intervalo pelo que tem de alcançar, não pelo que parece arrumado.