2015年のLinuxのコンテナ技術

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年にコンテナに関連する技術で、より議論が深まっていきそうな機能や、実装や改良が進んでいきそうな機能を紹介したいと思います。

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年もコンテナ内のデバイスに関する議論は深まっていって、適当な着地点により近づいていくでしょう。

ユーザ名前空間

ユーザ名前空間（User Namespace）は3.8カーネルで実装された、現時点では一番新しい名前空間です。連載の第16回で解説した通り名前空間の外、つまりコンテナの外では一般ユーザですので、名前空間内で特権を持つからと言って、ホストOS上のrootのように何でもできるわけではありません。

ユーザ名前空間内の特権ユーザができる操作についてはまだこれから議論がされていくようで、たとえばUbuntuでは非特権コンテナ内からoverlayfsがマウントできるようにパッチが当たっているようですし、BtrfsについてはLKMLでそのような提案がされているようです。

そんな中、実際に議論が進みパッチが投稿されているのが非特権コンテナ内からFUSEマウントをする機能です。細かい議論は私は見ていませんが、順調に投稿されているパッチのバージョンは上がっていっているようです。

一番新しい名前空間ですのでまだバグも多く、セキュリティとの関連が深い機能でもありますのでセキュリティホールに絡む修正も多いようで、ユーザ名前空間に関係するパッチはまだまだ大量に投稿されています。

2015年も機能の追加、修正がどんどんなされて、より安全に便利に非特権コンテナが使えるようになっていくのではないでしょうか。

新しい名前空間の提案

ユーザ名前空間の実装により一通り必要な名前空間が揃いました。しかし、これでコンテナを運用していく上で必要な名前空間の機能が全て揃ったのかというとそんなことはありません。現時点でもまだ色々な新しい名前空間の提案がなされています。

そのひとつで最近提案がなされているのが"CGroup Namespaces"です。現在、Cgroupはコンテナごとには仮想化されていません。そこでLXCでは必要に応じて必要なCgroupのみをバインドマウントするという方法でコンテナからCgroupを使っていました。これを名前空間で隔離しようという機能のようです。

他にはセキュリティ関係の名前空間の提案がされています。これはコンテナごとに独立してSELinuxやAppArmorなどのセキュリティ機能を使えるようにするための機能のようです。ただし、具体的なモジュールの実装ではなく、各セキュリティモジュールで名前空間が実装できるような名前空間の入れ物のような機能のようです。

他にも、以前から必要と言われて議論がされている名前空間もあります。たとえば、現状カーネルログは隔離がされていないため、ホストに関わるカーネルログがコンテナのsyslogにも出力されたりします。最近は議論を見かけないですが、以前はこれを解決する名前空間が議論されていました。

このようにコンテナの作成や起動に絶対必要な機能が一通り揃って、コンテナの利用が広がるに従い、コンテナの実運用で必要な機能が洗い出されてきて、それに対する提案と実装が出てくる段階になっているのでしょう。今後も新しい名前空間が提案され、追加されていくかも知れません。

overlayfs

3.18カーネルでoverlayfsというファイルシステムが追加されました。overlayfsは特にコンテナ用の機能というわけではありません。しかしコンテナで使うと便利ですので紹介しておきましょう。

Dockerが話題になったとき、その特長の一つとしてaufsというファイルシステムを使ったイメージの差分管理ができる特長があげられていました。overlayfsはaufsと同じ重ね合わせのできるUnionFSの実装の一つです。

aufsを使うにはパッチを適用してカーネルをビルドする必要があるのに対し、overlayfsはカーネルへのマージが済んでいますので、パッチを当てる必要がありませんから、今後は各種ディストリビューションで標準で使えるようになっていくでしょう。

Ubuntuでは従来からパッチを適用する形でoverlayfsが使えるようになっており、12.04 LTSの頃から使用可能でしたので、LXCでは以前からoverlayfsに対応していました。今後はUbuntu以外でも標準で使えるようになっていくでしょうから、overlayfsの利用が進むのではないでしょうか。Dockerでもストレージバックエンドでoverlayfs対応のものがマージされています。

ただし、Ubuntu 14.04 LTSの時点のoverlayfsと3.18カーネルでマージされたoverlayfsの間には仕様の互換性がなく、マウントオプションが異なり、ファイルシステムの変換も必要です。

