Ndryshimi i pishinës parazgjedhur të Docker nuk i rinumëron rrjetet

Ndryshimi i default-address-pools nuk i rinumëron rrjetet që keni tashmë, dhe pritja e kësaj është pikërisht mënyra se si një plan i kujdesshëm kthehet në një ndërprerje të papritur. Cilësimi rregullon shpërndarjen automatike për rrjetet e krijuara pasi daemon-i riniset me konfigurimin e ri. Gjithçka që punon tashmë e mban nënrrjetin që iu dha, sepse ai nënrrjet është pjesë e përcaktimit të ruajtur të rrjetit. Miti është i përshtatshëm sepse sugjeron se një ndryshim i vetëm rregullon çdo mbivendosje, dhe realiteti është një punë në dy pjesë: zgjidhni një interval që është vërtet i lirë, më pas migroni rrjetet që nuk janë.

Miti: një ndryshim i pishinës rregullon mbivendosjen

Miti ka një formë të caktuar. Dikush lexon se pishina parazgjedhur e Docker mund të ndryshohet, e ndryshon, rinis daemon-in dhe përfundon se rrjeti i kontejnerëve nuk përplaset më me VPN-në e zyrës. Rrjeti i vjetër është ende atje, ende i lidhur dhe ende mban adresën që përplaset.

Ajo që ndryshoi është sjellja e ardhshme e shpërndarësit, e cila është vërtet e dobishme dhe vërtet e kufizuar. Rrjetet e reja të krijuara pa një --subnet të qartë priten nga pishina e re; ato ekzistuese nuk kanë qenë kurrë në atë pishinë. Rinisja nuk i rindërton rrjetet dhe nuk i lëviz kontejnerët mes tyre. Nëse simptoma vazhdon pas ndryshimit, ndryshimi ishte i vërtetë dhe diagnoza ishte e paplotë.

Intervali bazë dhe parashtesa e shpërndarë

Konfigurimi ka dy fusha që ngatërrohen lehtë. base është intervali nga i cili pret shpërndarësi, dhe size është gjatësia e parashtesës së çdo rrjeti të shpërndarë, kështu që një bazë 10.10.0.0/16 me madhësi 24 shpërndan /24 brenda atij /16. Ndërrimi i roleve prodhon një model shpërndarjeje që nuk e kishit menduar, zakonisht një rrjet i vetëm gjigant ose një pishinë e shteruar.

Një pishinë është një rezervim, jo një provë. Docker shmang konfliktet që sheh në tabelën e rrugëzimit të hostit dhe nuk mund të shohë një VPN me të cilën nuk jeni lidhur ende.

Ky kufizim është i gjithë arsyeja për të zgjedhur me vetëdije. Intervalet për t'u krahasuar janë ato që hosti duhet të arrijë: LAN-i i zyrës, nënrrjetet e brendshme të VPN-së korporative, parashtesat e laboratorit ose të staging dhe çdo host tjetër kontejnerësh në të njëjtin overlay. Shkruajini ato si CIDR përpara se të prekni daemon-in, sepse një listë në kokë do të harrojë pikërisht atë që ka rëndësi. Pastaj zgjidhni një bazë që nuk mbivendoset me asnjë prej tyre, dhe mbajeni listën bashkë me vendosjen në prodhim që personi tjetër të mos e përsëritë ushtrimin nga kujtesa.

Inventarizoni përpara se të zgjidhni

Fillimisht inventarizoni çfarë ekziston. docker network ls i liston rrjetet, dhe docker network inspect bridge -f '{{.IPAM.Config}}' shtyp nënrrjetin që përdor një rrjet i caktuar. Përsëriteni për çdo rrjet të përcaktuar nga përdoruesi, sepse projektet Compose krijojnë të vetat dhe një --subnet i qartë në një skedar compose e anashkalon plotësisht pishinën.

Pika e fundit është ajo që i mbijeton migrimit. Një ndryshim i pishinës nuk e pengon një koleg të fiksojë 172.18.0.0/16 në një skedar compose, dhe konflikti kthehet me një autor tjetër.

Migrimi i asaj që ekziston tashmë

Migrimi i rrjeteve ekzistuese është një operacion i veçantë dhe i mbështetur. Çdo rrjet i prekur duhet të rikrijohet me nënrrjetin e ri, që do të thotë të shkëputen dhe të rilidhen kontejnerët që e përdorin, dhe rikrijimi i një rrjeti i heq lidhjet e kontejnerëve në vend që t'i lëvizë. Ruani vëllimet dhe konfigurimin dhe trajtoni rikrijimin si një vendosje në prodhim, jo si një rivendosje të dhënash. Bëjeni punën në një dritare mirëmbajtjeje, sepse kontejnerët në një rrjet të rikrijuar rinisin pavarësisht nëse e kishit planifikuar.

Ndiqui konfigurimin e dokumentuar të daemon-it dhe procedurën e rinisjes, dhe koordinoni ndërprerjen. Në një host me një daemon të vetëm, systemctl restart docker i rinis kontejnerët sipas politikave të tyre të rinisjes, dhe kjo është një sjellje që ia vlen ta dish përpara dhe jo pas.

Më pas verifikoni dy gjërat që ndryshimi duhej të rregullonte. Inspektoni nënrrjetin e ri me docker network inspect dhe konfirmoni se ndodhet brenda bazës së zgjedhur, më pas kontrolloni rrugën drejt një destinacioni përfaqësues VPN me ip route get 10.20.30.40 dhe konfirmoni se shkon atje ku prisni dhe jo në një urë. Testoni gjithashtu zbulimin e shërbimeve dhe komunikimin mes kontejnerëve, sepse një rrjet i rikrijuar me adresim tjetër mund të prishë zgjidhjen e emrave në mënyra që duken si gabim aplikacioni.

Çfarë prishet ende pas kësaj

Pjesa e qëndrueshme është regjistri. Mbani listën e shpërndarjeve, bazën dhe madhësinë e zgjedhur, dhe rrjetet e rikrijuara në të njëjtin vend si vendosja në prodhim.

Fakti që një interval është privat nuk e bën të sigurt për ripërdorim. 10.0.0.0/8 është privat dhe njëkohësisht gjëja më e mundshme që tashmë është në përdorim diku në rrugë, prandaj përgjigja është një rezervim konkret dhe jo një preferencë për një bllok. Dokumentacioni i rrjeteve të Docker përshkruan shpërndarjen automatike të nënrrjeteve dhe fushat e pishinës. Zgjidhni intervalin nga ajo që duhet të arrini, jo nga ajo që duket e rregullt.