Die Änderung des Docker-Standardpools nummeriert Netze nicht neu

Eine Änderung an default-address-pools nummeriert die Netze, die Sie bereits haben, nicht neu, und genau diese Erwartung macht aus einem sorgfältigen Plan einen unerwarteten Ausfall. Die Einstellung steuert die automatische Zuweisung für Netze, die entstehen, nachdem der Daemon mit der neuen Konfiguration neu gestartet wurde. Alles, was bereits läuft, behält sein zugewiesenes Subnetz, denn dieses Subnetz ist Teil der gespeicherten Definition des Netzes. Der Mythos ist bequem, weil er nahelegt, eine einzige Änderung behebe jede Überschneidung, und die Wirklichkeit ist eine Aufgabe in zwei Teilen: Wählen Sie einen Bereich, der wirklich frei ist, und migrieren Sie dann die Netze, die es nicht sind.

Der Mythos: eine Pooländerung behebt die Überschneidung

Der Mythos hat eine bestimmte Form. Jemand liest, dass der Standardpool von Docker geändert werden kann, ändert ihn, startet den Daemon neu und schließt daraus, dass das Containernetz nicht mehr mit dem Büro-VPN kollidiert. Das alte Netz ist noch da, noch verbunden und hält noch die Adresse, die kollidiert.

Geändert hat sich das künftige Verhalten des Zuteilers, was wirklich nützlich und wirklich begrenzt ist. Neue Netze, die ohne explizites --subnet entstehen, werden aus dem neuen Pool geschnitten; die bestehenden waren nie in diesem Pool. Ein Neustart baut keine Netze neu auf und verschiebt keine Container zwischen ihnen. Bleibt das Symptom nach der Änderung bestehen, war die Änderung real und die Diagnose unvollständig.

Basisbereich und zugewiesenes Präfix

Die Konfiguration hat zwei Felder, die leicht zu verwechseln sind. base ist der Bereich, aus dem der Zuteiler schneidet, und size ist die Präfixlänge jedes zugewiesenen Netzes, sodass eine Basis von 10.10.0.0/16 mit Größe 24 /24 innerhalb dieses /16 vergibt. Vertauschte Rollen erzeugen ein Zuteilungsmuster, das Sie nicht beabsichtigt haben, meist ein einziges riesiges Netz oder ein erschöpfter Pool.

Ein Pool ist eine Reservierung, kein Beweis. Docker vermeidet Konflikte, die es in der Routing-Tabelle des Hosts sieht, und kann ein VPN nicht sehen, mit dem Sie noch nicht verbunden sind.

Diese Einschränkung ist der ganze Grund, bewusst zu wählen. Die Bereiche zum Vergleichen sind die, die der Host erreichen muss: das Büro-LAN, die internen Subnetze des Firmen-VPN, die Präfixe von Labor oder Staging und jeder andere Container-Host im selben Overlay. Schreiben Sie sie als CIDR auf, bevor Sie den Daemon anfassen, denn eine Liste im Kopf wird genau den verfehlen, auf den es ankommt. Wählen Sie dann eine Basis, die sich mit keinem davon überschneidet, und bewahren Sie die Liste beim Deployment auf, damit die nächste Person die Übung nicht aus dem Gedächtnis wiederholt.

Erfassen, bevor Sie wählen

Erfassen Sie zuerst, was existiert. docker network ls listet die Netze, und docker network inspect bridge -f '{{.IPAM.Config}}' gibt das Subnetz aus, das ein bestimmtes verwendet. Wiederholen Sie das für jedes benutzerdefinierte Netz, denn Compose-Projekte erzeugen eigene, und ein explizites --subnet in einer Compose-Datei umgeht den Pool vollständig.

Der letzte Punkt ist der, der die Migration überlebt. Eine Pooländerung hindert einen Kollegen nicht daran, 172.18.0.0/16 in einer Compose-Datei festzunageln, und der Konflikt kehrt mit einem anderen Autor zurück.

Migrieren, was bereits existiert

Die Migration bestehender Netze ist ein separater, unterstützter Vorgang. Jedes betroffene Netz muss mit dem neuen Subnetz neu erstellt werden, was bedeutet, die es nutzenden Container zu trennen und wieder anzuhängen, und das Neuerstellen eines Netzes entfernt seine Containeranhänge, statt sie zu verschieben. Bewahren Sie Volumes und Konfiguration und behandeln Sie das Neuerstellen als Deployment und nicht als Datenreset. Erledigen Sie die Arbeit in einem Wartungsfenster, denn die Container in einem neu erstellten Netz starten neu, ob Sie es geplant haben oder nicht.

Folgen Sie der dokumentierten Daemon-Konfiguration und dem Neustartverfahren und koordinieren Sie die Unterbrechung. Auf einem Host mit einem einzigen Daemon startet systemctl restart docker Container gemäß ihren Neustartrichtlinien neu, und dieses Verhalten sollte man vorher kennen, nicht hinterher.

Prüfen Sie dann die beiden Dinge, die die Änderung beheben sollte. Untersuchen Sie das neue Subnetz mit docker network inspect und bestätigen Sie, dass es innerhalb der gewählten Basis liegt, und prüfen Sie dann die Route zu einem repräsentativen VPN-Ziel mit ip route get 10.20.30.40 und bestätigen Sie, dass sie dorthin führt, wo Sie es erwarten, und nicht in eine Bridge. Testen Sie auch die Diensterkennung und die Container-zu-Container-Kommunikation, denn ein mit anderer Adressierung neu erstelltes Netz kann die Namensauflösung auf Weisen brechen, die wie ein Anwendungsfehler aussehen.

Was danach noch bricht

Der dauerhafte Teil ist die Aufzeichnung. Bewahren Sie die Zuteilungsliste, die gewählte Basis und Größe sowie die neu erstellten Netze am selben Ort wie das Deployment auf.

Dass ein Bereich privat ist, macht ihn nicht sicher zur Wiederverwendung. 10.0.0.0/8 ist privat und zugleich das Wahrscheinlichste, was irgendwo auf dem Pfad bereits genutzt wird, deshalb ist die Antwort eine konkrete Reservierung und keine Vorliebe für einen Block. Die Docker-Netzwerkdokumentation beschreibt die automatische Subnetzzuweisung und die Poolfelder. Wählen Sie den Bereich danach, was Sie erreichen müssen, nicht danach, was ordentlich aussieht.