Cambiare il pool predefinito di Docker non rinumera le reti

Modificare default-address-pools non rinumera le reti che avete già, e aspettarselo è esattamente il modo in cui un piano accurato diventa un'interruzione imprevista. L'impostazione governa l'assegnazione automatica delle reti create dopo il riavvio del demone con la nuova configurazione. Tutto ciò che già gira conserva la sottorete che gli è stata assegnata, perché quella sottorete fa parte della definizione memorizzata della rete. Il mito è comodo perché suggerisce che una sola modifica sistemi ogni sovrapposizione, e la realtà è un lavoro in due parti: scegliete un intervallo davvero libero, poi migrate le reti che non lo sono.

Il mito: una modifica al pool sistema la sovrapposizione

Il mito ha una forma precisa. Qualcuno legge che il pool predefinito di Docker può essere cambiato, lo cambia, riavvia il demone e conclude che la rete dei container non entra più in collisione con la VPN dell'ufficio. La vecchia rete è ancora lì, ancora collegata e detiene ancora l'indirizzo che entra in collisione.

Ciò che è cambiato è il comportamento futuro dell'allocatore, che è davvero utile e davvero limitato. Le nuove reti create senza un --subnet esplicito vengono ritagliate dal nuovo pool; quelle esistenti non sono mai state in quel pool. Un riavvio non ricostruisce le reti e non sposta i container tra di esse. Se il sintomo persiste dopo la modifica, la modifica era reale e la diagnosi incompleta.

Intervallo di base e prefisso assegnato

La configurazione ha due campi facili da confondere. base è l'intervallo da cui l'allocatore ritaglia, e size è la lunghezza del prefisso di ogni rete assegnata, quindi una base 10.10.0.0/16 con dimensione 24 distribuisce /24 all'interno di quel /16. Invertire i ruoli produce uno schema di assegnazione non voluto, di solito un'unica rete enorme o un pool esaurito.

Un pool è una prenotazione, non una prova. Docker evita i conflitti che vede nella tabella di routing dell'host e non può vedere una VPN a cui non vi siete ancora collegati.

Questo limite è l'intero motivo per scegliere con cognizione. Gli intervalli da confrontare sono quelli che l'host deve raggiungere: la LAN dell'ufficio, le sottoreti interne della VPN aziendale, i prefissi del laboratorio o dello staging e qualsiasi altro host di container sullo stesso overlay. Scriveteli come CIDR prima di toccare il demone, perché un elenco a memoria salterà proprio quello che conta. Poi scegliete una base che non si sovrapponga a nessuno di essi e conservate l'elenco insieme al deployment, così la persona successiva non ripete l'esercizio a memoria.

Inventariate prima di scegliere

Inventariate prima ciò che esiste. docker network ls elenca le reti, e docker network inspect bridge -f '{{.IPAM.Config}}' stampa la sottorete usata da una specifica. Ripetete per ogni rete definita dall'utente, perché i progetti Compose creano le proprie e un --subnet esplicito in un file compose aggira del tutto il pool.

Quest'ultimo punto è quello che sopravvive alla migrazione. Un cambio di pool non impedisce a un collega di fissare 172.18.0.0/16 in un file compose, e il conflitto torna con un altro autore.

Migrare ciò che esiste già

Migrare le reti esistenti è un'operazione separata e supportata. Ogni rete interessata deve essere ricreata con la nuova sottorete, il che significa scollegare e ricollegare i container che la usano, e ricreare una rete rimuove i suoi collegamenti ai container invece di spostarli. Preservate volumi e configurazione e trattate la ricreazione come un deployment, non come un azzeramento dei dati. Fate il lavoro in una finestra di manutenzione, perché i container di una rete ricreata si riavviano che l'abbiate pianificato o no.

Seguite la configurazione del demone e la procedura di riavvio documentate, e coordinate l'interruzione. Su un host con un solo demone, systemctl restart docker riavvia i container secondo le loro politiche di riavvio, ed è un comportamento che vale la pena conoscere prima e non dopo.

Poi verificate le due cose che la modifica doveva sistemare. Ispezionate la nuova sottorete con docker network inspect e confermate che si trovi dentro la base scelta, poi controllate la rotta verso una destinazione VPN rappresentativa con ip route get 10.20.30.40 e confermate che vada dove vi aspettate e non in un bridge. Testate anche la scoperta dei servizi e la comunicazione tra container, perché una rete ricreata con un indirizzamento diverso può rompere la risoluzione dei nomi in modi che sembrano un bug dell'applicazione.

Cosa si rompe ancora dopo

La parte duratura è il registro. Conservate l'elenco delle assegnazioni, la base e la dimensione scelte e le reti ricreate nello stesso posto del deployment.

Il fatto che un intervallo sia privato non lo rende sicuro da riutilizzare. 10.0.0.0/8 è privato ed è anche la cosa più probabile che sia già in uso da qualche parte lungo il percorso, per questo la risposta è una prenotazione specifica e non una preferenza per un blocco. La documentazione di rete di Docker descrive l'assegnazione automatica delle sottoreti e i campi del pool. Scegliete l'intervallo in base a ciò che dovete raggiungere, non a ciò che sembra ordinato.