Zmiana domyślnej puli Dockera nie przenumerowuje sieci

Zmiana default-address-pools nie przenumerowuje sieci, które już masz, i właśnie to oczekiwanie zamienia staranny plan w nieoczekiwaną awarię. Ustawienie rządzi automatycznym przydziałem dla sieci tworzonych po restarcie demona z nową konfiguracją. Wszystko, co już działa, zachowuje przydzieloną podsieć, ponieważ ta podsieć jest częścią zapisanej definicji sieci. Mit jest wygodny, bo sugeruje, że jedna zmiana naprawia każde nakładanie się, a rzeczywistość to praca w dwóch częściach: wybierz zakres, który naprawdę jest wolny, a potem zmigruj sieci, które nie są.

Mit: jedna zmiana puli naprawia nakładanie się

Mit ma określony kształt. Ktoś czyta, że domyślną pulę Dockera można zmienić, zmienia ją, restartuje demona i dochodzi do wniosku, że sieć kontenerów nie koliduje już z VPN-em biurowym. Stara sieć nadal tam jest, nadal jest podłączona i nadal trzyma adres, który koliduje.

Zmieniło się przyszłe zachowanie przydzielacza, które jest naprawdę przydatne i naprawdę ograniczone. Nowe sieci utworzone bez jawnego --subnet są wycinane z nowej puli; istniejące nigdy w tej puli nie były. Restart nie odbudowuje sieci i nie przenosi kontenerów między nimi. Jeśli objaw utrzymuje się po zmianie, zmiana była prawdziwa, a diagnoza niepełna.

Zakres bazowy i przydzielony prefiks

Konfiguracja ma dwa pola, które łatwo pomylić. base to zakres, z którego wycina przydzielacz, a size to długość prefiksu każdej przydzielonej sieci, więc baza 10.10.0.0/16 o rozmiarze 24 rozdaje /24 wewnątrz tego /16. Zamiana ról daje wzorzec przydziału, którego nie chciałeś, zwykle jedną ogromną sieć albo wyczerpaną pulę.

Pula to rezerwacja, nie dowód. Docker unika konfliktów, które widzi w tablicy routingu hosta, i nie widzi VPN-a, z którym jeszcze się nie połączyłeś.

To ograniczenie jest całym powodem, by wybierać świadomie. Zakresy do porównania to te, do których host musi dotrzeć: LAN biura, wewnętrzne podsieci VPN firmy, prefiksy laboratorium lub stagingu i każdy inny host kontenerów w tym samym overlayu. Zapisz je jako CIDR, zanim dotkniesz demona, bo lista w głowie pominie właśnie ten, który się liczy. Potem wybierz bazę, która nie pokrywa się z żadnym z nich, i trzymaj listę razem z wdrożeniem, żeby następna osoba nie powtarzała ćwiczenia z pamięci.

Zinwentaryzuj, zanim wybierzesz

Najpierw zinwentaryzuj to, co istnieje. docker network ls wymienia sieci, a docker network inspect bridge -f '{{.IPAM.Config}}' wypisuje podsieć użytą przez konkretną sieć. Powtórz dla każdej sieci zdefiniowanej przez użytkownika, bo projekty Compose tworzą własne, a jawny --subnet w pliku compose całkowicie omija pulę.

Ten ostatni punkt jest tym, który przetrwa migrację. Zmiana puli nie powstrzyma kolegi przed przypięciem 172.18.0.0/16 w pliku compose, a konflikt wraca z innym autorem.

Migracja tego, co już istnieje

Migracja istniejących sieci to osobna, obsługiwana operacja. Każdą dotkniętą sieć trzeba odtworzyć z nową podsiecią, co oznacza odłączenie i ponowne podłączenie kontenerów, które jej używają, a odtworzenie sieci usuwa jej przypięcia kontenerów zamiast je przenosić. Zachowaj wolumeny i konfigurację i traktuj odtworzenie jak wdrożenie, a nie reset danych. Pracuj w oknie serwisowym, bo kontenery w odtworzonej sieci uruchomią się ponownie niezależnie od tego, czy to zaplanowałeś.

Postępuj zgodnie z udokumentowaną konfiguracją demona i procedurą restartu oraz skoordynuj przerwę. Na hoście z jednym demonem systemctl restart docker restartuje kontenery zgodnie z ich politykami restartu, a to zachowanie warto znać wcześniej, a nie później.

Następnie zweryfikuj dwie rzeczy, które zmiana miała naprawić. Sprawdź nową podsieć za pomocą docker network inspect i potwierdź, że leży w wybranej bazie, a potem sprawdź trasę do reprezentatywnego celu VPN za pomocą ip route get 10.20.30.40 i potwierdź, że prowadzi tam, gdzie oczekujesz, a nie do mostka. Przetestuj też odkrywanie usług i komunikację między kontenerami, bo sieć odtworzona z innym adresowaniem może zepsuć rozwiązywanie nazw w sposób, który wygląda jak błąd aplikacji.

Co nadal się psuje potem

Trwałą częścią jest zapis. Przechowuj listę przydziałów, wybraną bazę i rozmiar oraz odtworzone sieci w tym samym miejscu co wdrożenie.

To, że zakres jest prywatny, nie czyni go bezpiecznym do ponownego użycia. 10.0.0.0/8 jest prywatny i jednocześnie najprawdopodobniej już gdzieś na trasie używany, dlatego odpowiedzią jest konkretna rezerwacja, a nie preferencja jednego bloku. Dokumentacja sieci Dockera opisuje automatyczny przydział podsieci i pola puli. Wybieraj zakres według tego, do czego musisz dotrzeć, a nie według tego, co wygląda schludnie.