LXCでは筆者が作成したパッチがマージされていますので、1.0.7以降ではマウントオプションに関してはどの時点のoverlayfsでもマウントできるようになっています。

しかし、現時点ではファイルシステムがどの時点のoverlayfsで作られたのかを簡単に検出することが難しい場合が多いので、LXCではファイルシステムの変換については特に対応していませんので注意が必要です。

またマージされたばかりですので、まだどんな場面でもoverlayfsが使えるというわけではなさそうです。たとえば、3.18の時点のoverlayfsはext4以外のファイルシステム上では使えないようです。今後も細かい改良が続いていくでしょう。

Checkpoint/Restore

ここまではカーネル周辺の話題を見てきましたが、ここからはコンテナの実装周辺の話題を見てみましょう。

まずは最近急速に実装が進み、一気に実用段階に達したように見えるCheckpoint/RestoreもしくはCheckpoint/Restartと呼ばれる機能です。筆者はこれが2015年のコンテナ周辺の一番の目玉機能ではないかと思っています。

この機能は実行中のプロセスの状態を保存して、保存した状態から再開させます。仮想マシンの実装ではライブマイグレーションという機能は既に実現されており広く使われています。コンテナで同様の機能を実現したいという要求に応える機能です。

もちろんコンテナは隔離化された普通のプロセスですので、CRIUはコンテナでなく普通のプロセスでも使えます。

これを使うユーザ空間の実装としてOpenVZの開発者が取り組んでいたのがCRIU（Checkpoint/Restore In Userspaceの略）というツールです。

3.3カーネルのころからこの機能に必要な機能がかなりの数マージされるようになり、3.11で一通り実装が完了し、2013年末にCRIU 1.0がリリースされました。その後も精力的にバージョンアップが続き、2014年9月の1.3の頃にLXCとDockerに対応しました。2014年12月リリースのCRIU 1.4ではDockerコンテナのCheckpoint/Restore用のスクリプトが付属するようになっています。

LXCでも同じ時期にlxc-checkpointコマンドが実装され、次にリリース予定の新しいバージョンである1.1ではCRIU対応となります。

LXCコンテナのマイグレーションについてはコンテナ型仮想化の情報交換会の第5回で私がデモを行っており、特に問題なく動作します[2]⁠。

現時点ではCRIUの動作に必要な設定や条件が存在し、まだどんなコンテナについても問題なくCheckpoint/Restoreできるわけではありません。しかしここまでの開発スピードを見ていると、2015年もどんどん完成度が上がっていくことが期待できる気がします。

2014年末でCRIUできちんとCheckpoint/Restoreできる準備が整いました。この機能を使うとコンテナをデプロイする場面や運用の場面での可能性が色々と広がるような気がします。

2015年には、この機能を使った面白い試みが色々出てきたり、多数のコンテナを管理するためのプロダクトでこの機能を採用してライブマイグレーションを行う動きが出てくるのではないでしょうか。前述のようにCRIUはコンテナ専用の機能というわけではありませんので、コンテナという枠を超えていろいろと面白いことができそうです。

LXC

LXCは2014年の2月に1.0がリリースされました。それまでもその後しばらくもホスト上できちんとコンテナが作成でき、起動ができるという点をまじめに追求してきました。12月に1.0.7がリリースされ、かなり完成度が上がっていますので、そろそろ完成度を上げるという点ではやることが少なくなってきた気がします。

それに伴い1.1リリースの話が出てきており、予定では2015年1月にリリースの予定になっています。1.1の新機能の目玉は前述のCRIUによるCheckpoint/Restoreサポートと、最近のバージョンのsystemdへの対応です。

この原稿を書いている12月中旬の時点ではまだsystemd対応は終わっていないようなので予定通りリリースされるかは不明です。しかし1.0リリースの時の追い込み具合を考えると、すごいスピードでコードがマージされて予定通りリリースされることも十分考えられます。

LXCはUbuntuの開発者がメインで開発されていますので、これまではまずUbuntu上で動作することを確認してから、Fedoraなどのsystemdを採用したディストリビューションでの問題をつぶしていくという開発の進み方になってしまっていました。しかし今後はUbuntuではsystemdへの移行が行われるということで、ここできちんとsystemdへの対応を行っていこうということだと思います。

今後はこれまでのようなタイムラグはなく、新しいリリースのLXCをsystemd採用のディストリビューションでも利用できるようになるはずです。色々なディストリビューションで新しいバージョンのLXCがすぐに安定して使えるようになっていくでしょうから、LXCが使いやすくなりますね。

