„Docker“ telkinių persidengimo klaida nėra VPN maršruto problema

„Docker“ atsisako kurti tinklą su pranešimu, kad telkinys persidengia su kitu šioje adresų erdvėje, ir kas nors nusprendžia, kad VPN maršrutas turi būti priežastis. Taip negali būti. Ši klaida atsiranda skirstant telkinį, dar neegzistuojant nė vienam paketui, o rankinis branduolio maršrutas jai jokios įtakos neturi. VPN svarbus vienu žingsniu vėliau, kai konteineris, jau turintis adresą, tampa nepasiekiamas po to, kai atsiranda maršrutas. Dvi problemos, du įrodymų rinkiniai, o juos sumaišius gaunamas pakeitimas, kuris nei vienos nesutvarko.

Dvi panašiai atrodančios klaidos

Skirstymo klaida yra aritmetinė. „Docker“ palygina prašomą potinklį su tais, kuriuos jau valdo, randa sankirtą ir atsisako. Niekas dar neveikia, todėl nėra maršruto, konteinerio ir eismo, kurį būtų galima patikrinti.

Veikimo metu simptomas yra pasiekiamumo klausimas. Konteineris, kuris vakar atsakydavo, dabar neatsako, ir kažkas pasikeitė pagrindinio kompiuterio maršrutizavimo lentelėje. Konteineris vis dar turi savo adresą; klausimas, kokiu keliu šis adresas eina.

Abi yra adresų plano problemos. Tik viena iš jų yra „Docker“ problema.

Pirmiausia perskaitykite paskirstytus telkinius

Išvardykite tinklus ir patikrinkite tuos, kurie galėtų susikirsti. Potinklis yra IPAM konfigūracijoje, o prijungti konteineriai išvardyti atskirai:

docker network ls
docker network inspect EXISTING_NETWORK

Palyginkite tą potinklį su telkiniu, kurio prašo naujas tinklas, ir atsiminkite, kad „Compose“ kiekvienam projektui sukuria savo numatytąjį tinklą. Konfliktas su pamirštu projektu atrodo lygiai taip pat kaip konfliktas su demonu.

Statinis ipv4_address paslaugoje yra vieno konteinerio adresas, o ne telkinio apibrėžimas. Jį pakeitus persidengimas nepradingsta, nes persidengimas yra tarp tinklų potinklių, o ne tarp konteinerių. „Docker“ network-create nuoroda reikalauja nesipersidengiančių potinklių įprastam tiltiniam skirstymui ir dokumentuoja, kaip vieną pasirinkti aiškiai.

Pasirinkite priešdėlį, kuris atlaiko VPN

Tiesioginį konfliktą ir būsimą maršrutą lemia tas pats pasirinkimas, tad padarykite jį kartą. Palyginkite kandidatinį diapazoną su LAN, su kiekviena VPN paskirties vieta, kurią gali pasiekti pagrindinis kompiuteris, ir su bet kokiu kitu naudojamu overlay.

Priešdėlis, kuris tenkina „Docker“ ir susiduria su nuotoliniu tinklu, duoda konteinerį, kuris švariai paleidžiamas ir tampa nepasiekiamas tą akimirką, kai tunelis pakyla. Tai antroji šio straipsnio klaida, ir ją daug sunkiau diagnozuoti vėliau nei išvengti dabar.

Užsirašykite pasirinktus diapazonus ten, kur kitas projektas galės juos perskaityti. Vienos eilutės paskirstytų priešdėlių registras pigesnis nei savaitė nepaaiškinamų laiko limitų.

Sąmoningai atsisakykite tinklo arba jį pakeiskite

Naujam „Compose“ tinklui nustatykite nenaudojamą priešdėlį tinklo IPAM konfigūracijoje. Esamam projektui suplanuokite pernumeravimą: fiksuoti adresai, priklausomos paslaugos ir tinklo atkūrimo žingsnis – į viską reikia atsižvelgti, nes YAML redagavimas nepernumeruoja veikiančio tinklo.

Jei pasenęs tinklas turi konfliktuojantį paskirstymą, prieš jį pašalindami patikrinkite, kas prijungtas. docker network rm atsisako tol, kol yra aktyvių endpointų, o docker stop priima konteinerių pavadinimus ar ID, o ne tinklo pavadinimą. Konteinerio sustabdymas taip pat nepašalina tinklo apibrėžimo, kuriame laikomas telkinys.

Platus prune nėra diagnostikos įrankis. Jis pasiekia nesusijusius projektus ir sunaikina įrodymus, kuriuos ketinote rinkti.

Numatytieji telkiniai padeda tik kitam skirstymui

Demono numatytojo adresų telkinio nustatymas pagerina būsimus automatinius skirstymus, laikydamas juos už jūsų rezervuojamų diapazonų. Jis retroaktyviai neperadresuoja jau esamų tinklų, ir neišsprendžia aiškaus potinklio, kuris persidengia su kitu aiškiu potinkliu.

Traktuokite šį nustatymą kaip atskirą, suplanuotą pakeitimą su savo perkrovimu, o ne kaip vieno projekto taisymo dalį. Sumaišius abu, demono perkrovimas patenka į nesusijusio tyrimo vidurį. Suplanuokite jį atskirame laiko intervale. Tada patvirtinkite, kad vienas naujas automatinis skirstymas tikrai patenka už rezervuotų diapazonų.

Kai sukūrimas pavyksta, patikrinkite iš tikrųjų veikiantį potinklį ir tada atlikite vieną tikrą programos užklausą, kai VPN yra numatytoje būsenoje. Jei telkinys galioja, o prieiga vis tiek nepavyksta, likęs darbas yra maršruto parinkimas, filtravimas ir grįžtamasis kelias. Tai veikimo metu atliekamas tyrimas, ir jis nepaneigia skirstymo klaidos atgaline data.

Darbo tvarka: perskaitykite paskirstytus telkinius, pasirinkite priešdėlį, kuris apeina ir „Docker“, ir VPN paskirties vietas, sąmoningai iš naujo sukurkite tinklą, tada išbandykite vieną užklausą su pakeltu tuneliu.