De standaardpool van Docker wijzigen hernummert netwerken niet

default-address-pools wijzigen hernummert de netwerken die u al hebt niet, en dat verwachten is precies hoe een zorgvuldig plan een onverwachte storing wordt. De instelling regelt de automatische toewijzing voor netwerken die ontstaan nadat de daemon opnieuw start met de nieuwe configuratie. Alles wat al draait, behoudt het subnet dat het kreeg, omdat dat subnet deel uitmaakt van de opgeslagen definitie van het netwerk. De mythe is handig omdat ze suggereert dat één bewerking elke overlap oplost, en de werkelijkheid is een taak in twee delen: kies een bereik dat echt vrij is en migreer daarna de netwerken die dat niet zijn.

De mythe: één poolwijziging lost de overlap op

De mythe heeft een bepaalde vorm. Iemand leest dat de standaardpool van Docker kan worden gewijzigd, wijzigt hem, herstart de daemon en concludeert dat het containernetwerk niet meer botst met de VPN van kantoor. Het oude netwerk staat er nog, is nog steeds verbonden en houdt nog steeds het adres dat botst.

Wat veranderde, is het toekomstige gedrag van de toewijzer, dat echt nuttig en echt beperkt is. Nieuwe netwerken die zonder expliciete --subnet ontstaan, worden uit de nieuwe pool gesneden; de bestaande zaten nooit in die pool. Een herstart bouwt geen netwerken opnieuw op en verplaatst geen containers ertussen. Als het symptoom na de wijziging aanhoudt, was de wijziging echt en was de diagnose onvolledig.

Basisbereik en toegewezen prefix

De configuratie heeft twee velden die makkelijk te verwarren zijn. base is het bereik waaruit de toewijzer snijdt, en size is de prefixlengte van elk toegewezen netwerk, dus een basis van 10.10.0.0/16 met grootte 24 deelt /24 uit binnen die /16. Omgekeerde rollen leveren een toewijzingspatroon op dat u niet bedoelde, meestal één enorm netwerk of een uitgeputte pool.

Een pool is een reservering, geen bewijs. Docker vermijdt conflicten die het in de routingtabel van de host ziet, en het kan een VPN die u nog niet hebt verbonden niet zien.

Die beperking is de hele reden om bewust te kiezen. De bereiken om mee te vergelijken zijn die de host moet bereiken: het kantoor-LAN, de interne subnetten van de bedrijfs-VPN, de prefixen van het lab of staging en elke andere containerhost op dezelfde overlay. Schrijf ze op als CIDR voordat u de daemon aanraakt, want een lijst in uw hoofd mist precies degene die ertoe doet. Kies daarna een basis die met geen ervan overlapt, en bewaar de lijst bij de uitrol zodat de volgende persoon de oefening niet uit het geheugen herhaalt.

Inventariseer voordat u kiest

Inventariseer eerst wat bestaat. docker network ls somt de netwerken op, en docker network inspect bridge -f '{{.IPAM.Config}}' drukt het subnet af dat een bepaald netwerk gebruikt. Herhaal dit voor elk door de gebruiker gedefinieerd netwerk, want Compose-projecten maken hun eigen netwerken en een expliciete --subnet in een compose-bestand omzeilt de pool volledig.

Dat laatste punt is het punt dat de migratie overleeft. Een poolwijziging weerhoudt een collega er niet van 172.18.0.0/16 in een compose-bestand vast te pinnen, en het conflict komt terug met een andere auteur.

Migreren wat al bestaat

Bestaande netwerken migreren is een aparte, ondersteunde bewerking. Elk getroffen netwerk moet opnieuw worden aangemaakt met het nieuwe subnet, wat betekent dat de containers die het gebruiken worden losgekoppeld en opnieuw aangesloten, en een netwerk opnieuw aanmaken verwijdert de containerkoppelingen in plaats van ze te verplaatsen. Behoud volumes en configuratie en behandel het opnieuw aanmaken als een uitrol, niet als een datareset. Doe het werk in een onderhoudsvenster, want de containers op een opnieuw aangemaakt netwerk herstarten of u dat nu had gepland of niet.

Volg de gedocumenteerde daemonconfiguratie en herstartprocedure en coördineer de onderbreking. Op een host met één daemon herstart systemctl restart docker containers volgens hun herstartbeleid, en dat is gedrag dat u beter vooraf dan achteraf kent.

Controleer daarna de twee dingen die de wijziging moest oplossen. Inspecteer het nieuwe subnet met docker network inspect en bevestig dat het binnen de gekozen basis ligt, controleer daarna de route naar een representatieve VPN-bestemming met ip route get 10.20.30.40 en bevestig dat die gaat waar u verwacht en niet naar een bridge. Test ook service discovery en communicatie tussen containers, want een netwerk dat opnieuw is aangemaakt met een andere adressering kan naamresolutie breken op manieren die op een applicatiefout lijken.

Wat daarna nog steeds stukgaat

Het duurzame deel is het verslag. Bewaar de toewijzingslijst, de gekozen basis en grootte, en de opnieuw aangemaakte netwerken op dezelfde plek als de uitrol.

Dat een bereik privé is, maakt het niet veilig om te hergebruiken. 10.0.0.0/8 is privé en tegelijk het meest waarschijnlijke dat al ergens op het pad in gebruik is, daarom is het antwoord een specifieke reservering en niet een voorkeur voor één blok. De Docker-netwerkdocumentatie beschrijft automatische subnettoewijzing en de poolvelden. Kies het bereik op basis van wat u moet bereiken, niet op basis van wat er netjes uitziet.