Dockerエラーの修正: Pool overlaps with other one on this address space

TL;DR

Dockerは、指定したサブネット、またはDockerが自動選択したサブネットが既に使用中のものと衝突しているため、ネットワークを作成できません。衝突の原因は、別のDockerネットワーク、VPNトンネル、または社内LANの場合があります。解決策は、既に使用中のものを列挙し、空きCIDRブロックを見つけ、そのブロックを明示的に指定してネットワークを作成することです。

# 既存のDockerネットワークとそのサブネットを一覧表示する
docker network ls
docker network inspect $(docker network ls -q) \
  --format '{{.Name}}  {{range .IPAM.Config}}{{.Subnet}}{{end}}'

# 重複しないサブネットでネットワークを作成する
docker network create --subnet=172.30.0.0/16 my_network

なぜこのエラーが発生するのか

DockerはRFC 1918のプライベートアドレス範囲からサブネットを割り当てます。172.17.0.0/16から始まり、172.18.0.0/16、172.19.0.0/16と続きます。問題は、Dockerだけがそのプールを使っているわけではないという点です。

以下のいずれかが対象サブネットをすでに使用している場合にエラーが発生します：

既存のDockerネットワーク（誰も積極的に使っていないものも含む）
ホスト上のVPNインターフェース
そのマシンを経由してルーティングされる社内LAN
PodmanやKubernetesのCNIプラグインなど、別のコンテナランタイム

Dockerのデフォルトプールは172.16.0.0/12、つまり172.16.x.xから172.31.x.xの範囲です。数ヶ月間コンテナを動かし続けているマシンでは、この範囲全体が埋まってしまうことがあります。そうなると、明示的なサブネットを指定しないdocker network createはすべて失敗します。

ステップ1 — 使用中のアドレスを確認する

次のワンライナーで、すべてのDockerネットワークとそのサブネットを表示できます：

docker network inspect $(docker network ls -q) \
  --format '{{.Name}}  {{range .IPAM.Config}}{{.Subnet}}{{end}}'

開発環境での出力例：

bridge        172.17.0.0/16
host
none
my_app_net    172.18.0.0/16
staging_net   172.19.0.0/24
old_project   172.20.0.0/16

ホストのネットワークインターフェースも確認してください。VPNクライアントは接続した瞬間に10.x.x.xや192.168.x.xのブロックを静かに確保します：

ip addr show   # Linux
ifconfig       # macOS

ステップ2 — 空きサブネットを選ぶ

出力を確認して空きを探してください。172.xの範囲が埋まっている場合は、RFC 1918の別のクラスに切り替えましょう：

10.10.0.0/24 — 254コンテナに対応、覚えやすい
10.20.0.0/24 — 10.10が使用済みの場合の第二候補
192.168.100.0/24 — 10.xと172.xの両方が混雑している場合に有効

2つの範囲が重複しているか分からない場合は、既存のサブネットをToolCraftのサブネット計算ツールに貼り付けてみてください。空きブロックを視覚的に表示し、ブラウザ上で完結するためデータのアップロードは不要です。

ステップ3 — サブネットを明示的に指定してネットワークを作成する

作成時にサブネットを固定することで、Dockerの誤った自動選択を防げます：

docker network create \
  --driver bridge \
  --subnet=10.10.0.0/24 \
  --gateway=10.10.0.1 \
  my_network

Docker Composeを使用している場合は、docker-compose.ymlに直接設定します：

networks:
  my_network:
    driver: bridge
    ipam:
      config:
        - subnet: 10.10.0.0/24
          gateway: 10.10.0.1

ステップ4 — 不要なネットワークを削除する（任意だが推奨）

古いプロジェクトのネットワークは自動的には消えません。docker-compose upとdocker-compose downを10ヶ月繰り返すと、それぞれがサブネットの一部を占有した数十もの孤立したネットワークが残ることがあります。

# コンテナに接続されていないネットワークをすべて削除する
docker network prune

# 特定のネットワークを名前で削除する
docker network rm old_project

削除後、サブネットを指定せずに再度ネットワーク作成を試みてください。不要なネットワークが片付けば、Dockerが自動的に空きブロックを見つけられることが多いです。

修正を確認する

# 正しいサブネットでネットワークが作成されたことを確認する
docker network inspect my_network \
  --format '{{range .IPAM.Config}}Subnet: {{.Subnet}}  Gateway: {{.Gateway}}{{end}}'

# 新しいネットワーク上でコンテナを起動してIPアドレスを確認する
docker run --rm --network my_network alpine ip addr show eth0

コンテナには選択した範囲内のIPアドレス（例：10.10.0.2/24）が割り当てられるはずです。エラーなく起動すれば完了です。

デフォルトアドレスプールの設定

複数のプロジェクトでこのエラーが繰り返し発生する場合、根本的な解決策はDockerのデフォルト設定を変更することです。デフォルトで172.xを使わないよう、/etc/docker/daemon.jsonを編集（または作成）します：

{
  "default-address-pools": [
    {"base": "10.10.0.0/16", "size": 24}
  ]
}

その後、デーモンを再起動します：

sudo systemctl restart docker

新しく自動作成されるネットワークはすべて10.10.0.0/16から/24を切り出すようになります。256個のネットワークを作成できるため、十分な余裕があります。混雑した172.xプールはそのまま残ります。

VPNとの競合

企業VPNはよくある原因の一つです。VPNトンネルは接続した瞬間に10.0.0.0/8や172.16.0.0/12などのブロックを確保しますが、Dockerにはそれを知る手段がありません。対処法は、Dockerをそれらの範囲から完全に遠ざけることです。

VPNが使用していない192.168.200.0/24のようなアドレスを選び、上記の通りdaemon.jsonで固定してください。VPNが使用している範囲が不明な場合は、接続中にip routeを実行してください。VPNのルートはインターフェース名（通常はtun0またはutun）とともに明確に表示されます。