Dockerは仮想スイッチと仮想イメージの両方を持つ
下記の記事で、Dockerは仮想スイッチと仮想イメージの両方を持つと理解した。
自分の気づきをメモ。
間違っていたら後で直す。
【参考】
【連載】世界一わかりみが深いコンテナ & Docker入門 ? その5:Dockerのネットワークってどうなってるの? ? | SIOS Tech. Lab
僕は、DockerとVMの違いが分かってなかった。
VMWareのソフトでVMの仮想NICをいじったり、VMSphereで複数のVMを再起動する、とかしていたけれど、何か腑に落ちなかった。
なるほど、dockerでは、CentOSの2つのVMを構築するだけでなく、仮想スイッチまで作ってくれるわけだ。
# docker run -it -d --name test01 centos:centos7
# docker run -it -d --name test02 centos:centos7
この仮想スイッチは、L3スイッチに似ている。
IPアドレスを持つし、デフォルトゲートウェイも持つ。
そうでなければ、VMから外部ネットワークへ通信できない。
では、なぜDockerは仮想スイッチが必要なのか?
理由は、おそらく、仮想スイッチを経由して、VMや他のNW機器とパケット転送やイーサネットフレーム転送を制御する必要があるから。
イメージ的には、Dockerの仮想スイッチに、PCとコンソールケーブルで接続して、PCから仮想スイッチにログインして、VLANやSTP、OSPFなどを設定できるようにしたいのだろう。
つまり、Dockerの仮想スイッチは、ネットワーク制御の入り口に当たるわけだ。
また、Linuxをいじっている時に、iptables をよくわからずに操作していたが、NAT機能のことだったのね。
すると、Linuxそのものをルータとして機能させていたわけだ。
Dockerが仮想スイッチを操作できるならば、Dockerを動かすOSそのものをNAT機能を持つルータにしてしまえば、Webシステムの冗長化やブルーグリーン・デプロイメントも楽に制御できるはず。
こういう技術がない頃は、手作業でロードバランサーの向き先を変えて、2つのWebサーバーに順に本番モジュールをリリースしていたが、いつも冷や汗をかいていたのを思い出した。
Dockerで仮想スイッチやVMも一括設定できるなら、どの環境にも簡単に移植できるようになるはず。
さらには、クラウドの種類、AWS、Azureに依存しないように構築できるはず。
Infrastructure as codeは、移植性を透明的にする方向に進化しているわけだ。
| 固定リンク
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「ネットワーク・クラウド」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- Go言語でできることは何なのか(2022.11.06)
- コンテナはサーバーレスアーキテクチャのための1つの技術(2022.11.06)
- クラウド上の開発がJavaに与えた影響は何なのか(2022.10.16)
コメント