Docker pool pārklāšanās kļūda nav VPN maršruta problēma

Docker atsakās izveidot tīklu ar paziņojumu, ka pool pārklājas ar citu šajā adrešu telpā, un kāds nolemj, ka VPN maršrutam jābūt cēlonim. Tas nevar būt. Šī kļūda rodas, kamēr pool tiek piešķirts, pirms pastāv pat viena pakete, un manuāls kodola maršruts uz to neietekmē. VPN ir svarīgs vienu soli vēlāk, kad konteiners, kuram jau ir adrese, pēc maršruta parādīšanās kļūst nesasniedzams. Divas problēmas, divas pierādījumu kopas, un to sajaukšana rada izmaiņas, kas nesalabo nevienu.

Divas līdzīgas kļūdas

Piešķiršanas kļūda ir aritmētiska. Docker salīdzina pieprasīto apakštīklu ar tiem, kurus tas jau pārvalda, atrod krustojumu un atsakās. Nekas vēl nedarbojas, tāpēc nav maršruta, nav konteinera un nav satiksmes, ko pārbaudīt.

Darbības laika simptoms ir sasniedzamības jautājums. Konteiners, kas vakar atbildēja, tagad neatbild, un kaut kas ir mainījies resursdatora maršrutēšanas tabulā. Konteiners joprojām tur savu adresi; jautājums ir, kuru ceļu šī adrese izvēlas.

Abas ir adrešu plāna problēmas. Tikai viena no tām ir Docker problēma.

Vispirms izlasiet piešķirtos pool

Uzskaitiet tīklus un pārbaudiet tos, kuri varētu krustoties. Apakštīkls atrodas IPAM konfigurācijā, un pievienotie konteineri ir uzskaitīti atsevišķi:

docker network ls
docker network inspect EXISTING_NETWORK

Salīdziniet šo apakštīklu ar pool, ko pieprasa jaunais tīkls, un atcerieties, ka Compose katram projektam izveido savu noklusējuma tīklu. Konflikts ar aizmirstu projektu izskatās tieši tāpat kā konflikts ar dēmonu.

Statiska ipv4_address servisā ir viena konteinera adrese, nevis pool definīcija. To mainot, pārklāšanās nepazūd, jo pārklāšanās ir starp tīklu apakštīkliem, nevis starp konteineriem. Docker network-create atsauce parastai tilta piešķiršanai pieprasa nepārklājošus apakštīklus un dokumentē, kā vienu skaidri izvēlēties.

Izvēlieties prefiksu, kas pārdzīvo VPN

Tūlītējo konfliktu un nākotnes maršrutu nosaka viena un tā pati izvēle, tāpēc izdariet to vienreiz. Salīdziniet kandidāta diapazonu ar LAN, ar katru VPN galamērķi, ko resursdators var sasniegt, un ar jebkuru citu lietoto overlay.

Prefikss, kas apmierina Docker un saduras ar attālo tīklu, dod konteineru, kas sākas tīri un kļūst nesasniedzams tajā mirklī, kad tunelis paceļas. Tā ir otrā kļūda šajā rakstā, un to daudz grūtāk diagnosticēt vēlāk nekā izvairīties tagad.

Pierakstiet izvēlētos diapazonus vietā, no kurienes nākamais projekts tos varēs izlasīt. Vienas rindas piešķirto prefiksu reģistrs ir lētāks par nedēļu neizskaidrotu taimautu.

Apzināti izņemiet vai mainiet tīklu

Jaunam Compose tīklam iestatiet neizmantoto prefiksu tīkla IPAM konfigurācijā. Esošam projektam plānojiet pārnumurēšanu: fiksētās adreses, atkarīgie servisi un tīkla atkārtotas izveides solis visi ir jāņem vērā, jo YAML rediģēšana pārnumurē darbībā esošu tīklu.

Ja novecojis tīkls pārvalda konfliktējošo piešķīrumu, pirms tā noņemšanas pārbaudiet, kas ir pievienots. docker network rm atsakās, kamēr pastāv aktīvi endpoint, un docker stop pieņem konteineru nosaukumus vai ID, nevis tīkla nosaukumu. Konteinera apturēšana arī nenoņem tīkla definīciju, kas tur pool.

Plašs prune nav diagnostikas rīks. Tas sasniedz nesaistītus projektus un iznīcina pierādījumus, kurus tikko grasījāties vākt.

Noklusējuma pool palīdz tikai nākamajai piešķiršanai

Dēmona noklusējuma adrešu pool iestatījums uzlabo nākotnes automātiskās piešķiršanas, turot tās ārpus diapazoniem, kurus rezervējat. Tas retroaktīvi nepārnumurē jau esošus tīklus, un tas neatrisina skaidru apakštīklu, kas pārklājas ar citu skaidru apakštīklu.

Uztveriet šo iestatījumu kā atsevišķu, plānotu izmaiņu ar savu restartu, nevis kā viena projekta labošanas daļu. Abu sajaukšana nozīmē, ka dēmona restarts iekrīt nesaistītas izmeklēšanas vidū. Ieplānojiet to savā logā. Pēc tam apstipriniet, ka viena jauna automātiskā piešķiršana patiešām nonāk ārpus rezervētajiem diapazoniem.

Kad izveide izdodas, pārbaudiet apakštīklu, kas faktiski darbojas, un pēc tam veiciet vienu reālu lietojumprogrammas pieprasījumu, kad VPN ir paredzētajā stāvoklī. Ja pool ir derīgs un piekļuve joprojām neizdodas, atlikušais darbs ir maršruta izvēle, filtrēšana un atgriešanās ceļš. Tā ir darbības laika izmeklēšana, un tā nepadara piešķiršanas kļūdu retroaktīvi bezjēdzīgu.

Darba kārtība: izlasiet piešķirtos pool, izvēlieties prefiksu, kas apiet gan Docker, gan VPN galamērķus, apzināti izveidojiet tīklu no jauna, pēc tam pārbaudiet vienu pieprasījumu ar paceltu tuneli.