新春特別企画

2015年のLinuxのコンテナ技術

この記事を読むのに必要な時間:およそ 5.5 分

ユーザ名前空間

ユーザ名前空間(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はコンテナ専用の機能というわけではありませんので,コンテナという枠を超えていろいろと面白いことができそうです。

※2)
DockerコンテナのCheckpoint/Restoreも以前試したのですがうまくいきませんでした。今ならうまく行くかも知れません。

著者プロフィール

加藤泰文(かとうやすふみ)

2009年頃にLinuxカーネルのcgroup機能に興味を持って以来,Linuxのコンテナ関連の最新情報を追っかけたり,コンテナの勉強会を開いたりして勉強しています。英語力のない自分用にLXCのmanページを日本語訳していたところ,あっさり本家にマージされてしまい,それ以来日本語訳のパッチを送り続けています。

Plamo Linuxメンテナ。ファーストサーバ株式会社所属。

Twitter:@ten_forward
技術系のブログ:http://tenforward.hatenablog.com/

バックナンバー

新春特別企画

バックナンバー一覧

コメント

コメントの記入