Docker noklusējuma baseina maiņa tīklus nepārnumurē

default-address-pools maiņa nepārnumurē tīklus, kas jums jau ir, un tieši šīs cerības dēļ rūpīgs plāns pārvēršas negaidītā pārtraukumā. Iestatījums regulē automātisku piešķiršanu tīkliem, kas tiek izveidoti pēc dēmona restartēšanas ar jauno konfigurāciju. Viss, kas jau darbojas, saglabā tam piešķirto apakštīklu, jo šis apakštīkls ir daļa no tīkla saglabātās definīcijas. Mīts ir ērts, jo liek domāt, ka viens labojums novērš katru pārklāšanos, un realitāte ir divdaļīgs darbs: izvēlieties diapazonu, kas patiešām ir brīvs, un pēc tam migrējiet tīklus, kas tādi nav.

Mīts: viena baseina maiņa novērš pārklāšanos

Mītam ir noteikta forma. Kāds izlasa, ka Docker noklusējuma baseinu var mainīt, nomaina to, restartē dēmonu un secina, ka konteineru tīkls vairs nesaduras ar biroja VPN. Vecais tīkls joprojām ir, joprojām pievienots un joprojām tur adresi, kas saduras.

Mainījās piešķīrēja turpmākā uzvedība, kas patiešām ir noderīga un patiešām ierobežota. Jauni tīkli, kas izveidoti bez skaidras --subnet, tiek izgriezti no jaunā baseina; esošie tajā baseinā nekad nav bijuši. Restartēšana nepārbūvē tīklus un nepārvieto konteinerus starp tiem. Ja simptoms saglabājas pēc maiņas, maiņa bija īsta, bet diagnoze bija nepilnīga.

Pamata diapazons un piešķirtais prefikss

Konfigurācijā ir divi lauki, kurus viegli sajaukt. base ir diapazons, no kura piešķīrējs griež, un size ir katra piešķirtā tīkla prefiksa garums, tāpēc bāze 10.10.0.0/16 ar izmēru 24 izdala /24 šajā /16 iekšienē. Lomu apvēršana rada nevēlamu piešķiršanas modeli, parasti vienu milzīgu tīklu vai izsmeltu baseinu.

Baseins ir rezervācija, nevis pierādījums. Docker izvairās no konfliktiem, ko redz resursdatora maršrutēšanas tabulā, un tas nevar redzēt VPN, kuram vēl neesat pievienojies.

Šis ierobežojums ir viss iemesls izvēlēties apzināti. Diapazoni, ar kuriem jāsalīdzina, ir tie, kuriem resursdatoram jāpiekļūst: biroja LAN, uzņēmuma VPN iekšējie apakštīkli, laboratorijas vai staging prefiksi un jebkurš cits konteineru resursdators tajā pašā overlay. Pierakstiet tos kā CIDR pirms dēmona aiztikšanas, jo saraksts galvā palaidīs garām tieši to, kas ir svarīgs. Pēc tam izvēlieties bāzi, kas nepārklājas ar nevienu no tiem, un glabājiet sarakstu kopā ar izvietošanu, lai nākamais cilvēks neatkārtotu vingrinājumu no atmiņas.

Uzskaitiet pirms izvēles

Vispirms uzskaitiet, kas pastāv. docker network ls uzskaita tīklus, un docker network inspect bridge -f '{{.IPAM.Config}}' izdrukā apakštīklu, ko izmanto konkrēts tīkls. Atkārtojiet katram lietotāja definētam tīklam, jo Compose projekti veido savus, un skaidra --subnet compose failā pilnībā apiet baseinu.

Pēdējais punkts ir tas, kas pārdzīvo migrāciju. Baseina maiņa neliedz kolēģim compose failā piespraust 172.18.0.0/16, un konflikts atgriežas ar citu autoru.

Jau esošā migrācija

Esošo tīklu migrācija ir atsevišķa, atbalstīta darbība. Katrs skartais tīkls ir jāizveido no jauna ar jauno apakštīklu, kas nozīmē to izmantojošo konteineru atvienošanu un atkārtotu pievienošanu, un tīkla izveide no jauna noņem tā konteineru piesaistes, nevis pārvieto tās. Saglabājiet sējumus un konfigurāciju un uztveriet izveidi no jauna kā izvietošanu, nevis datu atiestatīšanu. Veiciet darbu apkopes logā, jo atkārtoti izveidotā tīkla konteineri tiek restartēti neatkarīgi no tā, vai to plānojāt.

Ievērojiet dokumentēto dēmona konfigurāciju un restartēšanas procedūru un saskaņojiet pārtraukumu. Resursdatorā ar vienu dēmonu systemctl restart docker restartē konteinerus saskaņā ar to restartēšanas politikām, un tā ir uzvedība, ko vērts zināt pirms, nevis pēc.

Pēc tam pārbaudiet abas lietas, ko maiņai vajadzēja labot. Pārbaudiet jauno apakštīklu ar docker network inspect un apstipriniet, ka tas atrodas izvēlētās bāzes iekšienē, pēc tam pārbaudiet maršrutu uz reprezentatīvu VPN galamērķi ar ip route get 10.20.30.40 un apstipriniet, ka tas iet tur, kur gaidāt, nevis tiltā. Pārbaudiet arī pakalpojumu atklāšanu un konteineru savstarpējo saziņu, jo tīkls, kas atkārtoti izveidots ar citu adresāciju, var salauzt nosaukumu atrisināšanu tā, ka tas izskatās pēc lietojumprogrammas kļūdas.

Kas joprojām lūzt pēc tam

Noturīgā daļa ir ieraksts. Glabājiet piešķīrumu sarakstu, izvēlēto bāzi un izmēru un atkārtoti izveidotos tīklus tajā pašā vietā, kur izvietošanu.

Tas, ka diapazons ir privāts, nepadara to drošu atkārtotai lietošanai. 10.0.0.0/8 ir privāts un vienlaikus visticamāk jau tiek izmantots kaut kur ceļā, tāpēc atbilde ir konkrēta rezervācija, nevis viena bloka izvēle. Docker tīklu dokumentācija apraksta automātisku apakštīklu piešķiršanu un baseina laukus. Izvēlieties diapazonu pēc tā, kam jums jāpiekļūst, nevis pēc tā, kas izskatās kārtīgi.