LXD

前述のようにこれまでLXCはLinuxカーネルに実装されている機能をフルに使って、コンテナ環境をきちんと動作させるという点に注力してきました。そのためどうしても具体的な開発や運用のさまざまな問題に対応していく機能をスピーディーに実装していくDockerに比べると話題性という点では劣っていた気がします。

しかし、コンテナ環境の実現という点で完成度が上がったところで、LXC周辺でも動きが出てきました。それがLXDです。

LXDはLXCの置き換えではなく、liblxcを使ったLXCコンテナを管理していくための仕組みです。liblxcのGoバインディングを使って開発されています。

LXDは

REST APIを提供するデーモン
コマンドラインクライアント
OpenStack Novaプラグイン

から成ります。

これにより、ホスト上のローカルな環境のコンテナを扱うだけでなく、ネットワーク越しのコンテナホストとコンテナの管理が行えるようになり、さらにはコンテナホストがOpenStackのコンピュートノードとして使えるようにもなりますので、コンテナを使ったプラットフォームの構築の可能性が大きく広がるでしょう。

前述のCheckpoint/Restoreにも対応してライブマイグレーションができるようになるようです。

またLXCはテンプレートを使って手元でコンテナイメージを構築するという印象が強かったのに対し、LXDではDockerのようにイメージの使用を前提とする環境になるようです。

これまでLXCはコンテナを作成して起動させるだけでした。LXCを使ったLXDというプロダクトの開発が始まったのは、LXCがある程度の完成度に達し、より具体的なソリューションを行うプラットフォームの1つのパーツとして使われていく準備が整ったということだと思います。

11月はじめに発表された時点では、ドキュメントだけでコードは存在しない状態でした。その後開発が進み、原稿執筆時点の12月中旬ではかなりの機能が実装されており、とりあえず試してみることはできるようになっています。

メーリングリストへのパッチ投稿を中心とした開発のLXCに比べて、LXDはGithubへのプルリクエストを中心とした開発でスピード感があります。2015年に入ってもかなりのスピードで機能の実装が進むのではないでしょうか。

LXDにより、LXCコンテナを大規模にデプロイするような環境を構築しやすくなります。このような場面では一歩先を行っているDockerに少し近づく基盤ができつつあります。

2015年は複数のコンテナが連係する環境を構築する場合、候補としてDocker以外にもLXC/LXDが検討できるようになっていくのではないでしょうか。選択肢が増えることで検討の余地が広がるのは良いことですね。LXDによってLXCにも大きな飛躍のチャンスが来たように思います。

LXCFS

以上のようにLXDはLXCを使ったプラットフォーム構築や運用を解決していくためのソリューションです。それに対してLXCを使ったコンテナ環境内部の運用環境を改善していくためのツールとしてLXCFSというFUSEを使ったファイルシステムの開発が始まりました。

Linuxのコンテナでは/proc以下は最低限の仮想化はなされているものの、cpuinfoやmeminfoなどのリソース情報についてはホストOSと同じ内容が見えており、たとえばfreeコマンドのような一般的にサーバ管理の際に使用するようなコマンドを使うとコンテナのリソース消費の状態でなく、ホストOS全体の状態が見えていました。

これを解決するためにcgroupから情報を取得してコンテナに提供するなどの機能を持ったLXCFSの開発が始まりました。他にも非特権コンテナ上でcgroupfsを使えるようにする機能が実装されるようです。

LXCFSは12月の中旬に開発が始まりました。おそらくLXC 1.1でのsystemd対応と合わせて、systemd環境での非特権コンテナを動かすためのパーツの1つとして考えられているようなので、しばらく急速に開発が進み、とりあえず動くものが2015年早々にも登場するかもしれません。

まとめ

2014年はLinuxカーネルに標準で実装された機能だけでコンテナ環境が安定して動く環境が整った年でした。コンテナの利用が進むにつれ、コンテナの適用や実際の運用の場面でまだ足りない機能が続々と洗い出されてきている状況だと思います。

それがより洗い出され、2015年はコンテナを運用していく上での色々な解決するための実装がより進み、コンテナを利用する環境がより整っていくでしょう。

それに伴い、コンテナを使った面白いプロダクトやサービスが2014年以上にたくさん出てきそうで楽しみです。今年もコンテナから目が離せませんね。