Změna výchozího poolu Dockeru sítě nepřečísluje

Změna default-address-pools nepřečísluje sítě, které už máte, a právě čekání na to promění pečlivý plán v nečekaný výpadek. Nastavení řídí automatické přidělování sítím vytvořeným poté, co se démon restartuje s novou konfigurací. Všechno, co už běží, si ponechá přidělenou podsíť, protože ta podsíť je součástí uložené definice sítě. Mýtus je pohodlný, protože naznačuje, že jedna úprava vyřeší každý překryv, a realita je práce o dvou částech: vyberte rozsah, který je skutečně volný, a pak migrujte sítě, které volné nejsou.

Mýtus: jedna změna poolu vyřeší překryv

Mýtus má konkrétní podobu. Někdo si přečte, že výchozí pool Dockeru lze změnit, změní ho, restartuje démona a usoudí, že kontejnerová síť už nekoliduje s kancelářskou VPN. Stará síť je pořád tam, pořád připojená a pořád drží adresu, která koliduje.

Změnilo se budoucí chování alokátoru, což je opravdu užitečné a opravdu omezené. Nové sítě vytvořené bez explicitního --subnet se vyřezávají z nového poolu; ty stávající v něm nikdy nebyly. Restart sítě nepřestavuje a nepřesouvá kontejnery mezi nimi. Pokud symptom po změně přetrvává, změna byla skutečná a diagnóza byla neúplná.

Základní rozsah a přidělený prefix

Konfigurace má dvě pole, která se snadno pletou. base je rozsah, ze kterého alokátor vyřezává, a size je délka prefixu každé přidělené sítě, takže základ 10.10.0.0/16 s velikostí 24 rozdává /24 uvnitř toho /16. Prohození rolí vytvoří vzorec přidělování, který jste nechtěli, obvykle jednu obrovskou síť nebo vyčerpaný pool.

Pool je rezervace, ne důkaz. Docker se vyhýbá konfliktům, které vidí v routovací tabulce hostitele, a nemůže vidět VPN, ke které jste se ještě nepřipojili.

To omezení je celý důvod volit vědomě. Rozsahy k porovnání jsou ty, kterých musí hostitel dosáhnout: kancelářská LAN, vnitřní podsítě podnikové VPN, prefixy laboratoře nebo stagingu a jakýkoli jiný kontejnerový hostitel na stejném overlayi. Zapište je jako CIDR, než se dotknete démona, protože seznam v hlavě vám unikne právě ten, na kterém záleží. Pak vyberte základ, který se s žádným nepřekrývá, a držte seznam u nasazení, aby další člověk neopakoval cvičení z paměti.

Zinventarizujte, než vyberete

Nejprve zinventarizujte, co existuje. docker network ls vypisuje sítě a docker network inspect bridge -f '{{.IPAM.Config}}' vypíše podsíť, kterou konkrétní síť používá. Opakujte to pro každou uživatelsky definovanou síť, protože projekty Compose si vytvářejí vlastní a explicitní --subnet v souboru compose pool úplně obejde.

Právě ten poslední bod migraci přežije. Změna poolu nezabrání kolegovi, aby v souboru compose připnul 172.18.0.0/16, a konflikt se vrátí s jiným autorem.

Migrace toho, co už existuje

Migrace stávajících sítí je samostatná, podporovaná operace. Každou zasaženou síť je třeba znovu vytvořit s novou podsítí, což znamená odpojit a znovu připojit kontejnery, které ji používají, a znovuvytvoření sítě odstraní její připojení kontejnerů, místo aby je přesunulo. Zachovejte svazky a konfiguraci a berte znovuvytvoření jako nasazení, ne jako reset dat. Pracujte v maintenance okně, protože kontejnery na znovu vytvořené síti se restartují, ať to plánujete, nebo ne.

Postupujte podle dokumentované konfigurace démona a postupu restartu a přerušení koordinujte. Na hostiteli s jedním démonem systemctl restart docker restartuje kontejnery podle jejich restartovacích politik, což je chování, které je dobré znát předem, ne až potom.

Pak ověřte dvě věci, které měla změna opravit. Prohlédněte novou podsíť pomocí docker network inspect a potvrďte, že leží uvnitř zvoleného základu, pak zkontrolujte trasu k reprezentativnímu cíli VPN pomocí ip route get 10.20.30.40 a potvrďte, že vede tam, kam čekáte, a ne do bridge. Otestujte také objevování služeb a komunikaci mezi kontejnery, protože síť znovu vytvořená s jiným adresováním může rozbít překlad jmen způsoby, které vypadají jako chyba aplikace.

Co se i potom rozbíjí

Trvalá část je záznam. Uchovávejte seznam přidělení, zvolený základ a velikost a znovu vytvořené sítě na stejném místě jako nasazení.

To, že je rozsah privátní, ho nedělá bezpečným k opětovnému použití. 10.0.0.0/8 je privátní a zároveň nejpravděpodobněji už někde na cestě použitý, a proto je odpovědí konkrétní rezervace, ne preference jednoho bloku. Dokumentace sítí Dockeru popisuje automatické přidělování podsítí a pole poolu. Vybírejte rozsah podle toho, čeho musíte dosáhnout, ne podle toho, co vypadá uklizeně.