Schimbarea pool-ului implicit Docker nu renumerotează rețelele

Schimbarea default-address-pools nu renumerotează rețelele pe care le aveți deja, iar așteptarea aceasta este exact felul în care un plan atent devine o întrerupere neașteptată. Setarea guvernează alocarea automată pentru rețelele create după ce daemonul repornește cu noua configurație. Tot ce rulează deja își păstrează subrețeaua primită, pentru că acea subrețea face parte din definiția stocată a rețelei. Mitul este comod pentru că sugerează că o singură modificare repară fiecare suprapunere, iar realitatea este o muncă în două părți: alegeți un interval cu adevărat liber, apoi migrați rețelele care nu sunt.

Mitul: o singură schimbare a pool-ului repară suprapunerea

Mitul are o formă anume. Cineva citește că pool-ul implicit al Docker poate fi schimbat, îl schimbă, repornește daemonul și conchide că rețeaua de containere nu mai intră în conflict cu VPN-ul biroului. Rețeaua veche este încă acolo, încă atașată și încă deține adresa care intră în conflict.

Ce s-a schimbat este comportamentul viitor al alocatorului, care este cu adevărat util și cu adevărat limitat. Rețelele noi create fără un --subnet explicit sunt decupate din noul pool; cele existente nu au fost niciodată în acel pool. O repornire nu reconstruiește rețelele și nu mută containere între ele. Dacă simptomul persistă după schimbare, schimbarea a fost reală, iar diagnosticul incomplet.

Interval de bază și prefix alocat

Configurația are două câmpuri ușor de confundat. base este intervalul din care decupează alocatorul, iar size este lungimea prefixului fiecărei rețele alocate, așa că o bază 10.10.0.0/16 cu dimensiunea 24 distribuie /24 în interiorul acelui /16. Inversarea rolurilor produce un model de alocare nedorit, de obicei o singură rețea uriașă sau un pool epuizat.

Un pool este o rezervare, nu o dovadă. Docker evită conflictele pe care le vede în tabela de rutare a gazdei și nu poate vedea un VPN la care nu v-ați conectat încă.

Această limitare este întregul motiv de a alege deliberat. Intervalele de comparat sunt cele pe care gazda trebuie să le atingă: LAN-ul biroului, subrețelele interne ale VPN-ului corporativ, prefixele laboratorului sau de staging și orice altă gazdă de containere din același overlay. Scrieți-le ca CIDR înainte de a atinge daemonul, pentru că o listă din memorie va rata exact pe cea care contează. Apoi alegeți o bază care nu se suprapune cu niciuna dintre ele și păstrați lista împreună cu implementarea, ca următoarea persoană să nu repete exercițiul din memorie.

Inventariați înainte de a alege

Mai întâi inventariați ce există. docker network ls listează rețelele, iar docker network inspect bridge -f '{{.IPAM.Config}}' afișează subrețeaua folosită de o rețea anume. Repetați pentru fiecare rețea definită de utilizator, pentru că proiectele Compose își creează propriile rețele, iar un --subnet explicit într-un fișier compose ocolește complet pool-ul.

Ultimul punct este cel care supraviețuiește migrării. O schimbare a pool-ului nu împiedică un coleg să fixeze 172.18.0.0/16 într-un fișier compose, iar conflictul revine cu un alt autor.

Migrarea a ceea ce există deja

Migrarea rețelelor existente este o operațiune separată și acceptată. Fiecare rețea afectată trebuie recreată cu noua subrețea, ceea ce înseamnă detașarea și reatașarea containerelor care o folosesc, iar recrearea unei rețele elimină atașamentele de containere în loc să le mute. Păstrați volumele și configurația și tratați recrearea ca o implementare, nu ca o resetare de date. Faceți munca într-o fereastră de mentenanță, pentru că containerele dintr-o rețea recreată repornesc indiferent dacă ați planificat asta.

Urmați configurația daemonului și procedura de repornire documentate și coordonați întreruperea. Pe o gazdă cu un singur daemon, systemctl restart docker repornește containerele conform politicilor lor de repornire, iar acesta este un comportament pe care merită să-l cunoașteți înainte, nu după.

Apoi verificați cele două lucruri pe care schimbarea trebuia să le repare. Inspectați noua subrețea cu docker network inspect și confirmați că se află în baza aleasă, apoi verificați ruta către o destinație VPN reprezentativă cu ip route get 10.20.30.40 și confirmați că merge unde vă așteptați, nu într-un bridge. Testați și descoperirea serviciilor și comunicarea între containere, pentru că o rețea recreată cu altă adresare poate rupe rezolvarea numelor în moduri care par o eroare a aplicației.

Ce încă se strică după aceea

Partea durabilă este înregistrarea. Păstrați lista alocărilor, baza și dimensiunea alese și rețelele recreate în același loc cu implementarea.

Faptul că un interval este privat nu îl face sigur pentru reutilizare. 10.0.0.0/8 este privat și totodată cel mai probabil să fie deja folosit undeva pe traseu, de aceea răspunsul este o rezervare concretă, nu o preferință pentru un bloc. Documentația de rețele Docker descrie alocarea automată de subrețele și câmpurile pool-ului. Alegeți intervalul după ce trebuie să atingeți, nu după ce pare ordonat.