Dockerコンテナ間通信の仕組み｜コンテナ名によるDNS名前解決を完全解説

5-1 で「カスタムブリッジならコンテナ名で通信できる」ことを確認しました。今回はその中身を深掘りし、複数コンテナを安心してつなぐためのテクニック（ネットワークエイリアス・複数ネットワーク参加・依存順序）まで身につけます。

💡 この記事のゴール
① Docker 内蔵DNS（127.0.0.11）の仕組み理解
② --name がそのままコンテナのホスト名になること
③ ネットワークエイリアスで別名を付ける
④ 1コンテナを複数ネットワークに参加させる（docker network connect）
⑤ DBが先に起動するような「順序依存」の扱い方（第6章への伏線）

--name はそのままホスト名
内蔵DNSサーバの仕組み
ネットワークエイリアスで別名を付ける
1コンテナを複数ネットワークに参加させる
ネットワーク分離パターン（front / back）
「DBが先に起動していないと失敗する」問題
まとめ

1. `--name` はそのままホスト名

カスタムブリッジ上のコンテナは、--name で付けた名前がそのままホスト名として他コンテナから見えます。

docker network create app-net
docker run -d --name db --network app-net -e POSTGRES_PASSWORD=secret postgres:16

# 別のコンテナから「db」という名前でアクセス
docker run --rm --network app-net postgres:16 \
  psql -h db -U postgres -c "SELECT 1;"
# → 結果が返ってくる ✅

💡 --name を付けないと？
Docker が自動で2単語のランダム名（例: quirky_hopper）を付けます。それでもホスト名として使えますが、人間にとって覚えにくいので、ネットワーク上で通信させるコンテナには必ず --name を付けるのが鉄則です。

2. 内蔵DNSサーバの仕組み

5-1 で軽く触れた Docker 内蔵 DNS を、もう一歩深く見てみます。

【コンテナ内の名前解決の流れ】
📦 コンテナ「app」が db に接続しようとする
① glibc
resolv.conf 参照
▶
② 127.0.0.11
Docker内蔵DNS
▶
③ db = 172.18.0.3
同ネットワーク検索
▶
④ 接続成功

    127.0.0.11 はコンテナ内のみで有効。ホスト側からは見えない
  

解決順序

Docker 内蔵DNSは同じカスタムブリッジ上の名前を最優先で解決し、見つからなければ外部DNS（ホストのDNS設定や 8.8.8.8 等）にフォワードします。

# 内部コンテナ名は Docker 内蔵DNSが解決
$ docker exec app nslookup db
Server:     127.0.0.11
Address:    172.18.0.3

# 外部ドメインは外にフォワード
$ docker exec app nslookup google.com
Server:     127.0.0.11
Address:    172.217.175.238    ← 8.8.8.8 等に問い合わせた結果

3. ネットワークエイリアスで別名を付ける

コンテナ名以外に追加のホスト名を付けたい場合があります。たとえば：

アプリから接続する名前は database に固定したい
バージョン違いで db-v1・db-v2 を並行運用したいが、どちらも db と呼びたい

そんなとき --network-alias を使います。

# pg-16-a というコンテナ名に「db」というエイリアスを付与
docker run -d --name pg-16-a --network app-net --network-alias db \
  -e POSTGRES_PASSWORD=secret postgres:16

# アプリ側からは「db」で引ける
docker exec app ping -c 1 db         # ✅ 通る
docker exec app ping -c 1 pg-16-a    # ✅ これも通る（本名）

💡 エイリアスの実用例：ブルーグリーン
新旧2バージョンの DB を立ち上げ、どちらを「db」として見せるかをエイリアスの付け替えで切り替えるパターンがあります。docker network disconnect → docker network connect --alias db で一瞬でスイッチ可能。

4. 1コンテナを複数ネットワークに参加させる

1つのコンテナを複数のネットワークに同時接続できます。実行中に追加することも可能。

# 2つのネットワーク作成
docker network create frontend
docker network create backend

# nginx は frontend に起動
docker run -d --name web --network frontend nginx

# 後から backend にも繋ぐ
docker network connect backend web

# 確認（2つのネットワークに参加しているはず）
docker inspect web -f '{{json .NetworkSettings.Networks}}' | jq 'keys'
# → ["backend", "frontend"]

コマンド	役割
`docker network connect <net> <ctr>`	既存コンテナをネットワークに参加
`docker network disconnect <net> <ctr>`	ネットワークから切断

5. ネットワーク分離パターン（front / back）

複数ネットワーク参加の典型的な使い方：フロントネットとバックネットを分離して、インターネット公開コンテナから内部DBを直接見えないようにします。

【2段ネットワーク構成】
🌐 frontend-net（インターネット公開側）
📦 proxy（nginx）
📦 app（Web）
🔒 backend-net（内部のみ）
📦 app
📦 db
📦 cache（redis）

    ↑ app は両方に参加するが、db / cache は backend-net のみ。proxy から db は見えない（直接攻撃されにくい）
  

docker network create frontend-net
docker network create backend-net

# DB は backend のみ
docker run -d --name db --network backend-net \
  -e POSTGRES_PASSWORD=secret postgres:16

# アプリは両方に参加
docker run -d --name app --network frontend-net myapp
docker network connect backend-net app

# nginx は frontend のみ（DB には到達不能）
docker run -d --name proxy --network frontend-net -p 80:80 nginx

💡 最小権限の原則
各コンテナを「必要なネットワークだけに参加」させることで、万が一proxyが突破されても DB に直接到達できないネットワーク境界が生まれます。Dockerのシンプルな機能だけで多層防御を作れる例です。

6. 「DBが先に起動していないと失敗する」問題

カスタムブリッジで名前解決ができても、接続先のサービスが準備完了しているかは別問題です。アプリのコンテナが「まだ起動中のDB」に接続しようとして失敗するケースは日常茶飯事。

対処パターン

手段	内容	どこで扱う？
アプリ側のリトライ	接続失敗時に数秒待って再試行（指数バックオフ）	アプリのコード
`wait-for-it.sh` 等	DBポート到達可能になるまで起動を待つラッパー	Dockerfile の ENTRYPOINT で包む
healthcheck + depends_on	Compose でDBの健康状態を見て順序制御	第6章 6-4 で詳しく
Swarm/K8s の準備完了プローブ	オーケストレータが賢く待つ	第10章以降

⚠️ 「起動順」だけでは不十分
docker run db を先に実行しても、DBプロセスが「接続を受け付けられる状態」になっているかは別問題。アプリ側にリトライを仕込むのが一番堅牢です。第6章 6-4 の healthcheck と組み合わせるとさらに確実。

7. まとめ

押さえどころ	内容
名前解決	カスタムブリッジ上でコンテナ名を `127.0.0.11` 内蔵DNSが解決
`--name`	ホスト名として機能。本番・開発共に必ず付ける
`--network-alias`	別名を付けてアプリ側の接続先名を安定化
複数ネットワーク	`docker network connect` で後から追加可能
分離パターン	frontend / backend を分けて多層防御
依存	起動順より「接続可能になるまで待つ」ロジックが必要