Docker-en pool lehenetsia aldatzeak ez ditu sareak berriro zenbakitzen

default-address-pools aldatzeak ez ditu jada dituzun sareak berriro zenbakitzen, eta hori espero izatea da plan arretatsu bat ustekabeko eten bihurtzeko modua. Ezarpnak daemonak konfigurazio berriarekin berrabiarazi ondoren sortzen diren sareen esleipen automatikoa arautzen du. Dagoeneko martxan dagoen guztiak emandako azpisarea mantentzen du, azpisare hori sarearen gordetako definizioaren parte delako. Mitoa erosoa da edizio bakar batek gainjartze guztiak konpontzen dituela iradokitzen duelako, eta errealitatea bi zatitako lana da: aukeratu benetan libre dagoen barruti bat, eta gero migratu libre ez dauden sareak.

Mitoa: pool aldaketa batek gainjartzea konpontzen du

Mitoak forma zehatza du. Norbaitek Docker-en pool lehenetsia alda daitekeela irakurtzen du, aldatzen du, daemona berrabiarazten du eta ondorioztatzen du edukiontzi-sareak jada ez duela bulegoko VPNarekin talka egiten. Sare zaharra oraindik han dago, oraindik konektatuta, eta oraindik talka egiten duen helbidea dauka.

Aldatu dena esleitzailearen etorkizuneko portaera da, benetan erabilgarria eta benetan mugatua dena. --subnet espliziturik gabe sortutako sare berriak pool berritik mozten dira; lehendik daudenak ez ziren inoiz pool horretan egon. Berrabiarazteak ez ditu sareak berreraikitzen eta ez ditu edukiontziak haien artean mugitzen. Aldaketaren ondoren sintomak jarraitzen badu, aldaketa erreala izan zen eta diagnosia osatugabea.

Oinarrizko barrutia eta esleitutako aurrizkia

Konfigurazioak erraz nahasten diren bi eremu ditu. base esleitzaileak mozten duen barrutia da, eta size esleitutako sare bakoitzaren aurrizki-luzera, beraz 10.10.0.0/16 oinarriak 24 tamainarekin /24 banatzen ditu /16 horren barruan. Rolak alderantziz jartzeak nahi ez zenuen esleipen-eredua sortzen du, normalean sare erraldoi bat edo pool agortu bat.

Pool bat erreserba da, ez proba. Dockerrek ostalariaren bideratze-taulan ikusten dituen gatazkak saihesten ditu, eta oraindik konektatu ez duzun VPN bat ezin du ikusi.

Muga hori da deliberatuki aukeratzeko arrazoi osoa. Alderatzeko barrutiak ostalariak iritsi behar dituenak dira: bulegoko LANa, enpresako VPNaren barneko azpisareak, laborategiko edo stagingeko aurrizkiak eta overlay berean dagoen beste edozein edukiontzi-ostalari. Idatzi itzazu CIDR gisa daemona ukitu aurretik, buruko zerrendak garrantzitsuena dena huts egingo baitu. Gero aukeratu horietako batekin ere gainjartzen ez den oinarri bat, eta gorde zerrenda hedapenarekin batera, hurrengo pertsonak ariketa buruz ez errepikatzeko.

Inbentariatu aukeratu aurretik

Lehenengo inbentariatu existitzen dena. docker network ls sareak zerrendatzen ditu, eta docker network inspect bridge -f '{{.IPAM.Config}}' sare jakin batek erabiltzen duen azpisarea inprimatzen du. Errepikatu erabiltzaileak definitutako sare bakoitzerako, Compose proiektuak bereak sortzen baititu eta compose fitxategi bateko --subnet esplizituak pool-a erabat saihesten baitu.

Azken puntu hori da migrazioari eusten diona. Pool aldaketak ez dio lankide bati compose fitxategi batean 172.18.0.0/16 finkatzea eragozten, eta gatazka beste egile batekin itzultzen da.

Dagoeneko badagoena migratzea

Lehendik dauden sareak migratzea eragiketa bereizia eta onartua da. Eragindako sare bakoitza azpisare berriarekin birsortu behar da, eta horrek esan nahi du hura erabiltzen duten edukiontziak deskonektatu eta berriro konektatu behar direla, eta sare bat birsortzeak edukiontzi-eranskinak kentzen ditu, ez ditu mugitzen. Gorde bolumenak eta konfigurazioa, eta hartu birsorketa hedapen gisa, ez datuen berrezarketa gisa. Egin lana mantenimendu-leiho batean, birsortutako sare bateko edukiontziak berrabiarazten baitira hori planifikatu ala ez.

Jarraitu dokumentatutako daemonaren konfigurazioa eta berrabiarazte-prozedura, eta koordinatu etena. Daemon bakarreko ostalari batean, systemctl restart docker edukiontziak haien berrabiarazte-politiken arabera berrabiarazten ditu, eta hori aurretik ezagutzea merezi duen portaera da, ez geroago.

Gero egiaztatu aldaketak konpondu behar zituen bi gauzak. Ikuskatu azpisare berria docker network inspect-ekin eta egiaztatu aukeratutako oinarriaren barruan dagoela, gero egiaztatu VPN helmuga adierazgarri baterako bidea ip route get 10.20.30.40-ekin eta egiaztatu espero duzun lekura doala, zubi batera joan beharrean. Probatu zerbitzuen aurkikuntza eta edukiontzien arteko komunikazioa ere, helbideratze ezberdinarekin birsortutako sare batek izenen ebazpena hauts baititzake aplikazio-errore itxura duten moduetan.

Zer hausten da oraindik geroago

Zati iraunkorra erregistroa da. Gorde esleipen-zerrenda, aukeratutako oinarria eta tamaina, eta birsortutako sareak hedapenarekin leku berean.

Barruti bat pribatua izateak ez du berrerabiltzeko seguru egiten. 10.0.0.0/8 pribatua da eta, aldi berean, bidean nonbait jada erabiltzen ari den gauzarik probableena, horregatik erantzuna erreserba zehatz bat da, ez bloke bakarrerako lehentasuna. Docker-en sare-dokumentazioak azpisareen esleipen automatikoa eta poolaren eremuak deskribatzen ditu. Aukeratu barrutia iritsi behar duzunetik, ez itxura onekoa denetik.