コンテナ型仮想化とDocker
コンテナ型仮想化は便利である。chrootの時代から、jailの時代から、LXCの時代を経て、Dockerへ。
docker pullしてdocker runすれば、面倒なインストールなくサービスが動き始めるなんて、実に簡単ではないか。
Dockerfileに導入手順を記載しているようなものなので、構成管理もばっちりである。
本当か？
Dockerは少しやりすぎじゃないのか？
dockerhubに転がっているイメージをベースに何かしようとすると、そのイメージのベースはCentOSだったりDebianだったりする。それを動かしているホストはUbuntuで動いていたりする。
これ、本当に構成管理といえるのか？
systemcallに何か変更があったらアウトよね。まあそれくらい枯れてきたってことなんだろうけど。
だから、Dockerは出来上がったアプリケーションをブラックボックス化するパッケージングシステムと考えるのがよい。
すでにDocker環境ができあがっているものを起点として、ソースをいじりながら何かしようとすると、さらにその環境がよく分からないことになっていたりすると、わりと地獄である。DevOpsといいつつ、DevもOpも地獄になる。つらい。
だけど、黒魔法がDockerfileに既述されるようになっただけでも、マシだとも考えられる。
Dockerはサービスのパッケージである
割り切って考えてみよう。Dockerは「サービスをパックしたもの」である。
そう考えた時、docker runで走って欲しいのはサービスである。仮想環境で動くフルスペックのOSではない。
だから、コンテナ向け軽量distroなんてのも出てきているけど、アプリの実行環境が動けばよいと言って思い出すのが、OSvなどのライブラリOSである。
ライブラリOSが動けばいいんじゃねえの？
いやいや、あれは足回りをvirtioなど簡素なものにしてメモリ管理などをハイパーバイザに押し込んでいるわけで、コンテナからはLinuxカーネルが見えているわけで、全然違うだろ。
そうね、そうだよね。違うよね。
でもね、あたい、思うんだ。コンテナの中にLinuxカーネルは必要なのかしらって、ね。
たとえば、Dockerfileから、Linuxカーネルを必要としない何かしらの環境用のイメージを作る方法……無理だ。Dockerfileの中や、entrypointの中でごちゃごちゃできすぎている。
特にentrypointの中でgit cloneして最新版に更新するぜとかやってる奴いるからな。
どうしよう。
entrypoint云々を無視すると、できあがったイメージから、libcの部分をするっと抜いて別のライブラリに置き換えて……違うな。
問題意識をもう一度整理してみると、サービスのパッケージを動かすのに、足回りにでかいdistro、あるいはでかいカーネルを引きずる必要はないんじゃないのか？ということだ。
こういったことを以前からごちゃごちゃと考えていて、実はそれはDockerがどうのではなくて、セキュアな基盤をうまいこと作れないかという文脈でなのだが、なかなかまとまらない。
同時に、対話的shellと実行環境と開発環境が混在しているUNIXの世界が、ごちゃごちゃしつつも、実に面白い世界なのだよなと改めて実感していたりする。
多分その面白さとセキュリティをどう両立させるかというのは、ポイントのひとつなのだろうけれど。