Dockerのデフォルトブリッジとカスタムブリッジの違い｜DNS名前解決まで徹底解説

第4章まではコンテナ1個を起動する話が中心でした。第5章からはコンテナ同士をつなぐ／外から叩くネットワークの世界に入ります。最初に知っておきたい決定的な違いが「デフォルトブリッジ」と「カスタムブリッジ」です。

結論を先に言うと：本番・開発問わず、常にカスタムブリッジを使うべき。その理由は「コンテナ名で通信できるかどうか」にあります。

目次

1. Docker の3つのデフォルトネットワーク
2. デフォルトブリッジの問題点
3. カスタムブリッジの作り方
4. 実験：名前で通信できる／できないを確かめる
5. なぜこの違いが生まれるのか（自動DNS）
6. 実務での使い方
7. まとめ

1. Docker の3つのデフォルトネットワーク

Docker をインストールすると、最初から3つのネットワークが用意されています。

$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
abc123...      bridge    bridge    local    ← 今回の主役。-network 指定なしで使われる
def456...      host      host      local    ← ホストのネットワーク名前空間をそのまま使う
ghi789...      none      null      local    ← ネットワーク無効化（lo だけ）

このうち bridge が「デフォルトブリッジ」。一方、自分で docker network create して作るブリッジは「カスタムブリッジ（user-defined bridge）」と呼ばれます。どちらも同じ bridge ドライバを使いますが、挙動は大きく違います。

2. デフォルトブリッジの問題点

一番の問題は：コンテナ名でお互いを呼び出せないことです。

デフォルトブリッジには自動のDNS名前解決機能がないため、コンテナ A から B に通信したいとき、B のIPアドレスを直接指定する必要があります。IPはコンテナ起動のたびに変わる可能性があるので、実質使い物になりません。

3. カスタムブリッジの作り方

たった1コマンドです。

$ docker network create mynet
abc123def456...

$ docker network ls
NETWORK ID     NAME     DRIVER    SCOPE
abc123...      bridge   bridge    local
def456...      host     host      local
ghi789...      none     null      local
jkl012...      mynet    bridge    local     ← 新しいカスタムブリッジ

コンテナを起動するときに --network mynet を付けるだけで、このネットワーク上に配置されます。

docker run -d --name app --network mynet nginx
docker run -d --name db  --network mynet postgres:16 -e POSTGRES_PASSWORD=secret

4. 実験：名前で通信できる／できないを確かめる

4-1. デフォルトブリッジでの挙動

# デフォルトブリッジで2つのコンテナを起動
docker run -d --name alpha alpine sleep 3600
docker run -d --name beta  alpine sleep 3600

# alpha から beta へ名前で ping
docker exec alpha ping -c 2 beta
# → ping: bad address 'beta'     ❌ 名前解決できない

# IP で ping すれば通る（確認用）
docker exec alpha ping -c 2 $(docker inspect -f '{{.NetworkSettings.IPAddress}}' beta)
# → 64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.1 ms     ✅ IPならOK

4-2. カスタムブリッジでの挙動

# カスタムブリッジを作る
docker network create mynet

# 同じ mynet 上に2つのコンテナを起動
docker run -d --name alpha --network mynet alpine sleep 3600
docker run -d --name beta  --network mynet alpine sleep 3600

# alpha から beta へ名前で ping
docker exec alpha ping -c 2 beta
# → PING beta (172.18.0.3): 56 data bytes
# → 64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.1 ms     ✅ 名前で解決できる🎉

4-3. 後片付け

docker rm -f alpha beta
docker network rm mynet

5. なぜこの違いが生まれるのか（自動DNS）

カスタムブリッジだけが、Docker 内蔵の組み込みDNSサーバ（127.0.0.11）を使ったコンテナ名の自動解決を提供します。

各コンテナの /etc/resolv.conf を覗くと、DNSサーバが 127.0.0.11（Docker内蔵DNS）に設定されています。このDNSが、同じカスタムブリッジに参加している他コンテナの名前を IP に解決してくれます。

$ docker exec alpha cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

$ docker exec alpha nslookup beta
Server:		127.0.0.11
Address:	127.0.0.11#53

Non-authoritative answer:
Name:	beta
Address: 172.18.0.3

6. 実務での使い方

「Webアプリ + DB」の典型的な構成をカスタムブリッジで組む例：

# 1. ネットワークを作る
docker network create app-net

# 2. DB（先に起動）
docker run -d --name db --network app-net \
  -e POSTGRES_PASSWORD=secret postgres:16

# 3. アプリ（DBにホスト名「db」で接続）
docker run -d --name app --network app-net \
  -p 3000:3000 \
  -e DATABASE_URL="postgres://postgres:secret@db:5432/postgres" \
  myapp

重要なのは DATABASE_URL=postgres://...@db:5432/... の部分。IPではなくコンテナ名「db」で接続先を指定できています。DB コンテナを再起動しても IP が変わっても、アプリ側の設定はそのまま動きます。

7. まとめ

参考リンク

• Bridge network driver（Docker公式） — ブリッジネットワークの一次情報源。
• Networking with standalone containers（公式チュートリアル） — カスタムブリッジを作って2コンテナ接続する公式例。

Dockerの基礎を動画で体系的に学びませんか？

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

クーポン割引で講座を見る →