Docker numatytojo telkinio keitimas tinklų nepernumeruoja

default-address-pools pakeitimas nepernumeruoja tinklų, kuriuos jau turite, ir būtent to tikėjimasis paverčia kruopštų planą netikėtu sutrikimu. Nustatymas valdo automatinį paskirstymą tinklams, sukuriamiems po to, kai tarnyba paleidžiama iš naujo su nauja konfigūracija. Viskas, kas jau veikia, išlaiko jai skirtą potinklį, nes tas potinklis yra išsaugotos tinklo apibrėžties dalis. Mitas patogus, nes siūlo, kad vienas pakeitimas sutvarko kiekvieną persidengimą, o tikrovė – dviejų dalių darbas: pasirinkite diapazoną, kuris tikrai laisvas, tada migruokite tinklus, kurie tokie nėra.

Mitas: vienas telkinio pakeitimas sutvarko persidengimą

Mitas turi konkrečią formą. Kažkas perskaito, kad Docker numatytąjį telkinį galima pakeisti, pakeičia jį, paleidžia tarnybą iš naujo ir padaro išvadą, kad konteinerių tinklas nebesikerta su biuro VPN. Senasis tinklas vis dar yra, vis dar prijungtas ir vis dar laiko adresą, kuris kertasi.

Pasikeitė būsimas skirstytuvo elgesys, kuris tikrai naudingas ir tikrai ribotas. Nauji tinklai, sukurti be aiškaus --subnet, išpjaunami iš naujo telkinio; esami tame telkinyje niekada nebuvo. Paleidimas iš naujo neperstato tinklų ir neperkelia konteinerių tarp jų. Jei simptomas išlieka po pakeitimo, pakeitimas buvo tikras, o diagnozė – nepilna.

Bazinis diapazonas ir skirtas priešdėlis

Konfigūracijoje yra du laukai, kuriuos lengva supainioti. base yra diapazonas, iš kurio skirstytuvas pjauna, o size yra kiekvieno skirto tinklo priešdėlio ilgis, todėl bazė 10.10.0.0/16 su dydžiu 24 išdalija /24 tame /16 viduje. Sukeitus vaidmenis gaunamas neplanuotas paskirstymo modelis, dažniausiai vienas didžiulis tinklas arba išsekęs telkinys.

Telkinys yra rezervacija, ne įrodymas. Docker vengia konfliktų, kuriuos mato pagrindinio kompiuterio maršrutizavimo lentelėje, ir negali matyti VPN, prie kurio dar neprisijungėte.

Šis apribojimas yra visa priežastis rinktis sąmoningai. Diapazonai, su kuriais reikia lyginti, yra tie, kuriuos pagrindinis kompiuteris turi pasiekti: biuro LAN, įmonės VPN vidiniai potinkliai, laboratorijos ar staging priešdėliai ir bet kuris kitas konteinerių kompiuteris tame pačiame overlay. Užsirašykite juos kaip CIDR prieš liesdami tarnybą, nes sąrašas galvoje praleis būtent tą, kuris svarbus. Tada pasirinkite bazę, kuri nesikerta su nė vienu, ir laikykite sąrašą kartu su diegimu, kad kitas žmogus nekartotų pratimo iš atminties.

Surašykite prieš rinkdamiesi

Pirmiausia surašykite, kas egzistuoja. docker network ls išvardija tinklus, o docker network inspect bridge -f '{{.IPAM.Config}}' išspausdina potinklį, kurį naudoja konkretus tinklas. Pakartokite kiekvienam vartotojo apibrėžtam tinklui, nes Compose projektai kuria savo, o aiškus --subnet compose faile visiškai apeina telkinį.

Paskutinis punktas yra tas, kuris išgyvena migraciją. Telkinio pakeitimas nesustabdys kolegos prisegti 172.18.0.0/16 compose faile, ir konfliktas grįžta su kitu autoriumi.

Jau esančių tinklų migracija

Esamų tinklų migracija yra atskira, palaikoma operacija. Kiekvienas paveiktas tinklas turi būti sukurtas iš naujo su nauju potinkliu, o tai reiškia jį naudojančių konteinerių atjungimą ir prijungimą iš naujo, ir tinklo sukūrimas iš naujo pašalina jo konteinerių prijungimus, o ne perkelia juos. Išsaugokite tomus ir konfigūraciją, o sukūrimą iš naujo traktuokite kaip diegimą, ne kaip duomenų atstatymą. Darbą atlikite techninės priežiūros lange, nes iš naujo sukurto tinklo konteineriai bus paleisti iš naujo nepriklausomai nuo to, ar tai planavote.

Laikykitės dokumentuotos tarnybos konfigūracijos ir paleidimo iš naujo procedūros, ir suderinkite pertraukimą. Kompiuteryje su viena tarnyba systemctl restart docker paleidžia konteinerius iš naujo pagal jų paleidimo taisykles, ir tai elgsena, kurią verta žinoti prieš, o ne po.

Tada patikrinkite du dalykus, kuriuos pakeitimas turėjo sutvarkyti. Patikrinkite naują potinklį su docker network inspect ir patvirtinkite, kad jis yra pasirinktos bazės viduje, tada patikrinkite maršrutą į reprezentatyvią VPN paskirties vietą su ip route get 10.20.30.40 ir patvirtinkite, kad jis eina ten, kur tikitės, o ne į tiltą. Išbandykite ir paslaugų atradimą bei konteinerių tarpusavio ryšį, nes tinklas, sukurtas iš naujo su kitu adresavimu, gali sugadinti vardų skyrimą taip, kad atrodo kaip programos klaida.

Kas vis dar lūžta po to

Ilgalaikė dalis yra įrašas. Laikykite paskirstymo sąrašą, pasirinktą bazę ir dydį bei iš naujo sukurtus tinklus toje pačioje vietoje kaip diegimą.

Tai, kad diapazonas yra privatus, nepadaro jo saugaus pakartotiniam naudojimui. 10.0.0.0/8 yra privatus ir kartu labiausiai tikėtina, kad jau naudojamas kažkur kelyje, todėl atsakymas yra konkreti rezervacija, o ne vieno bloko pirmenybė. Docker tinklų dokumentacija aprašo automatinį potinklių paskirstymą ir telkinio laukus. Rinkitės diapazoną pagal tai, ką turite pasiekti, o ne pagal tai, kas atrodo tvarkingai.