Dockerネットワークドライバ完全ガイド｜bridge・host・none・overlay・macvlanの違い

5-1〜5-4 では基本の bridge ドライバを中心に扱ってきました。第5章の締めとして、Docker が提供する5つのネットワークドライバを俯瞰します。複数ホストでのクラスタ運用（第10章 Swarm）や、既存LANへのコンテナ直接参加など、本番寄りの選択肢が理解できるようになります。

💡 この記事のゴール
① 5つのドライバ（bridge / host / none / overlay / macvlan）の特徴
② それぞれの「いつ使うか」判断軸
③ overlay・macvlan の前提条件（Swarm / 物理LAN要件）
④ ドライバ選定の一枚比較表

1. 5つのドライバ概観

ドライバ	一言で	ホストの範囲
`bridge`	標準の仮想ブリッジ + NAT	単一ホスト
`host`	ホストのネットワーク名前空間をそのまま共有	単一ホスト
`none`	ネットワーク無効化（loのみ）	単一ホスト
`overlay`	複数ホストを跨ぐ仮想ネットワーク	マルチホスト（Swarm必須）
`macvlan`	コンテナに物理LAN直属のMAC/IPを付与	単一ホスト（物理LAN統合）

💡 9割のユースケースは bridge（カスタム）
単一ホスト上でアプリとDBをつなぐ、Composeで複数サービスを立てる、といった日常の使い方では bridge ドライバで十分。他のドライバは「特定の要件」が出てきたときの選択肢です。

2. bridge（デフォルト）

Docker が作る仮想ブリッジ docker0 を介し、コンテナ同士とホスト外をNATで繋ぎます。5-1〜5-4 で扱ってきた世界です。

観点	内容
通信範囲	同じホスト上のコンテナ同士、-p 経由で外部
IP	Docker 管理の私設サブネット（例：172.18.0.0/16）
名前解決	カスタムブリッジなら自動（5-1）
性能	良好（NATのオーバーヘッドはわずか）
主な用途	日常ほぼ全て

3. host

コンテナがホストのネットワーク名前空間をそのまま使うモード。独立したネットワーク空間を持たず、-p の転送もありません。コンテナが 80 ポートでリッスンすれば、ホストの 80 ポートがそのままそれです。

# -p は不要（効果なし）
docker run -d --name web --network host nginx

# ホストの 80 ポートで直接リッスンしている
curl http://localhost/
# → Welcome to nginx!

メリット	デメリット
NAT オーバーヘッドゼロで性能最高	コンテナ分離が弱まる（ポート衝突しやすい）
数万コネクション・低遅延サービスに向く	同じホストで80番を使うコンテナを複数起動できない
`-p` 不要で手軽	Windows/macOS 版 Docker Desktop では意味が変わる（VM内ホスト）

⚠️ Docker Desktop（Win/Mac）の host は挙動が違う
Docker Desktop では「ホスト」は Linux VM を指します。Windows/macOS 側のLANとは別。host.docker.internal でホスト側に到達する仕組みが別途用意されているため、素の --network host は期待通りに動かないことがあります。Linux 直接運用時の用途と割り切ったほうが安全。

4. none

コンテナを完全にネットワークから切り離します。lo（ループバック）インターフェースだけが存在し、外部との通信はできません。

docker run -it --network none alpine sh
/ # ip addr
1: lo: <LOOPBACK,UP> ...
   inet 127.0.0.1/8 scope host lo
   (eth0 はない)

使いどころ

ネットワーク不要のバッチ処理（既存データだけで完結するワンショット計算）
信頼できないコードを動かすサンドボックス
ネットワーク設定を後から自前で組み立てるケース（上級者向け）

5. overlay（マルチホスト）

複数ホスト（物理マシンや VM）に分散して動いているコンテナ同士を、同じ仮想ネットワーク上にいるかのように通信させるドライバ。第10章で扱う Docker Swarm の基盤です。

【overlay：複数ホストをまたぐ仮想ネットワーク】
overlay-net（仮想）
🖥️ Host A
📦 web-1
🖥️ Host B
📦 web-2
🖥️ Host C
📦 db

    VXLAN カプセル化で物理LANを跨ぎ、仮想的に1つの L2 ネットワークに見せる
  

観点	内容
前提	Docker Swarm モード初期化済み（または Compose with swarm）
背後の技術	VXLAN（カーネルがパケットをカプセル化）
主な用途	マイクロサービスの本番運用・可用性の担保
代替	Kubernetes + CNI プラグイン（Flannel / Calico 等）

💡 第10章「Docker Swarm」で実戦登場
overlay ドライバは Swarm と組み合わせて初めて真価を発揮します。単発で使うことは稀。Kubernetes を使うなら CNI プラグインがこの役割を担うので、そちらで学ぶのが実戦的です。

6. macvlan / ipvlan

コンテナに物理LANと同じサブネットのMACアドレス・IPを割り当てるドライバ。コンテナが物理ネットワーク上の独立マシンのように振る舞います。

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 \
  macnet

docker run -d --network macnet --ip 192.168.1.50 nginx
# → LAN 内の他マシンから 192.168.1.50 で直接アクセス可能

使いどころ

レガシーアプリが「MACアドレス指定で通信」する前提のとき
コンテナを LAN 上の独立ホストのように扱いたいとき（社内監視対象・DHCPサーバから見える）
NATの2段構えを避けたい高スループット要件

⚠️ 制約が多いドライバ
・物理NIC がプロミスキャスモード対応必須
・クラウド（AWS/GCP/Azure）ではほぼ動かない（VPCが MAC spoofing を禁じる）
・Docker Desktop 環境では非対応
・Wi-Fi では制約が厳しい
本物のオンプレサーバかベアメタルVM での限定的な選択肢です。類似の ipvlan ドライバは MAC を共有するので一部制約を緩和できます。

7. 比較早見表

項目	bridge	host	none	overlay	macvlan
ホスト数	単一	単一	単一	複数	単一
コンテナ間通信	○（自動DNS）	○（ホスト経由）	×	○	○（同subnet）
外部通信	NAT	直接	×	NAT + VXLAN	直接（LAN）
`-p` 必要？	必要	不要	×	必要（公開時）	不要
性能	良	最高	N/A	ややオーバーヘッド	良
前提	なし	Linux直運用が本領	なし	Swarm	プロミスキャス対応NIC
用途	日常9割	性能要求	隔離	分散本番	LAN統合

8. まとめ

迷ったら	選ぶドライバ
普通の開発・本番	bridge（カスタム）
低遅延・高性能が最優先	host
ネットワーク隔離したいバッチ処理	none
複数サーバに分散する本番	overlay（+ Swarm）or Kubernetes CNI
コンテナにLAN上のIPを付けたい	macvlan / ipvlan

✅ 第5章完了！次のステップ
ネットワーク編お疲れさまでした。第6章は Docker Compose。ここまで docker run -d --network app-net -v pgdata:/var/lib/postgresql/data ... と長いコマンドを手入力してきましたが、Compose を使うとYAMLに書くだけで一発起動できます。複数コンテナ・複数ネットワーク・複数ボリュームを宣言的に管理する本命ツールです。