Promjena zadanog Dockerovog bazena ne prenumerira mreže

Promjena default-address-pools ne prenumerira mreže koje već imate, a očekivanje da hoće pretvara pažljiv plan u iznenadni prekid. Postavka upravlja automatskom dodjelom za mreže stvorene nakon ponovnog pokretanja daemona s novom konfiguracijom. Sve što već radi zadržava dodijeljenu podrežu, jer je ta podreža dio spremljene definicije mreže. Mit je zgodan jer sugerira da jedna izmjena rješava svaki sukob, a stvarnost je posao u dva dijela: odaberite raspon koji je doista slobodan, zatim migrirajte mreže koje nisu.

Mit: jedna promjena bazena rješava sukob

Mit ima određen oblik. Netko pročita da se Dockerov zadani bazen može promijeniti, promijeni ga, ponovno pokrene daemon i zaključi da se kontejnerska mreža više ne sukobljava s uredskim VPN-om. Stara mreža još je tu, još je povezana i još drži adresu koja se sukobljava.

Promijenilo se buduće ponašanje dodjeljivača, što je doista korisno i doista ograničeno. Nove mreže stvorene bez izričitog --subnet izrezuju se iz novog bazena; postojeće nikada nisu bile u tom bazenu. Ponovno pokretanje ne obnavlja mreže i ne premješta kontejnere među njima. Ako simptom potraje nakon promjene, promjena je bila stvarna, a dijagnoza nepotpuna.

Osnovni raspon i dodijeljeni prefiks

Konfiguracija ima dva polja koja je lako zamijeniti. base je raspon iz kojeg dodjeljivač izrezuje, a size je duljina prefiksa svake dodijeljene mreže, pa osnova 10.10.0.0/16 s veličinom 24 dijeli /24 unutar tog /16. Zamijenjene uloge daju obrazac dodjele koji niste namjeravali, obično jednu golemu mrežu ili iscrpljen bazen.

Bazen je rezervacija, ne dokaz. Docker izbjegava sukobe koje vidi u usmjerivačkoj tablici hosta i ne može vidjeti VPN na koji se još niste povezali.

To je ograničenje cijeli razlog za svjestan odabir. Rasponi za usporedbu su oni do kojih host mora doći: uredski LAN, interne podreže korporativnog VPN-a, prefiksi laboratorija ili staginga i bilo koji drugi kontejnerski host na istom overlayu. Zapišite ih kao CIDR-ove prije nego dirnete daemon, jer će popis u glavi propustiti onaj koji je važan. Zatim odaberite osnovu koja se ne preklapa ni s jednim i držite popis uz implementaciju da sljedeća osoba ne ponavlja vježbu po sjećanju.

Popišite prije odabira

Prvo popišite što postoji. docker network ls navodi mreže, a docker network inspect bridge -f '{{.IPAM.Config}}' ispisuje podrežu koju određena mreža koristi. Ponovite za svaku mrežu koju je definirao korisnik, jer Compose projekti stvaraju vlastite, a izričiti --subnet u compose datoteci potpuno zaobilazi bazen.

Ta posljednja točka preživljava migraciju. Promjena bazena ne sprječava kolegu da prikuca 172.18.0.0/16 u compose datoteku, a sukob se vraća s drugim autorom.

Migracija onoga što već postoji

Migracija postojećih mreža zasebna je, podržana operacija. Svaku zahvaćenu mrežu treba ponovno stvoriti s novom podrežom, što znači odvojiti i ponovno pripojiti kontejnere koji je koriste, a ponovno stvaranje mreže uklanja njezine kontejnerske pripoje umjesto da ih premješta. Sačuvajte volumene i konfiguraciju i tretirajte ponovno stvaranje kao implementaciju, a ne kao reset podataka. Radite u prozoru za održavanje, jer se kontejneri na ponovno stvorenoj mreži ponovno pokreću bez obzira na to jeste li to planirali.

Slijedite dokumentiranu konfiguraciju daemona i postupak ponovnog pokretanja te uskladite prekid. Na hostu s jednim daemonom systemctl restart docker ponovno pokreće kontejnere prema njihovim pravilima ponovnog pokretanja, a to je ponašanje koje vrijedi znati prije, a ne poslije.

Zatim provjerite dvije stvari koje je promjena trebala popraviti. Pregledajte novu podrežu s docker network inspect i potvrdite da je unutar odabrane osnove, zatim provjerite rutu do reprezentativnog VPN odredišta s ip route get 10.20.30.40 i potvrdite da ide kamo očekujete, a ne u most. Testirajte i otkrivanje usluga i komunikaciju kontejner-kontejner, jer mreža ponovno stvorena s drukčijim adresiranjem može slomiti razrješavanje imena na način koji izgleda kao greška aplikacije.

Što se i dalje kvari nakon toga

Trajni dio je zapis. Držite popis dodjela, odabranu osnovu i veličinu te ponovno stvorene mreže na istom mjestu kao i implementaciju.

To što je raspon privatan ne čini ga sigurnim za ponovnu upotrebu. 10.0.0.0/8 je privatan i ujedno najvjerojatnije već u upotrebi negdje na putu, zato je odgovor konkretna rezervacija, a ne sklonost jednom bloku. Dockerova dokumentacija o mrežama opisuje automatsku dodjelu podreža i polja bazena. Odaberite raspon prema onome do čega morate doći, a ne prema onome što izgleda uredno.