Docker の既定プールを変えてもネットワークは再採番されない
default-address-pools の変更が効くのは新しい自動ネットワークだけです。すでに使っている範囲を棚卸しし、稼働中のものの移行を計画してください。
default-address-pools を変えても、すでにあるネットワークの番号は振り直されず、そう期待することが慎重な計画を突然の障害に変える原因です。この設定が制御するのは、デーモンが新しい構成で再起動した後に作られるネットワークへの自動割り当てです。すでに動いているものは、そのサブネットがネットワークの保存された定義の一部であるため、与えられたサブネットを保持します。俗説が便利なのは一度の変更ですべての重複が直ると示唆するからで、実際は、本当に空いている範囲を選んでから空いていないネットワークを移行するという二段階の作業です。
俗説: プールを一度変えれば重複が直る
俗説には決まった形があります。Docker の既定プールは変更できると読んだ人が、それを変えてデーモンを再起動し、コンテナネットワークがオフィスの VPN と衝突しなくなったと結論します。古いネットワークはそのまま残り、接続されたままで、衝突するアドレスを保持し続けます。
変わったのは割り当て機構の今後の振る舞いで、それは確かに有用であり、確かに限定的です。明示的な --subnet なしで作られた新しいネットワークは新しいプールから切り出されますが、既存のものはそもそもそのプールにありませんでした。再起動はネットワークを作り直さず、コンテナを移動もしません。変更後も症状が続くなら、変更は実際に効いており、診断が不完全だったのです。
基底範囲と割り当てプレフィックス
構成には混同しやすい二つのフィールドがあります。base は割り当て機構が切り出す範囲で、size は割り当てられる各ネットワークのプレフィックス長であり、10.10.0.0/16 の基底と 24 のサイズなら、その /16 の中に /24 を配ります。役割を逆にすると意図しない割り当てパターンになり、たいていは巨大なネットワーク一つか枯渇したプールになります。
プールは予約であって証明ではありません。Docker はホストの経路テーブルに見える衝突は避けますが、まだ接続していない VPN は見えません。
この制約こそが、意図して選ぶべき理由のすべてです。比較すべき範囲は、ホストが到達しなければならないもので、オフィスの LAN、社内 VPN の内部サブネット、ラボやステージングのプレフィックス、同じオーバーレイ上の他のコンテナホストです。デーモンに触る前に、頭の中の一覧は重要な一つを必ず落とすので、CIDR として書き出してください。次にどれとも重ならない基底を選び、その一覧を配備と一緒に保管して、次の人が記憶から同じ作業を繰り返さないようにします。
選ぶ前に棚卸しする
まず現状を棚卸しします。docker network ls はネットワークを一覧し、docker network inspect bridge -f '{{.IPAM.Config}}' は特定のネットワークが使うサブネットを出力します。Compose プロジェクトは自前のネットワークを作り、compose ファイルの明示的な --subnet はプールを完全に迂回するため、ユーザー定義のネットワークごとに繰り返してください。
最後の点が移行後も生き残ります。プールを変えても、同僚が compose ファイルで 172.18.0.0/16 を固定するのを止められず、衝突は別の作者とともに戻ってきます。
すでにあるものを移行する
既存ネットワークの移行は別個の、サポートされた操作です。影響を受ける各ネットワークは新しいサブネットで作り直す必要があり、それは使っているコンテナを切り離して再接続することを意味し、ネットワークを作り直すとコンテナの接続は移されるのではなく削除されます。ボリュームと構成は保持し、作り直しはデータのリセットではなく配備として扱ってください。作り直したネットワーク上のコンテナは計画していてもいなくても再起動するため、作業は保守時間帯に行ってください。
文書化されたデーモン構成と再起動手順に従い、中断を調整してください。デーモンが一つのホストでは、systemctl restart docker は再起動ポリシーに従ってコンテナを再起動しますが、これは後ではなく前に知っておく価値のある挙動です。
次に、変更が直すはずだった二点を検証します。docker network inspect で新しいサブネットを調べ、選んだ基底の中にあることを確認し、続いて代表的な VPN 宛先への経路を ip route get 10.20.30.40 で確認し、ブリッジではなく期待した場所へ向かうことを確かめます。別のアドレスで作り直したネットワークはアプリの不具合に見える形で名前解決を壊すことがあるため、サービス検出とコンテナ間通信も試してください。
その後も壊れるもの
長く残るのは記録です。割り当て一覧、選んだ基底とサイズ、作り直したネットワークを配備と同じ場所に保管してください。
範囲がプライベートだからといって、再利用して安全とは限りません。10.0.0.0/8 はプライベートであり、同時に経路上のどこかですでに使われている可能性が最も高いため、答えは一つのブロックへの好みではなく、具体的な予約になります。Docker のネットワーク文書には自動サブネット割り当てとプールのフィールドが説明されています。範囲は整って見えるかではなく、到達すべきものから選んでください。