Ang pagbabago ng default pool ng Docker ay hindi nagnonumero muli ng mga network

Ang pagbabago ng default-address-pools ay hindi nagnonumero muli ng mga network na mayroon ka na, at ang pag-asa nito ang dahilan kung bakit ang maingat na plano ay nagiging hindi inaasahang pagkaantala. Pinamamahalaan ng setting ang awtomatikong paglalaan para sa mga network na nilikha pagkatapos mag-restart ang daemon gamit ang bagong configuration. Ang lahat ng tumatakbo na ay pinapanatili ang subnet na ibinigay dito, dahil ang subnet na iyon ay bahagi ng naka-save na depinisyon ng network. Ang mito ay maginhawa dahil iminumungkahi nito na ang isang pagbabago ay nag-aayos ng bawat overlap, at ang katotohanan ay trabaho sa dalawang bahagi: pumili ng saklaw na talagang libre, pagkatapos ay ilipat ang mga network na hindi.

Ang mito: isang pagbabago sa pool ang nag-aayos ng overlap

Ang mito ay may tiyak na hugis. May nakabasa na ang default pool ng Docker ay maaaring baguhin, binago ito, ini-restart ang daemon at nagpasya na ang container network ay hindi na bumabangga sa VPN ng opisina. Ang lumang network ay nandoon pa rin, nakakonekta pa rin at hawak pa rin ang address na bumabangga.

Ang nagbago ay ang hinaharap na pag-uugali ng naglalaan, na talagang kapaki-pakinabang at talagang limitado. Ang mga bagong network na nilikha nang walang malinaw na --subnet ay hinihiwa mula sa bagong pool; ang mga umiiral ay hindi kailanman naging bahagi ng pool na iyon. Ang pag-restart ay hindi nagtatayo muli ng mga network at hindi naglilipat ng mga container sa pagitan ng mga ito. Kung magpapatuloy ang sintomas pagkatapos ng pagbabago, totoo ang pagbabago at ang diagnosis ay hindi kumpleto.

Base range at inilalaang prefix

Ang configuration ay may dalawang field na madaling pagkamalangan. Ang base ay ang saklaw na hinihiwa ng naglalaan, at ang size ay ang haba ng prefix ng bawat inilalaang network, kaya ang base na 10.10.0.0/16 na may sukat na 24 ay namamahagi ng /24 sa loob ng /16 na iyon. Ang pagbaliktad ng mga papel ay gumagawa ng pattern ng paglalaan na hindi mo sinadya, kadalasan isang napakalaking network o isang naubos na pool.

Ang pool ay reserbasyon, hindi patunay. Iniiwasan ng Docker ang mga conflict na nakikita nito sa routing table ng host, at hindi nito makikita ang VPN na hindi mo pa nakakonekta.

Ang limitasyong iyon ang buong dahilan upang sadyang pumili. Ang mga saklaw na ihahambing ay ang mga kailangang maabot ng host: ang LAN ng opisina, ang mga panloob na subnet ng corporate VPN, ang mga prefix ng lab o staging at anumang iba pang container host sa parehong overlay. Isulat ang mga ito bilang CIDR bago hawakan ang daemon, dahil ang listahan sa isip ay makakaligtaan ang pinakamahalaga. Pagkatapos ay pumili ng base na hindi nago-overlap sa alinman sa mga ito, at itago ang listahan kasama ng deployment upang hindi ulitin ng susunod na tao ang ehersisyo mula sa memorya.

Iimbentaryo bago pumili

Iimbentaryo muna ang umiiral. Ang docker network ls ay naglilista ng mga network, at ang docker network inspect bridge -f '{{.IPAM.Config}}' ay nagpi-print ng subnet na ginagamit ng isang partikular na network. Ulitin para sa bawat network na tinukoy ng user, dahil ang mga proyekto ng Compose ay gumagawa ng sarili nila at ang malinaw na --subnet sa isang compose file ay lumalampas sa pool nang buo.

Ang huling puntong iyon ang nabubuhay pagkatapos ng migrasyon. Ang pagbabago ng pool ay hindi pumipigil sa kasamahan na i-pin ang 172.18.0.0/16 sa isang compose file, at bumabalik ang conflict kasama ng ibang may-akda.

Ilipat ang umiiral na

Ang paglilipat ng mga umiiral na network ay hiwalay at suportadong operasyon. Ang bawat apektadong network ay kailangang muling likhain gamit ang bagong subnet, na nangangahulugang idiskonekta at ikonekta muli ang mga container na gumagamit nito, at ang muling paglikha ng network ay nag-aalis ng mga container attachment nito sa halip na ilipat ang mga ito. Panatilihin ang mga volume at configuration at ituring ang muling paglikha bilang deployment, hindi data reset. Gawin ang trabaho sa maintenance window, dahil ang mga container sa muling nilikhang network ay nagre-restart kahit planuhin mo ito o hindi.

Sundin ang dokumentadong daemon configuration at restart procedure, at i-coordinate ang pagkaantala. Sa host na may isang daemon, ang systemctl restart docker ay nagre-restart ng mga container ayon sa kanilang restart policy, at iyon ay pag-uugaling dapat malaman bago at hindi pagkatapos.

Pagkatapos ay i-verify ang dalawang bagay na dapat ayusin ng pagbabago. Suriin ang bagong subnet gamit ang docker network inspect at kumpirmahin na nasa loob ito ng piniling base, pagkatapos ay suriin ang ruta patungo sa isang representatibong destinasyon ng VPN gamit ang ip route get 10.20.30.40 at kumpirmahin na pumupunta ito sa inaasahan mo at hindi sa isang bridge. Subukan din ang service discovery at komunikasyon ng container-sa-container, dahil ang network na muling nilikha na may ibang addressing ay maaaring makasira ng name resolution sa mga paraang mukhang bug ng application.

Ano pa ang nasisira pagkatapos

Ang matibay na bahagi ay ang talaan. Itago ang listahan ng paglalaan, ang piniling base at sukat, at ang mga muling nilikhang network sa parehong lugar ng deployment.

Ang pagiging pribado ng saklaw ay hindi nagpapasigurong ligtas itong gamitin muli. Ang 10.0.0.0/8 ay pribado at kasabay nito ang pinakamalamang na ginagamit na sa isang lugar sa ruta, kaya ang sagot ay isang tiyak na reserbasyon at hindi kagustuhan sa isang bloke. Inilalarawan ng dokumentasyon ng network ng Docker ang awtomatikong paglalaan ng subnet at ang mga field ng pool. Piliin ang saklaw batay sa kailangan mong maabot, hindi batay sa mukhang maayos.