Dockerとコンテナの理解
こんにちは、シニアソフトウェアエンジニアのriddleです。
こんにちは、ミドルソフトウェアエンジニアのひびのです。
このポッドキャストでは、僕たち2人で、技術だったりキャリアだったり、その他いろいろなことを話して、
IT業界のリアルを届けていこうという趣旨の番組です。
今日のテーマが、働くソフトウェアエンジニアのDockerやコンテナの理解度。
理解度、イエイ。
イエイ。
Docker。
コンテナ。
Docker、コンテナ。僕、Docker大好きです。
本当ですか。
好きだけど得意とは言っていないってやつなんですけど。
具体的にどういうときに使ってますか。
例えば、プロジェクト1つのウェブサービスの開発環境を、自分のローカルのパソコンで作るときとか。
なんというか、例えばそのウェブサイトのローカル開発環境を立ち上げるにあたって、いくつか他のミドルウェアが必要みたいなときに、
Dockerだったりとかそういうものを使えば、どのパソコンで開いても再現性の高い、かつパソコンの中の他のパソコンの中にわざわざそういうミドルウェアをインストールしなくても、環境を汚さなくても、
環境を汚さなくても再現性高く環境を構築できる、土台が作れる。ざっくりそういう理解です。
はい、ありがとうございます。めっちゃ便利で、特にポータビリティとか、日本語だと過半性?持ち運びやすさがあるみたいなところが、結構コンテナの売りかなと思いますが、そもそもどうやって成り立っているのか知ってますか?
Dockerファイルとその構造
どうやって成り立っているのか、正直僕はそこまで理解していないんですけど、なんかコンテナ、Dockerがちょっと有名になり始めた頃に、Xで、
Dockerは、チェンジオーナーコマンド、C-H-O-W-N、リナックスとかユニックスで、例えばファイルとかディレクトリの所有権を書き換える、パーミッションを書き換えるコマンドですよね。
実質あれだっていう議論を見かけたことがあって、そうなのかもしれないけど、中の仕組みよくわかってないからよくわかんないな、みたいなことを思った記憶はあります。
いやなんか全然ピンとこなかった、え、C-H-Oじゃなくて、C-H-ROOTじゃなくて。
C-H-ROOT、あ、そうか、いやすみません、C-H-ROOTだったかも、ROOT、あ、ROOT、C-H-ROOTだったあれかな、ユーザーのホームディレクトリを書き換える?違うか。
いや、C-H-ROOTっていうのは指定したパスをROOTにとして扱えるようになる。
なるほど、ちなみにそのC-H-ROOTで、ちょっと僕C-H-ROOTコマンド実は多分叩いたことがなくて、指定したディレクトリをROOTとして扱えるのは基本的にはそのシェルの中だけでっていう理解ですよね。
そうですね、シェルとかプロセスとか。
はい、そのシェルというかプロセス。
なるほど、確かにDockerっぽいですね。
そうそう、だからDockerで使ったんですよ、C-H-ROOTを。
あ、そうなんだ、そうか、そうなんですね。
例えば何というか、僕が今ざっくりと思いついた簡単な仕組みとしては、スラテンプディレクトリみたいな汚しても安全なディレクトリ直下に新しいディレクトリを作って、そのばかりで使う。
そこにこのプロセスの中では、C-H-ROOTをして、その中であらゆるものをインストールし、あらゆるファイルを展開し、みたいなことをやればDockerっぽいなって思いました。
そうですね、いや、Appでと思いますよ。
なるほど。
Dockerファイルってありますよね、書いたことありますか。
Dockerファイルもちろん書いたことあります。
あれ、一行一行書くと思うんですけど、最初に多分、フロムなんとかって書きますよね。
そうですね。
フロムなんとか、アルパインとか、Ubuntuとか、Goとか、Ubuntuとか入って、その後に例えばAppでファイルを足したり、コピーでファイルを足したりとか、
ランコマンドでAppとインストールをしたりとか、そういうことやると思うんですけど、
そうですね。
あれやってDockerビルドするとどういうことが起きてるか知ってますか。
えっと、Dockerビルドの時点ですよね。
実際にその、何というか、Dockerビルドだとイメージが作られるんですよね、確か。
そうですね、ビルドのイメージが作られます。
Dockerビルドするとイメージが作られる。
えっと、その時に何が行われているかで言うと、すみません、ちょっと分からないが正しいんですけど、
大丈夫です。
何というか、多分Dockerビルドまでなら、そのDockerコマンドの中の、多分、末尾にCMDだったりとか、何かしらのスタートアップコマンド書きますよね。
その直前までやるんじゃないかな、という理解です。
そのビルドした後にできるイメージがどういうものなのかとか、知ってますか。要するに、どういうファイルなのかとか。
それで言うと、ちょっとそれ、すみません、これエンジニアにあるまじき姿勢だと思うんですけど、もはや意識してなかった。
いいと思います。
何というか、それこそ昔、PSPを改造する時に使うようなドットISOみたいな、いわゆるOSのイメージファイル。
何かああいうものが作られてるんですかね、みたいな、何となくそういう理解です。
了解です。なんか、ISOファイルとはちょっと違うんですけど、ドッカーイメージ、今はドッカーイメージと呼ばれるのは、
OCIっていうオープンコンティーナー、何だっけ、忘れちゃったけど。
オープンコンティーナー。
OCIっていうオープンコンティーナーイニシアチブか、のイメージスペックって企画があって、それに準拠してるもので作られているんですけども、
いわゆるマニフェストとコンフィグとファイルシステムって3つで成り立ってて、それぞれこういう設定が書かれてるよねってやつと、
こういう物理的なファイルっていうものと、またメタデータみたいなものをここでうまく管理されてるんですけど、
コンテナって、コンテナのイメージってレイヤー構造になってるんですよ。
層になってるんですね。これどういうことかというと、1行目にfrom何とかって書いたら、まず一番下にそいつが入るんですよ。
その次に、コピー何とかっていうコマ打たれたら、そのコピー何とかの結果の層が入るんですね。
で、ランコマンドでパッケージインストールしたら、そのパッケージインストールしたやつがその上の層に入っていくっていうレイヤー構造になっていて、
これらを全部固めたやつがイメージですまず。
なるほど。そうか、今僕その話を聞いてピンときたのが、ドッカーファイル書いてドッカービルドするじゃないですか。
例えばその後に途中の行を書き換えて再度ドッカービルドを叩くと、たぶんその書き換えた行以前は何かしらキャッシュされてるみたいな、
なんというかそこがスキップされるみたいな挙動しますよね。
それはレイヤー構造になってるから、もう確定しているというか、すでに実行されたところはスキップして書き換えた行以降を実行すればいいっていう話ね。
そうです、合ってます。
なるほど。今、アハ体験ですね、これは。
よかった。なので、ドッカーファイルをもし書くときは、叩くと毎回変わるようなものに関してはなるべく後ろに書いた方がいいんですね。
そうですね、おっしゃる通り。
そう、ファイルのアウトとかでソースコードをアウトする場合は、そのソースコードは頻繁に変わるものであれば最後の方に書かないと、最初の方に書いちゃうとそれ以降毎回ビルドされちゃうので、最後の方に置いた方がいいと。
そうですね、おっしゃる通り。あとなんか僕が個人的に本当にそういうものなんだろうなと思ってやってたテクニックとしては、
コンテナの運用と技術
なんというか、まだまだドッカーファイル開発中で何回もビルドしなきゃいけないときに、割とアプトゲットコマンド、ミドルウェアを入れるのを本当に一行一行分けて書いて、
何というか必要ないところはキャッシュされやすくして開発していたとかはやってましたね。
なるほど、そういう時は最悪一番ベースのUbuntuのイメージだけを起動して、そのコンテナの中でいろんなパッケージをインストールしたりとかやった後に、これ入れればいいんだなって固めてからドッカーファイルを書いた方が楽かもしれない。
確かに、本当にそうですね、おっしゃる通りだ。
なので、実はドッカーセーブっていうコマンドがあるんですけど、これはイメージをターGZ形式から固められるんですよ。
そのイメージを固めて持っていくと、他のところでドッカーロードってコマンド使うとイメージとして扱えるみたいなこともできたりするんですね。
すごい、まあ言ってみたらあれですよね、他のコンピューターに持って行って、わざわざそこでもう1回ドッカービルドしなくてもイメージが出来上がるってことですよね。
そうだね。そうなんです。
そうか、便利なのはわかるけど、ドッカービルドすればいいじゃんと思ってしまった。
そうなんですけど、自分がドッカーファイル持ってないやつもあるじゃないですか。落としてきたけど、誰が作ったかわかんないけど、
昔からあって、これでも他のところ持ってきたけど、もうドッカーファイルとかなんもない。どうやって持っていこう。よし、イメージを1回ターGZにして持っていこうみたいなケースがあるんですよ。
なるほど、あんまりその状況を作りたくないけど、まあそういう時有効なんでしょうね。
はい。これちょっとレイヤー構造と話したんですけど、基本このレイヤーはリードオンリーなんですね。
最後にリードライトのレイヤーを足して、これらを全て重ねてファイルシステムを再現するみたいなことを言ってるんですけど、
これを使ってドッカーランとかすると、そのファイルシステムが展開されると。
で、上に1枚リードライトの層を重ねているので、例えばドッカーランしたコンテナの中でファイルを作ったりすると、確かにそれって反映されてるんですけど、
その下のレイヤーには一切影響を与えていない感じで。変わったのはその一番上に足された薄いリードライトだけのレイヤーに書き込まれるみたいな感じだよね。
はいはいはい。なるほどなるほど。うん。なるほど。うん。
まあまあまずまず、そういう感じですね。
で、これを起動すると、さっきひめのさんおっしゃってたCHルートとか、Linuxのネームスペースとか、Cグループとか、いろんなコマンドがあるんですけども、
それらを使って、同じ、例えばLinuxだったらLinuxのカーネルを使うけども、隔離された空間で動かすことができる。
はいはいはい。なるほどなるほど。
で、ちょっとLinuxの話になっちゃうんですけど、Linuxってプロセスっていう概念がありますよね。ありますね。
なんかコマンドとか実行した時も、基本的になんかLSで大体LSというプロセスが一回上がるんですけど、そうですね。
で、それ処理して落ちると。で、ネームスペースっていう概念があって、それはプロセス空間を分けられるんですよ。
うん。プロセス空間。どういうことかというと。はい。プロセス空間。
コンテナのプロセス隔離
例えばドッカーの中で、まあ何でもいいんですけど、Ubuntuコンテナを起動する。あ、ドッカーの中でというか、Ubuntuコンテナを起動して、Ubuntuコンテナの中に入って、
PSで叩くと、多分何も見えない。何も見えないっていうか、ほぼ何もないはずなんですよ。はい。なるほどなるほど。
それは、コンテナの中のプロセス空間と、コンテナが動いている外側のプロセス空間を分けてるんですね。
うんうん。なるほどなるほど。
それによって、コンテナの中で何かをやったとしても、他のコンテナとかには影響を与えられないみたいな隔離を実現してるんですよ。
なるほど、そういう仕組みだったんですね。じゃあ、僕ずっとあの仮想化っていう言葉につられて、
何というか、言ってみたらそのプロセスの中でいろいろなことをやってるみたいな理解をしてたんですけど、
そうじゃなくて、プロセスが生まれる領域を他と分けているだけ、みたいな理解の方が本当に新しい。
プロセスが生まれる領域は同じで、例えばホスト側でPSアタックと、そのコンテナのプロセスも見えるんですよ。
ホスト側で、コンテナ自体のですね、コンテナの。
自分でMacがあって、Macの中でどっか立ち上げてNginx当てるとするじゃないですか。
そうすると、Mac側でPSアタックとNginxが動いているのが見えるんですね。
そうなんだ、そうか、そうなんですね。
ただ、Nginxの中でPSアタックとNginxが動いていることは分かるけど、Macの他のプロセスは見えないんですよ。
そうなんですね。
なので、コンテナごとにプロセス空間を隔離してあげている。
みたいなことがLinuxとかMacの機能でできて、プラスそのネットワークとかも隔離されてるんですね。
そうですね。それこそDocker Composeとか使うときに、このポートだけ外側の、外側というかホストマシンのポートにバインディングするとか。
逆にそれをしないと隔離された状態っていうことでもね。
厳密に言うと、このネームスペースっていう概念を分けたときに、
例えばNginx側とホスト側で、ネームスペースをつなぐところにバーチャルイーサーっていうのが作られるんですよ。ペアが。
向こう側とこっち側にペアが作られて、そのペア間は通信できて、そのペアから抜けた先にホスト側にDocker0っていうネットワークのブリッジみたいな。
はいはいはい。そうですよね。
そこまで飛んできて、Nginx側が外に向けに通信しようとすると、そのブリッジまで通信が飛んできて、そこから先はIPテーブルとか、
あとはLinuxのルーターの仕組みとかを使って、変換をして外に出るみたいな機構をやってるんですね。
なので一応外からうちは、ごめんなさい、Nginxから外に行く分には割と簡単に行けるんですけど、
逆に外からNginxに入ろうと思うと一工夫必要で、この工夫がひめのさんが今おっしゃっていただいたコンポーズとかを使う、
-Pオプションつけて、外部のこのボートにバインディングしますよみたいな設定ですね。
はいはいはい。なるほどなるほど。確かにバインディングしたい、バインディング設定書きたい時ってあるでしょうね。
たぶん基本的には中でNginxを立ち上げて、行ってみたらそこに外、ホストマシンのブラウザからアクセスしたいとか、行ってみたらどっかの外からうちに入るっていうアクションですもんね。
-そうです。で、あれも結局裏側ではLinuxの仕組みを使っていて、例えばポートのローカルの方の80番ポートをNginxの80番に紐づけるみたいなことをやりたい場合は、
そのバインディングをするとですね、大体の場合IPテーブルズっていうLinuxとかだと組み込みのそういうツールがあるんですけども、
これを使って外から入ってきた通信のFナットかな、ディスティネーショナルとかDナットか、そういうねじ曲げるというか仕組みがあるんですけども、
後先を変えちゃうみたいなことがあるので、その後先をNginxの方に変えることでやっと通信が成り立つみたいなことを勝手にやってくれてるという感じになります。
-なるほど。
-なのでちょっとややこしいんですけど、ローカルでコンテナを起動したときに隔離されてるように見えるのはCHルートとかネームスペースみたいなもので空間がうまく区切られていたりしますし、
Linuxのシステムコール
ネットワークがつながるのはさっき言ったようなネームスペースとかIPテーブルズとかの仕組みのおかげですっていうのがちょっと基礎的な理解かなと思います。
-なるほど。その辺りのツールを使って、じゃあ僕らが使いやすいようにうまくやってくれてるということですね。
-そうですね。
-ちょっとここで一つ疑問が湧きました。たとえば、多分Dockerの内部的にもCHルートっていうコマンドを使っているっていう話がありましたよね。
-コマンド使ってるのかな。
-コマンドはちょっとシステムコールを呼んでる可能性があるんで、ちょっと。
-なるほど、なるほど。
-CHルートってコマンドそのまま叩いてるわけじゃないと思うんですけど。
-そうか、でもなんというか、CHルートじゃなくても似たような何かしらの仕組みを使って、同じ意味になるシステムコールを呼び出してるっていうことですね。
-そうですね。
-僕がMacでAlpine Linuxベースに作られたイメージを立ち上げることができるじゃないですか。
-はい。
-MacとLinuxって別のOSですよね。なんでこれができているんですか。
-ちなみに、WindowsのイメージをLinuxでは機能できないんですけど。
-おお、そうなんですね。
-Alpineが起動できるのはどっちもLinuxベースだからですね。
-おお、なるほど、なるほど。
-結局そのAlpineのイメージを作りましたってなった時に、何があるかって、そのAlpineで使われるディレクトリレイアウトとコマンドが入っているファイルシステムがあるんですよ、イメージがあるんですよ。
-はい。
-ってなると、結局例えばそのAlpineの、例えばビンの配下にLSみたいなコマンドがイメージの中にありますよね。
-うん。
-で、それを例えるときって裏側はシステムコールが呼ばれるじゃないですか。
-はい。
-リード系の。
-はい。
-それって結局そのLinuxKernel側に実装されていて、LinuxKernelって基本的には同じっていうと言い方あれですけど、
そのLinuxさんがね、作ってるやつあるじゃないですか。
-はいはいはい。
-AlpineもUbuntuも結局そのLinuxKernelを持って、あ、ごめんなさい、持っちゃった。
おそらくLinuxKernelを、ただディストリビューターがちょっといろんなツールをプラスして出してるだけなので、ベースは同じなんですよね。
-うーん、なるほど。
-なので動く。
-Macに搭載されているものもLinuxKernelなんですか?
-Macは確かUnixベースのBSDってやつなんですけど、多分基礎的なシステムコールはほとんど同じなんじゃないかな。
-なるほど、だからそこが共通化されてるってことね。
-はい。
-なるほど、じゃあ。
-だけどWindowsは全然違うからダメなんですね。
-僕ここでもう一つ疑問が湧きました。
一応WindowsにもWindowsサブシステムLinuxを使わなくてもDockerを使える仕組み確かあるじゃないですか。
-Docker DesktopとかWindowsに入れるってことですよね。
-です、です。
あれはどういう仕組みでLinuxを立ち上げているんですか?
-あれってLinux立ち上げられないやつか?使ったことないですよね。
-Linuxというか、Linuxベースで作られているであろうノードJSのイメージとか立ち上げられませんでした?
すみません、もし間違えてたら。
-使ったことないね。
-なるほど。
-使ったことないけど、いけるんだ。
-どうなんだろう、すみません。
僕も記憶が、これちょっと本当に間違えてたら申し訳ない。
でももしかしたらあれかもしれないですね。
Docker以前にもバーチャルボックスとかVMWareとかあったし、何かしらの方法でできるのかもしれないですね。
-調べてみよう。
Linux上はできないはず。
-そうか、そうだったんですね。
もしかしたら、あんまりやってないと思うんですけど、DockerがLinuxのシステムコールをWindowsのAPIに変換してあげているという、なんか七面倒くさいことをやっている可能性はあるかもしれないです。
ただまあ、もちろん全部をだいたいできるわけじゃないので、基本的なものに限られる気がしますが。
-なるほど。
-そんなことするのかな。
-できないことはないという感じですかね。
-いや、どうなったろうな。ちょっとなんかマジで触ったことないか的なこと言ってる気がするわ。
-ちょっと。
-確かにWSL2とかそういうの使ってる分にはそれはそうなんですけど、Windows側で確かにDockerでストップ動かしてるとどうやってやるんだろうな。
CPUアーキテクチャの違い
なんかAI君に聞く限り、WSL2をバックエンドとしてそっちで動かしてるみたいな。
-なるほど。そうなんだ。じゃああれですかね、Docker Desktopを使いたい場合はそのWSL使ってなくてもWSLを有効化しなきゃいけないみたいな何がしかがあるんですかね、きっと。
-それだっぽい。
-なるほど、なるほど。そうか、そういうことだったのか。
-それだったらまあ理解できませんね。
-完全に理解できました。ありがとうございます。
で、ここまでが。
-CPUアーキテクチャの違いは絶対残るんですよね。
何だっけ、例えばARMとAMD64ってあるじゃないですか。
ARM64とAMD64。
-そうですね。ARM64、AMD64ありますね。
-ことあるCPUアーキテクチャでビルドしたそのアーキテクチャ専用のイメージとかは違うところで起動できないんですよね。
-まあそうでしょうね。
-例えば、昔M1とかでやった時とかはARMだからAMDのところでプルしても起動できないんだ。
-そうですよね。
-だから起動するにはロゼッタ使わないといけないみたいな。
-とか今だと例えばMacのCPUで起動する時には、
from何々の後に何かしらこれはx86でビルドされたやつですよみたいな何かコマンド書かなきゃいけないとかありましたよね。
-そうですね。
あれはCPUに依存した形で最適化されてるから多分そういうCPUを呼び出す命令がないんでしょうね。
DockerとOCIの標準化
だからマルチアーキテクチャのどっかイメージとかだとどっちもいけるみたいなやつありますけど。
-なるほどなるほど。あれそうかそういう事情だったんですね。
なるほど。基礎は理解できた気がします。
-はい。よかったです。
ここからはもうなんかあれですよね。もう実際にプロダクションで動かす時にどうなってるのかみたいな話になりますけど、
こうなるともうなんかちょっと別にインフラとかやってないとあんまりこうピンとこないから微妙なとこですね。
知らなくていいんじゃないかっていう。
-それで言うとなんかさっきちょっとお話しされていたどっかのイメージ自体がOCIっていう標準規格に準拠してるっていう話ですよね。
言ってみたらそれに準拠しているから何というかあれですよね、多分AWSのECSとかDockerっていう名前使ってないですよね多分。
何というかそういうところでも動くイメージをDockerコマンドで作れるっていう事情なのかなと、もしかしたらそうなのかなと察したんですけど。
-そうですね、いやなんかもともとDockerがコンテナ全部やってますみたいな感じだったんですけど、
いやもともとそのコンテナもちろんLXCとかSolarisのなんかゾーンみたいな概念から来てDockerっていう潮流があったんですけど、
あまりにもDockerが人気ですぎてコンテナイコールDockerみたいな風潮になった時に、
GoogleとかAWSとかRed Hatとかが、なんかね旗から見てると潰しにかかってる感じがあったんですよね。
-ほう、そうなんですね。
-そんなの?いやなんか、クバネテスが別に潰しに行ってたような感じではないと思うんですけど、
例えば、もともとクバネテスってDockerをベースに動いてたんですよ、そのコンテナを動かすところは。
-あ、そうなんですか。
-ただ、やっぱこう標準化みたいな波をめちゃくちゃこう皆さんが打ち出してきて、
もともとはコンテナイメージってDocker社の標準企画だった、標準っていうのは独自企画だったのに、
そこからみんなが使えるようにってことでOCIっていうものを作ってそっちに寄せて、
で、Dockerの中身をなんかコンテナを作って動かすところと、
なんかもうちょっとプリミティブなところみたいな感じの、
なんか2つにさらにランタイムを分けるみたいなことをやったりして、
で、片方を標準化したりとか、
ゲームにするとなんかコンテナDとランCとかあるんですけど、
そういう感じのなんかね、どんどんDockerのね、要素技術をね細かくなんか標準化してって、
なんか奪ってったみたいな感じの。
ドッカー社がなかなか不憫ですね、それは。
いや、マジ不憫だった。Dockerなんかね、お金なかったっぽいんですよね。
Docker自体ってお金生まないから、その後Docker Swarmとか、コンポーザーはお金生まないか。
そうですよね。
Swarmのエンタープライズ版とか出したりしたんですけど、
Akumaのデスクとかでできちゃったし、
だからあんまりこう泣かず飛ばずで、
だからDocker Desktopで結構お金を稼ぐというか。
そうですよね。Docker Desktopを会社で使うときは、
しっかりエンタープライズで入って、
Docker社のレベルにしようみたいなことはみんなそういう意識でやってますもんね。
そうですね。でもDocker Desktop、お金払いたくないっていう人もいっぱいいるかな。
だいたいツールいっぱいありますし、
レッドハットが出してるポットマンっていうやつとか、
あとコリマっていうやつ。
なんかあるんですよ。
あるし、AWSも前なんか出してた気がするんですけどね。
そういうので、いろいろみんなDockerを使わずにやってやろうっていう感じのムーブで、
割とそうして残ったのが、Dockerの便利な仕組みだけだったっていうことですね。
そう、Dockerの便利な仕組みはコンポーズとか。
でもコンポーズも劇場なんかローカルで動かすには良いけど、
クラウドを動かすときはコンポーズ使わないしね、ほとんど。
まあそうですよね。
だから割と見てて不便なんですけどね、Dockerは。
確かに。
まあちょっと何の話だっけこれ。
あの標準化企画。
OCIの話か。
そうですね。
OCIとかもそういう経緯でできましたね。オープンコンティーナー一周。
なるほど。
団体もあった気がするわ、オープンコンティーナー何とかみたいな。
そうか、じゃあLAN-Cの方も標準化が進んでるってことですね。
そうですね。今なんかもう本当にKubernetesも標準化の嵐で、
ネットワークも標準化され、ストレージのインターフェイスも標準化され、
何とか何とかみたいな感じでいっぱいいろんななんかを継ぎ吐きがありますね。
もちろん便利なんですけど。
そうなんですね。
例えばKubernetesの話で言うとコンテナがいっぱい起動するわけじゃないですか。
いろんなノードに。
さっきの話でコンテナが外に出るためには一応簡単に出れるけど、
外から中に入っていくのは厳しいよねみたいな話しましたよね。
そうなった時にじゃあ複数ノードがある時に、
そのノードにそれぞれ起動しているコンテナ同士が通信するって大変そうじゃないですか。
なんとなくそんなイメージはありますね、そうなると。
だからなんでこれはなんか特殊なネットワークを用意しないといけないんですけど、
それを実現するためのプラグイン、CNIのプラグインって言うんですけど、
コンテナネットワークインターフェイスプラグインかな。
それもね多分10とかあるんですけど、
それを何に使うかっていうのは結構人によって違いますし、
ただそうすると困っちゃうから共通インターフェイスをKubernetesの方で定義したみたいな。
あ、Kubernetesかな?ちょっとごめんなさい、全然違かったかも。
へー、そうなんだ。
そういうのがあります。
これはもうコンテナの話じゃなくなったんで大丈夫です。
プラットフォーマーの政治力を感じちゃいますね。
そうですね、ドッカーは政治力あんまりなかったのかな。
だってコンテナなんて、ドッカーなんて最初なんか出た時に急になんか、
いや、ドッカーの思想は良くないみたいな感じで、
ロケットとかいう何か会社が、何だったっけ、コアOSみたいなの出した気がするし。
あ、ロケットか、ロケットを出したのかな。コアOSがロケットを出したのかな。
へー、コアOSがロケット。
ほんとね、ずっとバチバチしてたイメージしかない。
なのでちょっと不遇の歴史という感じがございます。
これは別にでも知らなくていいと思いますね。全然あの。
いや、でもとても興味深いですね。
そういうことを知ってるだけで、歴史に思いを馳せ、
そしてやっぱりこういう流れを組んでこうなったんだなって理解が湧きやすいじゃないですか。
これもまた文化人類学的な観点で。
優れた技術を生み出しても、ちゃんとロビー活動ができないと、
ちょっといいようにやられてしまうということはよくわかりました。
なんというか悲しいですね。
ちょっとだいぶニッチな方向に行っちゃいましたが、
とりあえずですね、現場のエンジニアはこれぐらいのことを理解しているんだよということが共有できたかなと思います。
途中までのマジで、ネットワークぐらいまでの話まで大丈夫なので、ぜひですね、理解してみてください。
このポッドキャストをハッシュタグURITで皆様からの感想やコメント募集しております。
KubernetesとCNIプラグイン
またチャンネルの概要欄にありますGoogleフォームのリンクからもご投稿可能です。ありがとうございました。
ありがとうございました。
