Windowsコンテナ on Openshift はどうやって動いているのか
Google I/OとMicrosft Buildが5月の第2週に重なっていたことは先週書きましたが、同じ週にRed Hat Summitも開かれていたようです。そこで、OpenShift on Azureの提供を開始することが発表されました。
Red Hatとマイクロソフト、共同でAzure上にOpenShiftのマネージドサービスを提供へ。OpenShiftでWindows Serverコンテナも利用可能に
OpenShift on Azure自体はずいぶん前に発表されていたのですが、やっと実サービスが提供開始されるということですね。（といってもまだ数ヶ月後ですが）
私が今回気になった（というか、思い出した）のは、「OpenShiftでWindows Serverコンテナも利用可能に」というところです。OpenShiftってLinuxですよね。なんでその上でWindowsコンテナが動くの?
そもそもコンテナというのは、ホストOSと同じOS用のアプリケーションでないと動かないはずなんですよね。以前も発表されたときに疑問に思ったんですが、そのときは調べてもよくわからなかったのです。
コンテナの歴史
元々コンテナというのは、Linux上でアプリケーションを分離させて動かす技術（LXC）が元になっています。LXCのさらにご先祖様がUNIXのchrootということで、Winkipediaによると「ビル・ジョイがインストールおよびビルドシステムのテスト用に作成したのが起源である。」ということです。ソフトウェアの開発時に、アプリケーションが暴走して他のプロセスを止めたりマシン全体をダウンさせたりすることを防ぐ為に、マシン内に隔離された環境を作りたいという要求から生まれたものと推察されます。
しかし、これはあくまでも開発のためのもので、隔離はしても同じディスクが見えたり同じIPアドレスを使うことになり、セキュリティ上の問題が発生する可能性があります。この辺を強化して、仮想マシン的な使い方ができるようにしたのがコンテナであり、コンテナを管理する技術がDockerです。
このようにコンテナはLinuxというOS上に隔離された環境を作るだけですから、そこで動くのはあくまでもLinux用のアプリです。逆に言えばOSの大部分をコンテナ間で共有することで、リソースやオーバーヘッドの少ない、軽量な環境が実現できるのです。
なぜ違うOSでコンテナが動くのか?
これに対して仮想化は、物理マシンの上に仮想的なマシンを構築し、その上にOSやミドルウェア、アプリをインストールして利用します。仮想マシンは完全に独立したマシンで、OSも自由に選択できます。しかし、ライセンスは個々に必要になり、メモリもディスクスペースも通常のマシンと同じだけ必要になり、仮想マシンの立ち上げ時には通常のマシンを立ち上げるのと同じ時間がかかるわけです。
しかし、Windowsコンテナ on OpenShift（Linux）では、Linuxの上でWindowsコンテナが動くと言っているわけです。これは、どういうことなのか?
今回改めて調べてみて、答えらしきものを見つけました。
この中で、このようにコメントされています。
この機能では、『Hyper-V』の隔離技術を活用することで、コンテナをサポートできるだけの必要最小限のOSを用いてLinuxカーネルを稼働させるようになっている。
コンテナの中にOSのサブセットが含まれていて、ハイパーバイザーの技術を使って動かしているということですね。コンテナと仮想マシンのハイブリッドのような感じでしょうか。これはOpenshift上でのWindowsコンテナの話では無く、Windows上でのLinuxコンテナの話ですが、逆も恐らく同じ仕組みでしょう。SQL Server on LinuxもWindows on ARMも同じ考え方ですね。Windowsのソースコードを持っているMicrosoftだからできることではあります。
コンテナのメリットは維持できるのか?
ここで疑問なのは、Windowsコンテナ on Linux（OpenShift）やLinuxコンテナ on Windowsが、コンテナと仮想マシンのハイブリッドのような構造になっているのだとすれば、リソース消費や起動時間が短いというコンテナのメリットが薄れてしまうのではないかということです。
もちろん、多少遅かろうがOSを選ばずにいろいろなコンテナが動く方が便利に決まっています。SQL Server on LinuxもWindows on ARMもそうですが、Microsoftは、ベストでは無くともベターから始める、動かないよりは動く方が良い、という考え方でいるのかも知れません。