Dockerネットワークの仕組みと使い方、bridge / host / overlayの違いとは?
Dockerで複数のコンテナを連携させるには、ネットワークの仕組みを理解することが重要です。
ネットワークモードの選定次第で、セキュリティ、パフォーマンス、スケーラビリティに大きな影響を与えるため、ぜひ使い分けの知識を習得しておきたいところです。
Dockerネットワークの基礎知識
Dockerは、コンテナ間通信や外部アクセスの方法を制御するために独自の仮想ネットワークを提供しています。
Dockerインストール直後には、以下のようなネットワークが自動で生成されます:
| ネットワーク名 | ドライバー | 説明 |
|---|---|---|
| bridge | bridge | デフォルトの仮想ネットワーク。複数コンテナ間で通信可能 |
| host | host | ホストOSのネットワークと共有(Linux限定) |
| none | null | ネットワーク無し |
| overlay | overlay | 複数ホスト間にまたがる分散ネットワーク(Swarm専用) |
以下で主要な3種類について詳しく解説していきます。
bridgeネットワークの仕組みと使い方
bridge はDockerのデフォルトネットワークで、もっともよく使われるモードです。
同一ホスト内で複数のコンテナをつなぎたいときに便利で、名前解決やポートフォワーディングにも対応しています。
特徴
- ホストとは独立した仮想ネットワーク上で動作
docker run時のポート指定が必要(例:-p 8080:80)- カスタムブリッジネットワークならコンテナ名解決が可能
デフォルトのbridgeとカスタムbridgeの違い
| 項目 | デフォルトbridge | カスタムbridge |
|---|---|---|
| 名前解決 | 不可 | 可能(コンテナ名で通信) |
| IP範囲 | 固定 | 自由に設定可能 |
| セキュリティ設定 | 固定 | ファイアウォールルール追加可能 |
デフォルトbridgeの例
bashdocker run -d --name web1 -p 8080:80 nginx
docker run -d --name web2 -p 8081:80 nginx
これはホストマシンのポート8080と8081を、それぞれ2つのnginxコンテナにバインドします。ただし、web1からweb2へはIP直打ちでしか通信できません。
カスタムbridgeネットワークの作成と接続
bashdocker network create \
--driver bridge \
my_custom_bridge
このネットワーク上に2つのコンテナを起動します。
bashdocker run -d --name web1 --network my_custom_bridge nginx
docker run -d --name web2 --network my_custom_bridge nginx
この状態では、web1 コンテナから web2 へ curl http://web2 のように名前解決が可能となります。
ポートフォワーディングと外部アクセス
bashdocker run -d --name web --network my_custom_bridge -p 8080:80 nginx
このように -p オプションを指定することで、ホスト側から http://localhost:8080 でアクセス可能になります。
ブリッジネットワークの確認
以下のコマンドでネットワークの一覧が確認できます:
bashdocker network ls
詳細情報を確認したい場合は:
bashdocker network inspect my_custom_bridge
不要になったネットワークの削除
bashdocker network rm my_custom_bridge
hostネットワークの仕組みとユースケース
host ドライバーは、コンテナがホストマシンと同じネットワーク空間を共有する特殊なモードです。
特にパフォーマンスを最重視する場合や、特定のポートバインディングの回避が必要なケースで活用されます。
特徴
- ホストのIPアドレスをそのまま使用
- ポートバインドが不要(
-pなしでそのまま公開される) - Linux環境専用(macOS/Windowsでは機能しません)
- 他のコンテナとは分離されており、名前解決は不可
利用例
以下はhostネットワークモードを使ったnginxの起動例です。
bashdocker run -d --name host-nginx --network host nginx
この場合、localhost:80 にアクセスすることでnginxに接続できます。
注意点
- 他のサービスとポート競合するリスクがある
- ネットワークの分離性がなくなるためセキュリティリスクが高い
適したケース
| ユースケース | 理由 |
|---|---|
| モニタリングツール | ホストのすべてのネットワークインターフェースにアクセスできるため |
| VPNやネットワークゲートウェイ | 複雑なルーティング設定が不要 |
| レガシーなポート要件を持つアプリケーション | NAT変換を省略できる |
詳しくは公式ドキュメントをご参照ください:host network driver
overlayネットワークの仕組みと使い方
overlay は、複数のDockerホスト間でコンテナを接続するための分散型ネットワークです。
Docker Swarm(またはDocker Enterprise)モードでのみ使用でき、クラスタ全体での通信を実現します。
特徴
- 異なるホスト上のコンテナ間で通信可能
- 暗号化されたVXLANトンネルを利用
- Swarmモードでのサービスディスカバリが自動化されている
- セキュアなマルチホスト構成に最適
準備:Swarmクラスタの初期化
まずSwarmモードを初期化します。
bashdocker swarm init
overlayネットワークの作成
bashdocker network create \
--driver overlay \
--attachable \
my_overlay_net
--attachable をつけることで、サービスだけでなく単独のコンテナもネットワークに接続可能になります。
サービスのデプロイ
bashdocker service create \
--name web \
--network my_overlay_net \
-p 8080:80 \
nginx
この例では、Swarmノード群のいずれかにアクセスすれば、適切にサービスへルーティングされます。
マルチホストでの通信例(2ノード以上)
| ホスト名 | コンテナ名 | ネットワーク |
|---|---|---|
| hostA | app-a | my_overlay_net |
| hostB | app-b | my_overlay_net |
これらは ping app-b によって相互に名前解決と通信が可能です。
セキュリティ対策
overlayネットワークはTLSと暗号化によって保護されており、安全な分散通信を実現しています。
公式ドキュメントでも高く推奨されております:overlay network driver
ネットワーク戦略の選定指針
| 使用目的 | 推奨ネットワークモード |
|---|---|
| 同一ホストで複数コンテナ通信 | bridge |
| シンプルなシングルコンテナ公開 | host |
| マルチホスト構成 | overlay |
| 外部ネットワークアクセスを遮断したい | none |
用途に応じて適切なネットワークを選ぶことで、セキュリティとパフォーマンスのバランスを最適化できます。
実践Tipsと注意点
DNS名前解決ができない?
デフォルトのbridgeでは名前解決が効かないため、カスタムネットワークの利用が推奨されます。
bashdocker network create --driver bridge mynet
コンテナ間通信ができない?
ファイアウォール設定やホストのネットワークポリシー(特にAWSやGCP)を確認する必要があります。
Swarmでoverlayが動かない?
以下の項目を確認してください:
docker swarm initを実行したか- 複数ノード間で
--advertise-addrを適切に指定したか - ポート
2377,7946,4789が開放されているか
まとめ
Dockerのネットワーク機能は非常に柔軟で、適切に使い分けることで、開発効率・運用効率・セキュリティすべてを高めることが可能です。
| モード | 特徴 | 主な用途 |
|---|---|---|
| bridge | 仮想ネットワークでの通信 | 同一ホスト内のマイクロサービス連携 |
| host | ホストのネットワークを共有 | パフォーマンス重視、特殊アプリ |
| overlay | 複数ホスト間通信 | Docker Swarmクラスタの構築 |
より詳しくはDocker公式ドキュメントのネットワークガイドをご参照ください:
公式ドキュメントリンク
articleDocker を用いた統一ローカル環境:新人オンボーディングを 1 日 → 1 時間へ
articleDocker で Dev Container を構築:VS Code/Codespaces で即戦力環境を配布
articleDocker マルチステージビルド設計大全:テスト分離・依存最小化・キャッシュ戦略
articleDocker コマンド早見表:build/run/exec/logs/prune を 1 枚で網羅
articleWindows WSL2 に Docker を最適導入:I/O 最適化・メモリ配分・互換性チェック
articleDocker vs Podman vs nerdctl 徹底比較:CLI 互換性・rootless・企業導入の勘所
articleSvelte のコンパイル出力を読み解く:仮想 DOM なしで速い理由
articleTauri で Markdown エディタを作る:ライブプレビュー・拡張プラグイン対応
articleStorybook で“仕様が生きる”開発:ドキュメント駆動 UI の実践ロードマップ
articleshadcn/ui で B2B SaaS ダッシュボードを組む:権限別 UI と監査ログの見せ方
articleSolidJS の Control Flow コンポーネント大全:Show/For/Switch/ErrorBoundary を使い分け
articleRemix で管理画面テンプレ:表・フィルタ・CSV エクスポートの鉄板構成
blogiPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
blogGoogleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
blog【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
blogGoogleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
blogPixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
blogフロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
review今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
reviewついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
review愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
review週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
review新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
review科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来