ブリッジモード

bridge モードでは、仮想ネットワークブリッジを使用してホストとコンテナのネットワーク間にレイヤーを作成します。これにより、ホストポートをコンテナポートに再マップするポートマッピングを作成できます。マッピングは静的または動的に実行することができます。

スタティックポートマッピングでは、どのホストポートをコンテナポートにマッピングするかを明示的に定義できます。上記の例を使用すると、ホスト上のポート 80 はコンテナのポート 3000 にマップされます。コンテナ化されたアプリケーションと通信するには、Amazon EC2 インスタンスの IP アドレスのポート 80 にトラフィックを送信します。コンテナ化されたアプリケーションの観点から見ると、ポート 3000 上のインバウンドトラフィックがわかります。

トラフィックポートのみを変更する場合は、静的ポートマッピングが適しています。ただし、これには host ネットワークモードを使用する場合と同じ欠点があります。各ホストで 1 つのタスクを複数インスタンス化することはできません。これは、静的ポートマッピングでは、1 つのコンテナしかポート 80 にマッピングできないためです。

この問題を解決するには、次の図に示すように、bridge ネットワークモードと動的ポートマッピングを使用することを検討してください。

ポートマッピングでホストポートを指定しないことで、Docker にエフェメラルポート範囲から未使用のポートをランダムに選択させ、それをコンテナのパブリックホストポートとして割り当てることができます。例えば、コンテナのポート 3000 をリッスンしている Node.js アプリケーションには、Amazon EC2 ホスト上の 47760 のようにランダムに大きい番号のポートが割り当てられる場合があります。これにより、そのコンテナの複数のコピーをホスト上で実行できるようになります。さらに、各コンテナにはホスト上の独自のポートを割り当てることができます。コンテナの各コピーは、ポート 3000 でトラフィックを受信します。ただし、これらのコンテナにトラフィックを送信するクライアントは、ランダムに割り当てられたホストポートを使用します。

Amazon ECS は、各タスクにランダムに割り当てられたポートを追跡するのに役立ちます。これは、ロードバランサーのターゲットグループと AWS Cloud Map サービス検出を自動的に更新して、タスクの IP アドレスとポートのリストを取得することによって行われます。このため、ダイナミックポートで bridge モードを使用するときのみにサポートされます。

ただし、bridge ネットワークモードを使用するデメリットの 1 つは、サービス間の通信をロックダウンするのが難しいことです。サービスはランダムで未使用のポートに割り当てられる可能性があるため、ホスト間で幅広いポート範囲を開く必要があります。ただし、特定のサービスが他の 1 つの特定のサービスとしか通信できないように特定のルールを作成するのは簡単ではありません。サービスには、セキュリティグループのネットワークルールに使用する特定のポートはありません。

bridge ネットワークモードは Amazon EC2 インスタンスでホストされている Amazon ECS タスクにのみサポートされています。Fargate で Amazon ECS を使用する場合はサポートされません。