Ŝanĝo de la defaŭlta Docker-pool ne renumeras retojn

Ŝanĝi default-address-pools ne renumeras la retojn, kiujn vi jam havas, kaj atendi tion estas kiel zorge farita plano fariĝas neatendita interrompo. La agordo regas la aŭtomatan atribuon por retoj kreitaj post kiam la demono restartiĝas kun la nova konfiguro. Ĉio jam funkcianta konservas la subreton, kiun ĝi ricevis, ĉar tiu subreto estas parto de la konservita difino de la reto. La mito estas oportuna, ĉar ĝi sugestas, ke unu ŝanĝo solvas ĉiun koincidon, kaj la realo estas laboro en du partoj: elektu gamon, kiu estas vere libera, poste migru la retojn, kiuj ne estas.

La mito: unu ŝanĝo de la pool solvas la koincidon

La mito havas specifan formon. Iu legas, ke la defaŭlta pool de Docker povas esti ŝanĝita, ŝanĝas ĝin, restartas la demonon kaj konkludas, ke la uja reto ne plu kolizias kun la oficeja VPN. La malnova reto ankoraŭ estas tie, ankoraŭ ligita, kaj ankoraŭ tenas la adreson, kiu kolizias.

Tio, kio ŝanĝiĝis, estas la estonta konduto de la atribuanto, kiu estas vere utila kaj vere limigita. Novaj retoj kreitaj sen eksplicita --subnet estas eltranĉitaj el la nova pool; la ekzistantaj neniam estis en tiu pool. Restarto ne rekonstruas retojn kaj ne movas ujojn inter ili. Se la simptomo daŭras post la ŝanĝo, la ŝanĝo estis reala kaj la diagnozo nekompleta.

Baza gamo kaj atribuita prefikso

La konfiguro havas du kampojn facile konfuzeblajn. base estas la gamo, el kiu la atribuanto tranĉas, kaj size estas la prefiksa longo de ĉiu atribuita reto, do bazo 10.10.0.0/16 kun grandeco 24 disdonas /24 ene de tiu /16. Inversigi la rolojn produktas atribuan ŝablonon, kiun vi ne intencis, kutime unu enorma reto aŭ elĉerpita pool.

Pool estas rezervo, ne pruvo. Docker evitas konfliktojn, kiujn ĝi vidas en la enkursiga tabelo de la gastiganto, kaj ĝi ne povas vidi VPN, al kiu vi ankoraŭ ne konektiĝis.

Tiu limigo estas la tuta kialo elekti konscie. La gamoj por kompari estas tiuj, kiujn la gastiganto devas atingi: la oficeja LAN, la internaj subretoj de la firmaa VPN, la prefiksoj de la laboratorio aŭ stagado, kaj ajna alia uja gastiganto sur la sama overlay. Skribu ilin kiel CIDR antaŭ ol tuŝi la demonon, ĉar listo en la kapo maltrafos ĝuste tiun, kiu gravas. Poste elektu bazon, kiu koincidas kun neniu el ili, kaj konservu la liston kun la deplojo, por ke la sekva persono ne ripetu la ekzercon el memoro.

Inventaru antaŭ ol elekti

Unue inventaru tion, kio ekzistas. docker network ls listigas la retojn, kaj docker network inspect bridge -f '{{.IPAM.Config}}' presas la subreton, kiun uzas specifa reto. Ripetu por ĉiu uzant-difinita reto, ĉar Compose-projektoj kreas proprajn kaj eksplicita --subnet en compose-dosiero tute preterpasas la pool.

Tiu lasta punkto estas la sola, kiu postvivas la migradon. Ŝanĝo de la pool ne malhelpas kolegon fiksi 172.18.0.0/16 en compose-dosiero, kaj la konflikto revenas kun alia aŭtoro.

Migri tion, kio jam ekzistas

Migri ekzistantajn retojn estas aparta, subtenata operacio. Ĉiu tuŝita reto devas esti rekreiita kun la nova subreto, kio signifas malkonekti kaj rekonekti la ujojn, kiuj uzas ĝin, kaj rekrei reton forigas ĝiajn ujajn aliĝojn anstataŭ movi ilin. Konservu volumojn kaj konfiguron kaj traktu la rekreon kiel deplojon, ne kiel datumrestarigon. Faru la laboron en prizorga fenestro, ĉar la ujoj sur rekreiita reto restartas sendepende de tio, ĉu vi planis ĝin.

Sekvu la dokumentitan demonan konfiguron kaj restartan proceduron kaj kunordigu la interrompon. Sur gastiganto kun unu demono, systemctl restart docker restartas ujojn laŭ iliaj restartaj politikoj, kaj tio estas konduto inda koni antaŭe, ne poste.

Poste kontrolu la du aferojn, kiujn la ŝanĝo devus ripari. Inspektu la novan subreton per docker network inspect kaj konfirmu, ke ĝi estas ene de la elektita bazo, poste kontrolu la itineron al reprezenta VPN-celo per ip route get 10.20.30.40 kaj konfirmu, ke ĝi iras tien, kien vi atendas, ne en ponton. Testu ankaŭ la malkovron de servoj kaj la ujo-al-ujo komunikadon, ĉar reto rekreiita kun alia adresado povas rompi nomrezolucion tiel, ke ĝi aspektas kiel aplika cimo.

Kio ankoraŭ rompiĝas poste

La daŭra parto estas la registro. Konservu la atribuan liston, la elektitan bazon kaj grandecon, kaj la rekreiitajn retojn en la sama loko kiel la deplojo.

Tio, ke gamo estas privata, ne faras ĝin sekura por reuzo. 10.0.0.0/8 estas privata kaj ankaŭ la plej verŝajna afero jam uzata ie sur la vojo, tial la respondo estas specifa rezervo, ne prefero por unu bloko. La Docker-reta dokumentaro priskribas aŭtomatan subretan atribuon kaj la pool-kampojn. Elektu la gamon laŭ tio, kion vi devas atingi, ne laŭ tio, kio aspektas ordema.