今回も前回に引き続き、私がLXCプロジェクトに対して送ったパッチなどを紹介していきます。
overlayfsのworkdirオプション
第18回で紹介したように、Ubuntuでは以前からカーネルにoverlayfsのパッチが当たっており、overlayfsが使えるようになっていました。しかしこの時点では、3.18カーネルでマージされたoverlayfsと違い、workdirオプションが不要でした。
LXCでは、以前からストレージバックエンドとしてoverlayfsがサポートされていたこともあり、私はカーネルにマージされる前からoverlayfsを使っていました。3.10カーネルがリリースされる前に、そろそろoverlayfsがカーネルにマージされそうということで話題になっていたことも、興味をもった理由でした。
私は普段はPlamo Linuxで最新のカーネルをビルドして使っています。そこで新しいバージョンのLinuxカーネルがリリースされるたびに、対応するoverlayfsのパッチを当てて、手元の環境でoverlayfsが使えるようにしていました。
ちょうど3.15カーネルがリリースされたときに、overlayfsのパッチを当てて作ったカーネルでは、LXCでoverlayfsを使ったクローンが失敗するようになりました。調べてみると、overlayfsの仕様が変わりworkdirオプションが必要になったためでした。
他に同じ問題に遭遇している人がいないかを軽く調べてみましたが、見つけることはできませんでした。overlayfsがUbuntuとSuSE以外では使えませんでしたし、そのどちらもカーネルのバージョンが3.15よりも前だったため、おそらくLXCユーザが誰も気づかなかったからだと思います。そこで開発メーリングリストに報告し、パッチの作成にチャレンジしてみることにしました。
どのように実装するかについてはあまり良いアイデアが浮かびませんでした。そこで、一度workdirオプションなしでマウントしてみて、エラーだったらworkdirオプションを付けてリトライするという、あまりスマートでない方法で実装することになりました。
ここでストレージバックエンド周辺のコードを見ていたことが、あとで紹介するLVMストレージバックエンドの修正や、aufsの非特権コンテナのパッチ送付につながっています。このパッチを作成したおかげで、どのように修正すべきかのアイデアがイメージしやすかったです。
この直後にも他のパッチが原因で生じた、aufs/overlayfsを使ったクローンで起こる問題を解決するパッチを送付しています。
lxc-configの改良
lxc-configはLXCのシステム設定を表示するためのコマンドです。このコマンドを改良するためのパッチを送ったのは、この連載がきっかけです。
私はLXCのシステム設定を変更することはほとんどないので、連載で書くために初めてlxc-configを使いました。
それほど需要が大きなコマンドとも思えないので、第10回の記事中ではあっさりと紹介しています。しかし、第11回で紹介した通り、LXCのシステム設定を表示するコマンドなのにcgroup関係のシステム設定項目の表示ができません。
変だなと思ってコードを見てみましたが、やはりcgroup関係の設定を表示するコードは入ってませんでした。cgroupの設定だけ表示できないのは変ですし、lxc-configのコードを見る限りでは簡単に追加できそうでしたので、早速パッチを作って送付しました。
最初のパッチを送った後に、メンテナのSerge Hallyn氏からコメントをもらい後者のパッチを作成しました。作った時点では自信がなかったので、お伺いを立てるメールを出した所そのままマージされてしまいました。このため変なコミットログになっています(^_^;)。
この連載を書いていなければ送っていないパッチです。以下のように、バージョン1.1では以下のようにcgroup関係の設定が表示できるようになりました。
$ sudo lxc-config -l
lxc.default_config
lxc.lxcpath
lxc.bdev.lvm.vg
lxc.bdev.lvm.thin_pool
lxc.bdev.zfs.root
lxc.cgroup.use
lxc.cgroup.pattern
LVMストレージバックエンドのバグ修正
この修正もこの連載がきっかけでした。私が普段使っている手元の環境では、コンテナディレクトリである/var/lib/lxcはBtrfsになっていますので、この連載で紹介するまではLVMをストレージバックエンドとして使ったことはありませんでした。
そこで別の環境でLVMを使ったコンテナの操作をいろいろ試していました。すると第21回に書いたように、クローン先のコンテナを消去するとクローン元の論理ボリュームまで同時に削除されてしまい、クローン元コンテナを起動できない不具合を発見しました。あまり使っている人がいなかったのか、この問題はこの時まで見逃されてきていました。
これは大きな問題ですし、修正範囲が大きそうだなと思ってコードを追いながら少し考えました。すると、少し工夫すればすぐに修正できそうだったので、まずは修正の方針に関してメーリングリストでお伺いを立て、了解を得た所でパッチを作成した送付しました。
非常にシンプルな修正で済みました。
aufsを使った非特権コンテナ
これは比較的最近行った修正です。先日リリースされたバージョン1.1.3に含まれています。
ユーザ名前空間について検索していると偶然、非特権ユーザによるユーザ名前空間内でのaufsのマウントのサポートというメールを見つけました。
aufsが標準機能として、ユーザ名前空間内の特権ユーザがマウントできる機能をサポートしているのであれば、少し変更を加えればLXCでaufsを使った非特権コンテナがサポートできそうなので、早速パッチを作成してみました。
変更している部分は多いですが、実はoverlayfsストレージバックエンドと行う処理は同じなので、ほぼoverlayfsのコードと同じなのです。
一点だけ、aufsが内部で使用するxinoファイルを扱う部分だけがoverlayfsと異なり、ここは最初にパッチを送付した際にコメントが付きました。私はaufsについて詳しいわけではないので、そこはaufsのメーリングリストに質問を投げて疑問点を解決しました。
カーネルで標準的にoverlayfsがサポートされているのに、いまさらaufsを使ったコンテナのパッチを送る必要があるのか、と思われる方がいらっしゃるかも知れません。
実は、ユーザ名前空間内の特権ユーザであってもoverlayfsはマウントできません。にもかかわらず、なぜLXCでは一般ユーザによるoverlayfsを使ったスナップショットクローンがサポートされているのかというと、Ubuntuのカーネルにはパッチが当たっており一般ユーザがユーザ名前空間内でoverlayfsマウントできるからです。
つまりUbuntu以外のほとんどの環境では、現時点では一般ユーザがoverlayfsを使ってコンテナのクローンを行えません。
一方、aufsのパッチが適用されているディストリビューションは一部なので、使える環境は少ないかも知れません。しかし、最新のaufsが使える環境であれば特別なパッチの適用がなくても、一般ユーザがaufsを使ったクローンが使えます。
aufsの非特権コンテナがサポートされることで、少しでも一般ユーザ権限で起動するコンテナの可能性が広がるのではないかと思い、パッチを送りました。
同様に第23回で紹介したlxc-start-ephemeralコマンドでも、一般ユーザがaufsを使った一時的なコンテナが起動できるようにパッチを送付してあります。
linuxcontainers.org翻訳
ここまではLXCに対して送ったパッチの話でした。ここでは、LXCの公式ページを含むlinuxcontainers.orgのページの翻訳の話をしましょう。
LXC 1.0がリリースされたころにLXCの公式ページが作成されました。非常にシンプルなページでしたので翻訳を行い、メーリングリストで日本語サイトについてのお伺いを立てたところ、いろいろな言語のページが共存できるように考えるという返事をもらいました。
そこで、公式サイトで日本語ページが公開できる準備ができるまではlxc-jpプロジェクトで翻訳を行い、プロジェクトのページで公開していたところ、定期的にlinuxcontainers.orgにミラーして、日本語ページとして公開してもらえるようになりました。
その後、linuxcontainers.orgがLXCを含むいろいろなプロジェクトのページを含むようリニューアルされました。その際に、ページのメンテナンスをしているStéphane Graber氏が、いろいろな言語の翻訳を簡単に公開できるように考えて仕組みを作ってくれました。これも、それまでに翻訳をきちんと更新して公開していた実績があったからだと思っています。
今ではGitHub上にサイト用のリポジトリがあり、Markdown形式でコンテンツを作成し、Pythonで書かれたスクリプトで変換すると、言語ごとの公開用コンテンツが生成されるようになっています。
一度全体のコンテンツを翻訳した後は、リリースのたびのアナウンスを翻訳する作業が中心です。リリースアナウンスの英語は難しくないので、それほど手間がかかる作業とは思えないかもしれません。しかし、実はリリースアナウンスには読んでも良くわからない項目が結構あります。内部的な変更についてそのまま書かれている場合があり、ユーザ視点で「どのように動きが変わったのか」が分かりづらい項目もあります。
このような場合は、それぞれのプロダクトのコミットログを参照したり、パッチを参照したりして変更点を調べます。そのため、結構大変な作業になることがあります。最近はプルリクエストを投げたことをツイートすると、翻訳のチェックをしていただけたりするので助かっています。
翻訳を行いたい場合は、GitHubでforkを行い、自身のリポジトリで翻訳コンテンツを作成してプルリクエストを投げれば、マージされて公開されます。誰でも翻訳や既に公開されているページの修正ができますので、もし翻訳の間違いに気づいた場合や、もっと分かりやすい訳がある場合には、是非プルリクエストを投げてみてください。
まとめ
前回と今回で、私とLXCプロジェクトの関わりについて紹介しました。
マニュアルの翻訳は、よく言われる「OSSへの貢献はできるところでやれば良い」という大げさなものを当初から考えていたわけでなく、前回紹介した通り、自分の役に立つためにという理由で始めました。
しばらく翻訳を更新し、翻訳に対するチェックをしていただいたりした結果、人に見せても恥ずかしくないレベルになりました。そこで、翻訳があることで少しでも貢献できるなら、本家にマージしてもらおうと思い、プルリクエストを送りました。最初のきっかけは小さなものでも、継続していると少しはOSSへ貢献できるものですね。
また、マニュアルの翻訳は、英語を読むだけでなく実際にLXCの動きを試しながら翻訳を行ったりしましたので、LXC全体の機能や仕組みがよく理解できるようになりました。これが後のプログラムのバグや改良のパッチに結びついているように思います。同様に公式サイトの翻訳でも、一通りの使い方や新機能の紹介があるため、LXC以外のプロダクトについての理解も進みました。
私はプログラミングの能力も知識もそれほど高くはありません。ですので、前回と今回で紹介したプログラムに対するコミットをご覧いただくと分かる通り、それほど複雑で高度なパッチはありません。それでも機能をよく理解していれば、単純な修正で解決したり改良できたりすることもあります。よく使うOSSでおかしいなと思ったり、不便だなと思うところがあった場合は、少し調べてみると改良に結びつくかもしれませんので、皆さんも試してみてはいかがでしょうか。
最近LXCの周辺では、LXC以外にもいろいろなプロダクトがかなりのスピードで開発されているので、ひとりで全体の進化を追いかけるのはきつくなってきましたが、もうしばらくは可能な限り周辺の動きを追いかけていきたいなと思っています。
第8回 コンテナ型仮想化の情報交換会＠東京
9/26（土）に東京で、コンテナに関する色々な話題を扱う勉強会の開催を予定しています。現在参加者を募集していますので、ご興味のある方は是非ご参加ください。
