2014年は非常にDockerが盛り上がった1年でしたね。

Dockerは2013年の夏ごろから注目を集めはじめました。その後バージョンが0.9となった2014年の春ごろからさらに注目を集めるようになり，それ以降はさまざまなサービスやベンダーがDockerをサポートしたり，Docker関連のプロダクトを出したりするニュースが駆け巡った気がします。

Dockerに関係する勉強会が数多く開催されるようになり，Docker Meetup Tokyoなどは募集が始まった途端に定員に達するという活況ぶりでした。

Dockerは「コンテナ技術」そのものではなく，Dockerがやりたいことを実現するための技術要素の1つとしてコンテナを使っています。このDockerの盛り上がりと共にそれまでどちらかというとマイナーな技術であった「コンテナ」も2014年には非常に注目される技術となりました。

実際，筆者が主催しているコンテナ型仮想化の情報交換会の2013年6月に開催した第1回は参加者7名でした（※1）が，2014年9月に開催した第4回は募集開始から数時間で定員に達する活況ぶりでした。

Dockerは2015年にはさらに盛り上がり，周辺プロダクトが充実していき，プロダクション環境に投入しやすい環境が整っていくように思います。

しかしDocker周辺の話題となると，業界の動きや周辺プロダクトの話題が主なものになっていき，「⁠コンテナ技術」そのものがDockerに関する話題とともに語られることは多くないような気がします。それはDockerに必要なコンテナとしての機能は今でもLinuxカーネルに一通りは揃っているように思えるからです。

2013年2月にリリースされた3.8カーネルで，Linuxカーネルに実装されるコンテナ関連の技術でとりあえず必要な大物の機能は揃ったように思います。しかし，機能が揃ったここがゴールというわけではなく，ここから色々なシーンでコンテナが使われはじめるということです。

それと共に，現時点で存在するコンテナ技術や周辺の技術だけでは足りない部分が多く出てくるようになるでしょう。システムコンテナとして使われることの多いLXCの開発コミュニティ周辺を見ていると，そのような「足りないもの」に関する議論を目にすることもあり，今後「コンテナ技術」そのものやその周辺の技術がどのように改良され，さらに進化していくのかをうかがい知ることができる気がします。

今回はそのように見かける議論のうちから，2015年にコンテナに関連する技術で，より議論が深まっていきそうな機能や，実装や改良が進んでいきそうな機能を紹介したいと思います。

※1）

参加者は少なかったけど中身は熱かったです。筆者が初めてDockerを知ったのもこの勉強会です。:-)

Cgroup

cgroupの今後については連載 「LXCで学ぶコンテナ入門 ─軽量仮想化環境を実現する技術」の第5回で紹介しました。現時点でもそこに書いた内容から大きく変化はありません。

第5回で書いたcgroupの単一階層構造は3.16カーネルでマージされています。この機能はcgroupfsをマウントする際に__DEVEL__sane_behaviorというオプションを付けると使えます。オプション名が 「まともなふるまい」 となっていて面白いですね。まだ__DEVEL___と付いている開発途上の機能です。

この機能が2015年に正式な機能となるかどうかはわかりません。しかしより完成度が上がっていくでしょう。いずれはsane_behaviorがデフォルトとなり，文字通りCgroupが「まともに」なるわけですね。

それとともに，まともなCgroupを前提とした現在のコンテナを改良する技術が出てきたり，Cgroupの管理を目指しているsystemdなどのソフトウェアできちんとCgroupを管理するインターフェースが整っていき，cgroupfsを直接操作する場面はなくなっていくでしょう。

また，第5回であわせて紹介したmemoryサブシステムのカーネルメモリの使用を制限する機能も実装が進むでしょう。さらに，memoryサブシステムではここしばらく，かなり性能の向上を実現するパッチが投稿されていました。

コンテナが市民権を得たので，カーネルの開発でもCgroupのコードの最適化が行いやすい環境になっているようです。この辺りはmemoryサブシステムの改良に関するお話とあわせて，コンテナ型仮想化の情報交換会の第4回で@hiro_kamezawaさんに「cgroupあれこれ」というセッションでお話をいただきました。発表資料と動画を公開していますので，興味のある方はぜひご覧ください。

今後も以上のような部分を中心にcgroupの改良が進んでいくでしょう。他にさらっとcgroup関連の議論をみたところ，cpusetサブシステムを改良するパッチが投稿されているようでした。

デバイス

コンテナは仮想マシンとは違い，名前空間やCgroupによって物理リソースやカーネルリソースを隔離しているだけですのでホストOS環境とコンテナ環境で独立していない部分が多くあります。

その中で，コンテナで独立して使いたいという議論がよく起こるのが デバイス です。

連載 「LXCで学ぶコンテナ入門 ─軽量仮想化環境を実現する技術」の第15回でコンテナ内でサウンドを取り扱う際もホスト側のデバイスファイルをバインドマウントしていましたね。

2013年には"Device Namespace"という提案がなされ，それに続いてデバイス名前空間の議論が起こっていました。しかし，デバイス名前空間が必要だという側でも十分に議論が整理されておらず，いろいろな話が出て発散しそのまま議論がフェードアウトしていました。

その後しばらくデバイスの議論は息を潜めていましたが，2014年にdevtmpfsをユーザ名前空間内で使えるようにするパッチを元に議論が再燃します。このパッチ自身はデバイス名前空間でなく，ユーザ名前空間内でmknodができない問題を解決するパッチでした。

このパッチに関してはすぐに不要であり問題があるという異議が出ていました。しかしその後議論が進むにつれ，コンテナ内でサポートする必要のあるデバイスもあるのではないかという話になっています。たとえば ループバックデバイス に関しては必要であるというある程度の合意が得られているようにみえます。

これはコンテナごとに必要に応じてループバックデバイスを持てるというもので，その後パッチが投稿されていました。しかし，細かい仕様に関してはまだ議論が必要そうでした。パッチを投稿された方も一旦別の実装にとりかかっているためペンディングになっているようです。2015年には再度この実装のパッチが投稿されたり，議論が行われたりするのではないでしょうか。

この他にもコンテナで独立したデバイスを使うユースケースとして，コンテナごとにデスクトップ環境を使いたい，コンテナ内でiSCSIを使いたい，スマートフォンのようなデバイスで複数のコンテナ環境を動作させ，デバイスを切り替えて使いたいなど色々なケースがあるようで，一部は先に紹介した提案の"Device Namespace"のようにパッチが作られたり，カーネルでなくユーザ空間のデーモンでうまく工夫して実現する実装がされていたりするようです。

このようないろいろなユースケースに対する合意は全部得られているわけではありません。しかし今後議論が深まるにつれ現在は不要とされている機能が必要という議論に発展していき，カーネルに実装されていく機能も出てくるかもしれません。

2015年にすぐに実現しそうな機能はないかもしれません。しかし2015年もコンテナ内のデバイスに関する議論は深まっていって，適当な着地点により近づいていくでしょう。