‫このセクションの要件には､ コンテナの起動方法を理解していることが含まれます｡ その後､ サブネットやIP､ ポートやファイアウォールなど､
‫TCP/IPネットワークの基本的な概念を説明します｡
‫しかし､ 次の講義で実際にコマンドラインについて学ぶ前に､
‫概念的なことに焦点を当てたこのセクションを理解することが､
‫より簡単になることは間違いないでしょう｡
‫コンテナの実行コマンドの-pオプションは､ あなたのマシンのポートを公開するものであることを思い出してほしいのです｡
‫Dockerネットワーキングの背景には､ 実はもっといろいろなことが起こっていて､ それをお話しします｡
‫Dockerには､ バッテリーは含まれるが取り外しが可能というコンセプトがあります｡ これは､ 基本的にデフォルトはかなり簡単で一般的ですが､
‫フードの下で多くのオプションを変更できることを意味します｡
‫この講義では､ ネットワーク上のそのコンテナに対してどのポートが開いているかを簡単に出力してくれるcontainer
‫portコマンドをさっそくチェックしてみましょう｡
‫次に､ Dockerネットワーキングと仮想ネットワーク､ そしてパケットがネットワーク上をどのように流れるかについて､
‫いくつかの概念を分解して説明することにします｡
‫最後に､ コンテナ同士がどのように会話しているのか､ また､ コンテナを物理ネットワークに公開するのとはどう違うのかを､
‫ネットワーク図で説明します｡
‫実際にコンテナを起動するときは､ バックグラウンドで特定のDockerネットワークに接続している状態です｡
‫デフォルトでは､ すぐに確認するように､ それはブリッジネットワークです｡ これはDockerデーモンがデフォルトのインターフェイスでホストIPアドレスを設定し､
‫コンテナがインターネットや他のネットワークに接続し､ 戻ってこられるようにするためのものです｡
‫しかし､ ホスト内で特定のコンテナ同士が対話する場合は､ 実際には-pを使う必要はない｡
‫例えば､ sequelサーバーとPHPのApacheコンテナを持つアプリケーションがあったとして､ この2つのコンテナは同じネットワーク上にあるべきで､
‫実際に物理ネットワークの残りの部分にポートを開くことなく､ 互いに会話できるようになっています｡
‫例えば､ MongoとNodeを使っている､ 関係のない別のアプリケーションがあったとして｡ jsは､ そのためのネットワークを作ることで､ -pを使ってネットワークに公開することなく､
‫互いに会話することができるようになります｡
‫しかし､
‫無関係のアプリが動作している可能性のあるもう一方のネットワークとは､ 実際には話ができないのです｡
‫しかし､ 私が説明したこれらの設定は､ 実はほとんどすべて変更可能だということです｡
‫そして､ これにはDockerが好んで使う良い言葉があります...｡ は､ 電池は入っていますが､ 取り外しが可能です｡
‫このコースでは､ 多くの場合､ デフォルトで動作するように設定されていることを確認してください｡
‫指定する必要もない｡ ただ､ ある種の標準的な方法で物事が構成されていることに気づかされます｡
‫しかし､ これらのオプションの多くは､ 実行時に設定可能であったり､ 事後に変更可能であったりします｡ そして､ ネットワークで遊んでいると､
‫その一端が見えてきます｡
‫実際に変更できることとしては､ 複数の仮想ネットワークを作成し､ アプリごとに1つ､ あるいは異なるセキュリティ要件に基づいて異なる仮想ネットワークを作成することなどが考えられます｡
‫実際に､ 物理的な世界と同じように､ 実際のコンピュータに2つの物理的なNICを搭載することができます｡ 実際に1つのコンテナに2つの仮想ネットワークを接続させることもできますし､
‫コンテナが何のネットワークとも会話しないようにすることもできます｡
‫箱から出してきた仮想ネットワーク設定をスキップして､ 実際に -- net=host
‫を使うこともできますが､
‫そうするとコンテナ化の利点が失われます｡
‫しかし､ 場合によっては必要となることもあります｡
‫この後､ 実際にDockerのネットワークドライバに触れていきます｡ Dockerの周りにはプラグインエコシステムがあり､
‫Dockerの機能を多くのサードパーティツールに拡張しています｡
‫しかし今回は､ いくつかの異なるDockerネットワークドライバを見て､ それらがどのように私たちのネットワークに変化を与え､
‫新しい能力を与えてくれるかを見ていきたいと思います｡
‫これは本当に表面的なことです｡
‫このコースでは､ マルチホスト・プライベートネットワーキングやサブインターフェイスのような､
‫より高度なトピックを扱うネットワークのコンセプトが随所に登場します｡
‫しかし､ 今は､ コマンドラインでの作業に飛び込もう｡
‫簡単な復習として､
‫コンテナの実行コマンドの-pを見てみましょう...｡ ドッカーコンテナを実行します｡
‫最初にコンテナを走らせたとき､ -p を使って Nginx の 80 番ポートを公開したのを覚えているかな｡
‫それは､ 左側のホストポートを取り､ そのポートからコンテナのポート80にトラフィックを転送しています｡
‫docker container port webhost を実行すると､ ホストからコンテナへのトラフィックを転送しているポートが､
‫コンテナ自体にわかりやすく表示されます｡
‫コンテナのIPアドレスの話はしていない｡
‫だから､ コンテナはホストと同じIPを使用していると思えばいいのです｡ しかし､ デフォルトではそうではありません｡
‫そのコンテナのDocker IPを検査することで簡単に取得できます｡
‫formatコマンド､ つまりオプションを使用します｡
‫テキスト出力をフィルタリングするために､ 先ほど使ったgrepコマンドをいつでも使うことができますが､
‫--formatを使うと､ 実際にはもう少しすっきりして一貫性があります｡ 中括弧を2つして､ 設定ファイルの形式を知ることに慣れれば､
‫NetworkSettings. IP Adressは､ そのJSON出力の実際のノードで､
‫私たちが見たいものです｡
‫そして､ ウェブホスト｡ あらら......綴りが違うってことですね｡
‫I P A d
‫そして､ それは私が期待したものではありません｡
‫私は私のローカルネットワーク上の私のMacを知っているので､ 私のホストのIPを使用しようとしていた場合､ 私は私のMacでifconfigを行うと､
‫私はちょうどIPアドレスが私のホームネットワークまたは1 9 2 1 6 8サブネット上にあることを知っています｡
‫同じネットワークでないのが面白いですね｡
‫では､ それはなぜなのか｡
‫描いてみたら､ もっと意味がわかるかな｡
‫私のホストOSがネットワークに接続されている場合... これが私のネットワークです... 物理ネットワーク そして､ これがホストマシーン（私の場合はMac）のイーサネットインターフェースです｡
‫そこには小さなファイアウォールがあり､ いくつかの役割を担っているのです｡ ネットワークから入ってくるすべての受信トラフィックをブロックするので､ デフォルトですべてがブロックされます｡
‫ファイアウォールと呼ぶべきでしょう｡ 私のコンテナから発信されるトラフィックは､
‫デフォルトでNATされることになります｡
‫ネットワーク上のごく一般的なエッジファイアウォールのような動作をしていますね｡
‫しかし､ この仮想ネットワークという概念があり､ デフォルトではブリッジやdocker0というネットワークが表示されます｡
‫新しいコンテナ（ここではC1と呼ぶ）を起動すると､ そのコンテナはそのネットワーク､ つまり仮想ネットワークに接続され､
‫その仮想ネットワークは自動的にホスト上のイーサネットインターフェースに接続されて､ 外に出ることができるようになります｡
‫今回の場合､ そのNginxを起動したところで､ -p 80:80を付与しています｡ MacのEthernetインターフェースで80番ポートを開き､
‫仮想ネットワーク経由で80番ポートに入ってきたものをコンテナの80番ポートに転送するよう､
‫こちらで指示しました｡
‫デフォルトでは､ 2つ目のコンテナを作成すると､ 同じブリッジネットワークに置かれるんだ｡
‫この2つのコンテナは､ 公開されたポートで自由に行き来することができます｡
‫pを指定しない限り､ ここの内部ネットワークに入ってくるトラフィックは､ 私のコンテナには届きません｡
‫実際に仮想ネットワークを増やして､ 好きなように呼び出すことができます｡ この1つのネットは､ 仮にマイアプリと呼ぶことにする｡
‫そして､ ここで2つのコンテナをつなぐとすると...｡ MySQLを手に入れた｡
‫その後､ アパッチを手に入れました｡
‫MySQLでは､ ポートを開けず､
‫-pも指定しなかった｡ でも､ Apacheのほうは､
‫-pを8080:80にしてあげました｡
‫つまり､ 右側にあるホストのイーサネットインターフェイスで､ ポート8080をリッスンし始めるということです｡
‫8080番ポートで私のホストにトラフィックが来るとすぐに､ 私が作成した新しい仮想ネットワークを経由して､
‫80番ポートのApacheサーバーにトラフィックを送ります｡
‫この仮想ネットワーク内では､ Apache サーバーはリスニングポート上で MySQL サーバーと自由に会話することができます｡
‫Dockerの仮想ネットワークについて､ コンテナがどこに属するかを考えるとき､ アプリケーションで関連しているので､
‫異なるコンテナを近接させることを考えてみてください｡
‫この2つの例では､ コンテナ1とコンテナ2が異なるランクにある場合､ 下のネットワークにあるサービスと話をしないのであれば､
‫別々の仮想ネットワークに置くことが理にかなっています｡
‫もし､ お互いに話をすることがあれば､ わざわざ公開されたポートを経由して､ 出たり入ったりしなければならないのだ｡
‫注意点として､ ホスト上のどのインターフェイスでも､ 複数のコンテナに対して複数のポートでリッスンすることはできません｡
‫つまり､ ホストレベルで80番ポートをリッスンするコンテナを2つ用意することはできないのです｡
‫それができるのは､ たった一人｡
‫別のコンテナを起動しようとすると､ 実際にはそのポートにはすでに何か他のものがあるとエラーになります｡
‫これはDockerの制限ではなく､
‫IPネットワークが通常どのように動作するかの制限です｡
‫このセクションについて､ 簡単におさらいしておきましょう｡ 実際には､ -pを使用してホスト上のポートを物理ネットワークに公開するなど､
‫Dockerネットワークの概念に多くの時間を費やしました｡ Dockerは､ バッテリーは含まれるが取り外しは可能という､
‫まともなデフォルトにフォーカスしているということです｡
‫ローカルでの開発・テストでは､ おそらくデフォルトのままでも大丈夫でしょうが､ すべては変更可能です｡
‫次に､ 特定のコンテナに対して公開されているポートを確認する簡単な方法である､ container
‫port コマンドについて学びました｡
‫次に､ 仮想ネットワーク上を移動するパケットを分解し､ それらが他の仮想ネットワークとどのように関係し､
‫Dockerマシンにどのように出入りしているのかを説明しました｡
‫次の講義で実際のCLIに入る前に､ これらの概念を理解しておくとよいでしょう｡