Docker sin pool-overlappfeil er ikkje eit VPN-ruteproblem

Docker nektar å opprette eit nettverk med meldinga om at poolen overlappar ein annan i dette adresserommet, og nokon bestemmer at VPN-ruta må vere årsaka. Det kan ho ikkje vere. Den feilen oppstår medan ein pool blir tildelt, før ein einaste pakke finst, og ei manuell kjernerute har inga innverknad på han. VPN tel eitt steg seinare, når ein container som alt har ei adresse sluttar å vere tilgjengeleg etter at ei rute dukkar opp. To problem, to sett med prov, og å blande dei gir ei endring som ikkje reparerer nokon av dei.

To feil som ser like ut

Tildelingsfeilen er aritmetisk. Docker samanliknar subnettet du bad om med subnetta det alt administrerer, finn eit snitt og nektar. Ingenting køyrer enno, så det finst inga rute, ingen container og ingen trafikk å granske.

Driftssymptomet er eit spørsmål om tilgjenge. Ein container som svara i går, svarar ikkje no, og noko har endra seg i rutetabellen til verten. Containeren held framleis på adressa si; spørsmålet er kva veg den adressa tek.

Begge er adresseplanproblem. Berre det eine er eit Docker-problem.

Les dei tildelte poolane først

List nettverka og gransk dei som kan overlappe. Subnettet bur i IPAM-konfigurasjonen, og dei tilkopla containerane blir lista separat:

docker network ls
docker network inspect EXISTING_NETWORK

Samanlikn det subnettet med poolen det nye nettverket ber om, og hugs at Compose opprettar sitt eige standardnettverk per prosjekt. Ein konflikt med eit prosjekt du har gløymt, ser nøyaktig ut som ein konflikt med daemonen.

Ein statisk ipv4_address på ein teneste er adressa til éin container, ikkje pooldefinisjonen. Å endre han fjernar ikkje ein overlapping, fordi overlappinga er mellom nettverkssubnett og ikkje mellom containerar. Docker sin network-create-referanse krev ikkje-overlappande subnett for vanleg bru-tildeling og dokumenterer korleis ein vel eitt eksplisitt.

Vel eit prefiks som overlever VPN

Den umiddelbare konflikten og den framtidige ruta blir avgjorde av det same valet, så tak det éin gong. Samanlikn kandidatområdet med LAN, med kvar VPN-destinasjon verten kan nå, og med kvar annan overlay som er i bruk.

Eit prefiks som gjer Docker nøgd og kolliderer med fjernnettverket, gir deg ein container som startar reint og blir utilgjengeleg i det augneblunken tunnelen er oppe. Det er den andre feilen i denne artikkelen, og han er mykje vanskelegare å diagnostisere seinare enn å unngå no.

Skriv ned dei valde områda ein stad der det neste prosjektet kan lese dei. Eit éinlinjes register over tildelte prefiks er billegare enn ei veke med uforklarlege tidsavbrot.

Trekk eit nettverk tilbake eller endre det med vilje

For eit nytt Compose-nettverk set du det ubrukte prefikset i IPAM-konfigurasjonen til nettverket. For eit eksisterande prosjekt planlegg du omnummereringa: faste adresser, avhengige tenester og steget med å gjenopprette nettverket må alle takast med, fordi redigering av YAML ikkje omnummererer eit køyrande nettverk.

Viss eit utdatert nettverk eig den konfliktfylte tildelinga, gransk kven som er tilkopla før du fjernar det. docker network rm nektar så lenge aktive endepunkt finst, og docker stop tek containernamn eller ID-ar i staden for eit nettverksnamn. Å stoppe ein container fjernar heller ikkje nettverksdefinisjonen som held poolen.

Ein brei prune er ikkje eit diagnoseverktøy. Han når urelaterte prosjekt og øydelegg prova du var i ferd med å samle.

Standardpoolar hjelper berre den neste tildelinga

Innstillinga for standardadressepoolen til daemonen betrar framtidige automatiske tildelingar ved å halde dei utanfor områda du reserverer. Ho gir ikkje eksisterande nettverk nye adresser i ettertid, og ho løyser ikkje eit eksplisitt subnett som overlappar eit anna eksplisitt subnett.

Handter den innstillinga som ei separat, planlagd endring med sin eigen omstart, ikkje som ein del av reparasjonen av eitt prosjekt. Å blande dei to betyr at ein daemon-omstart landar midt i ei urelatert gransking. Planlegg han i sitt eige vindauge. Stadfest deretter at éi ny automatisk tildeling faktisk landar utanfor områda du reserverte.

Når opprettinga lukkast, stadfest subnettet som faktisk køyrer, og gjer deretter éin ekte applikasjonsførespurnad med VPN i den tiltenkte tilstanden. Viss poolen er gyldig og tilgangen framleis feilar, er det gjenverande arbeidet ruteval, filtrering og returvegen. Det er ei driftsgransking, og ho gjer ikkje tildelingsfeilen meiningslaus i ettertid.

Arbeidsrekkjefølgje: les dei tildelte poolane, vel eit prefiks som unngår både Docker og VPN-destinasjonane, gjenopprett nettverket med vilje, og test deretter éin førespurnad med tunnelen oppe.