Dockers feil om pooloverlapping er ikke et VPN-ruteproblem

Docker nekter å opprette et nettverk med meldingen om at poolen overlapper med en annen i dette adresserommet, og noen bestemmer at VPN-ruten må være årsaken. Det kan den ikke være. Den feilen oppstår mens en pool tildeles, før en eneste pakke eksisterer, og en manuell kjernerute har ingen innvirkning på den. VPN betyr noe ett steg senere, når en container som allerede har en adresse slutter å være tilgjengelig etter at en rute dukker opp. To problemer, to sett med bevis, og å blande dem gir en endring som ikke reparerer noen av dem.

To feil som ser like ut

Tildelingsfeilen er aritmetisk. Docker sammenligner subnettet du ba om med subnettene det allerede administrerer, finner et snitt og nekter. Ingenting kjører ennå, så det finnes ingen rute, ingen container og ingen trafikk å undersøke.

Driftssymptomet er et spørsmål om tilgjengelighet. En container som svarte i går, svarer ikke nå, og noe har endret seg i vertens rutetabell. Containeren beholder fortsatt adressen sin; spørsmålet er hvilken vei den adressen tar.

Begge er adresseplanproblemer. Bare det ene er et Docker-problem.

Les de tildelte poolene først

List nettverkene og undersøk dem som kan overlappe. Subnettet bor i IPAM-konfigurasjonen, og de tilkoblede containerne listes separat:

docker network ls
docker network inspect EXISTING_NETWORK

Sammenlign det subnettet med poolen det nye nettverket ber om, og husk at Compose oppretter sitt eget standardnettverk per prosjekt. En konflikt med et prosjekt du har glemt, ser nøyaktig ut som en konflikt med daemonen.

En statisk ipv4_address på en tjeneste er én containers adresse, ikke pooldefinisjonen. Å endre den fjerner ikke en overlapping, fordi overlappingen er mellom nettverkssubnetter og ikke mellom containere. Dockers network-create-referanse krever ikke-overlappende subnetter for vanlig brotildeling og dokumenterer hvordan man velger ett eksplisitt.

Velg et prefiks som overlever VPN

Den umiddelbare konflikten og den fremtidige ruten avgjøres av det samme valget, så ta det én gang. Sammenlign kandidatområdet med LAN, med hver VPN-destinasjon verten kan nå, og med enhver annen overlay som er i bruk.

Et prefiks som tilfredsstiller Docker og kolliderer med fjernnettverket, gir deg en container som starter rent og blir utilgjengelig i det øyeblikket tunnelen er oppe. Det er den andre feilen i denne artikkelen, og den er mye vanskeligere å diagnostisere senere enn å unngå nå.

Skriv ned de valgte områdene et sted der det neste prosjektet kan lese dem. Et énlinjes register over tildelte prefikser er billigere enn en uke med uforklarlige tidsavbrudd.

Trekk tilbake eller endre et nettverk med vilje

For et nytt Compose-nettverk setter du det ubrukte prefikset i nettverkets IPAM-konfigurasjon. For et eksisterende prosjekt planlegger du omnummereringen: faste adresser, avhengige tjenester og trinnet med å gjenopprette nettverket må alle tas med, fordi redigering av YAML ikke omnummererer et kjørende nettverk.

Hvis et utdatert nettverk eier den konfliktfylte tildelingen, undersøk hvem som er tilkoblet før du fjerner det. docker network rm nekter så lenge aktive endepunkter finnes, og docker stop tar containernavn eller ID-er i stedet for et nettverksnavn. Å stoppe en container fjerner heller ikke nettverksdefinisjonen som holder poolen.

En bred prune er ikke et diagnoseverktøy. Den når urelaterte prosjekter og ødelegger bevisene du var i ferd med å samle.

Standardpooler hjelper bare den neste tildelingen

Daemonens innstilling for standardadressepool forbedrer fremtidige automatiske tildelinger ved å holde dem utenfor områdene du reserverer. Den gir ikke eksisterende nettverk nye adresser i ettertid, og den løser ikke et eksplisitt subnett som overlapper et annet eksplisitt subnett.

Behandle den innstillingen som en separat, planlagt endring med sin egen omstart, ikke som en del av reparasjonen av ett prosjekt. Å blande de to betyr at en daemon-omstart lander midt i en urelatert undersøkelse. Planlegg den i sitt eget vindu. Bekreft deretter at én ny automatisk tildeling faktisk lander utenfor områdene du reserverte.

Når opprettelsen lykkes, verifiser subnettet som faktisk kjører, og gjør deretter én ekte applikasjonsforespørsel med VPN i den tiltenkte tilstanden. Hvis poolen er gyldig og tilgangen fortsatt feiler, er det gjenstående arbeidet rutevalg, filtrering og returveien. Det er en driftsundersøkelse, og den gjør ikke tildelingsfeilen meningsløs i ettertid.

Arbeidsrekkefølge: les de tildelte poolene, velg et prefiks som unngår både Docker og VPN-destinasjonene, gjenopprett nettverket med vilje, og test deretter én forespørsel med tunnelen oppe.