本連載でも何度か紹介しているコンテナ・仮想マシンの管理システムである「LXD」がCanonicalの管理になった結果、コミュニティ版の「Incus」が登場しました。詳しい経緯は「LXCで学ぶコンテナ入門」の第55回「コンテナと仮想マシンのマネージャ"Incus"」に記述されています。今回は少し趣向を変えて、「UbuntuユーザーはLXDとIncusのどちらを使うべきか」という観点から、Incusを紹介します。
UbuntuとLXDとIncus
冒頭でも説明したように、LXDのコミュニティ版フォークとしてIncusが登場しました[1]。
フォークに至った詳細な流れは「LXCで学ぶコンテナ入門」が参考になりますが、かんたんに説明すると次のような時系列になります。
この中でUbuntuユーザーに一番影響するのは、ライセンスと署名の項目です。このあたりCanonical側のスタンスがふわっとしていて少しわかりにくいのですが、LXDのソースコードとしては2023年12月13日以降のコミットは、原則としてAGPL-3.0-onlyのライセンスになります。2023年12月以前のコードについてはCanonicalによるものはAGPL-3.0-onlyに、コミットメッセージにApache-2.0でライセンスされると書かれている部分のみApache-2.0となるような表現となっています[2]。いずれにせよCanonicalとしては、サーバー向けのツールは原則としてAGPL-3.0-onlyを採用したいようです。
Apache-2.0とAGPL-3.0-onlyが混在すること自体はライセンス上問題とはならないようですが、ファイル単位ではなくコミット単位でライセンスが異なると、実運用上いろいろややこしい状態となりそうです。さらにCLA未署名のコードは入れられないということはつまり、Incusで行った修正をLXDに取り込むためには修正コードのライセンス変更が必要であり、さらにIncus側で修正した人のCLA署名が必要となります。少なくともIncus側のメイン開発者は、CLAへの署名を行わないと宣言しているため、事実上Incusの修正のほとんどはLXDに取り込めません。同様にIncus側はApache-2.0ライセンスを継続すると判断しているため、LXD側の修正をIncusに取り込むのも、修正の著作権を持っていない第三者にはできなくなります。
これらを踏まえると、現時点ではLXDとIncusは「決別した」と考えなくてはならないことになります。具体的にはLXD 5.20/Incus 0.4からそれぞれ別の道を歩み始めることになります。そこで出てくる次の問題が、「LXDとIncusどちらを使うべきか」です。まずはLXDとIncusのそれぞれの利点をまとめておきましょう。
- LXDの利点
-
- Canonicalのマネージドプロジェクトである
- Canonicalの開発資本が投入される
- Ubuntuサーバーには最初からインストールされている
- snapパッケージとして管理可能
- Web UIが最初から用意されている
- MAAS/Juju/Charm/RBACやsnapcraftとの連携が可能
- Incusの利点
-
- LXDのオリジナルの開発者が関わっている
- snapパッケージ以外を使える
- Ubuntu固有の機能がない
- 各ディストリビューションでかんたんにインストール可能
- 日本語のドキュメントが充実している
Ubuntu以外のユーザーにとっては、snapパッケージでないことはかなり大きな利点になるでしょう。これによりsnapに依存せずにパッケージを作れるようになりました。さらにDocker上でLXDを使うというのも選択肢として出てくるかもしれません。
Ubuntuユーザーにとっては、どちらを使うか悩ましいところです。MAASを使っているならLXDが必須となりますが、そうでない場合はどちらを使うかの判断がわかれるでしょう。折しも今年4月には2年ぶりのLTSであるUbuntu 24.04 LTSがリリースされることになります。ユーザーの多くも、そろそろ24.04の評価を始めている段階で、LXDとIncusのどちらを選ぶかもその評価に関わってくるかもしれません。一応、IncusとLXDを併用するという案もありますが、将来のリリースに渡って独立して動かせるかまではわからないところです。
一番気になるかもしれない「開発の活発さ」や「将来性」については現時点ではまだはっきりとした差はありません。ちなみに単純にIncusがLinux Containersプロジェクトになった2023年8月7日以降のマージコミットを除くコミット数をカウントすると次のようになります。
- LXD：901コミット
- Incus：1739コミット
Incusは0.4までLXDの修正も取り込んでいたこと、さらにLXDの古い機能の削除やIncusへの命名変更に伴う修正があったことから、コミット数は多めに出ています。それを抜きにしてもIncusのほうがまだ多めですが、コミュニティプロジェクトとして、今後もそれを続けられるかは未知数です。さらにライセンスが変更された12月13日以降に限って言うと、LXDが14コミットでIncusが183コミットになりますが、これは単にCanonicalの開発者が休暇に入っただけかもしれません。
コミッターの種類はどちらもCanonicalドメインのメンバーが中心です。Incusはそれに加えて、Stéphane GraberやThomas Hippなどの、元Canonicalなコントリビューターが含まれます。Incusが生き残るには、今後Canonical以外のコントリビューターをどこまで増やせるかにかかってくるでしょう。
Ubuntu以外のディストリビューションの場合
さて、本題である「IncusとLXDのどちらを使うべきか」に話を戻します。まず、Ubuntu（とそのフレーバー）以外のディストリビューションでは、ほぼ「Incusが唯一の選択肢」となる見込みです。
というのもLXDをインストールするにはsnapdをインストールする必要があるのですが、LXDのためだけにsnapdをインストールするのは手間に対して利点が低くなるためです。それに対してIncusでは、LXDにあったsnap由来のコードを破棄し、旧来のパッケージ管理システムでも使えるようにする方向で調整がかかっています。その結果として、Debian/UbuntuだけでなくGentooやNixOS向けのパッケージが整備されるようになりましたし、英語版の最新ドキュメントだとFedoraやArch Linuxのインストール方法も記述があります。Incusの由来を考えるとopenSUSE版パッケージもまもなく整備されることでしょう。
Incusにおいて削除された機能のほとんどは、Ubuntu由来のサーバー向けソフトウェアとの連携機能であるため、Ubuntu以外のディストリビューションについてはほぼ関係ないはずです。
利用する上で最大と言える差異は、Web UIの有無でしょう。これについては、LXDの場合はsnapパッケージにWeb UI（LXD-UI）を組み込むことで対応していましたが[3]、Incusの場合は別のパッケージとしてデプロイする必要がありそうです。一応Web UI用のエントリーは残してありますので、LXD-UIを別に立ててそこから接続すれば使えることになっていますし、実際にその方法を使ってIncusのデモページでもWeb UIが使えるものの、今後も問題なく動くかはなんとも言えないところです[4]。
UbuntuサーバーのLTS版を使っている場合
Ubuntuサーバーで、なおかつLTS版のみをインストールしている場合は、「Ubuntu 24.04 LTSの間はLXDを使う」のが無難かもしれません。
まず、サーバー版のUbuntuにはLXDが最初からインストールされていますし、古いUbuntuからアップグレードする場合も、特に気にすることなくそのまま使えるという大きな利点もあります。さらにLXDのLTS版も、Ubuntuと同じく長期サポートされます[5]。よって今からUbuntu 24.04 LTSに向けて、LXDをIncusに移行するための調査・検討時間がないという場合、Ubuntu 24.04 LTSについてはLXDを使い続けることが、最も安全でしょう。
また、サーバーオーケストレーションツールであるMAAS/JujuやCanonicalが提供するRBACとLXDを組み合わせて使いたい場合、さらにはsnapcraftを用いてLXD上でsnapパッケージをビルドしたいケースなどは、引き続きLXDを使ったほうが良いことになります。このあたりについては、「LXCで学ぶコンテナ入門」の第55回「コンテナと仮想マシンのマネージャ"Incus"」の「LXDからの変更点」を参考に判断することになりそうです。
逆にLXDで「Linux Containersのイメージサーバーを使っている」場合は、Incusに移行する必要があります。これは「lxc remote list」で表示される、「https://images.linuxcontainers.org」から提供されるイメージです。通常のLXDではインスタンスを作成する場合に、次のようにベースイメージを設定します。
$ lxc launch ubuntu:22.04 jammy
ここで言う「ubuntu:」がイメージサーバーを指定している部分です。「ubuntu:」はCanonicalが提供しているUbuntuのリリースビルドに対するイメージサーバーで、「images:」はUbuntuを含む様々なディストリビューションのイメージサーバーです。この「images:」のほうは、将来的にLXDからはアクセスできなくなります。Ubuntu 24.04 LTSがリリースされる頃までを目処に段階的に制限がかかる見込みです。もしimagesサーバーを使っている場合はIncusに移行することを検討してください。
Incus側ではLXDからの移行ツールである「lxd-to-incus」を提供しています。少なくともLXD 4.0から5.19からの移行はサポートしていますし、将来的なLXDのリリース（次のLTSであるLXD 6.0）からの移行もサポートされる可能性は高そうです。
ちなみにIncusもLTSリリースを4月前半頃に予定しています。おそらくUbuntu 24.04 LTSまでにはLTS版のIncus（Incus 6.0）が登場するのではないでしょうか。
UbuntuデスクトップやサーバーのLTS以外を使っている場合
Ubuntuデスクトップのユーザーや、あまりいないとは思いますが物理マシン上でUbuntuサーバーのLTS以外を使っている場合は、特に悩ましい判断になることでしょう。
すでにLXDをインストール済みである場合は、「UbuntuサーバーのLTS版を使っている場合」と同じ「Ubuntu 24.04 LTSの間はLXDを使う」判断が無難そうです。新規にLXDをインストールする場合は、「IncusかLXDかは用途や好みで判断する」なんてどっちつかずな結論になります。
前述したとおりMAASやsnapcraftを使うならLXDがおすすめです。何かコマンドスクリプト的なものを使っていて、その中でlxcコマンドを実行している場合も、当面はLXDを使い続けても良いでしょう[6]。また、LXDそのもののバージョンアップのタイミングを完全に自分でコントロールしたい場合、たとえばUbuntu 22.04 LTSにおいて、どこかのタイミングでLXD 5.0から6.0に切り替えたいと考えている場合は、切り戻しがしやすいsnap版を使い続けたほうが便利です。
それらがいずれも該当しない場合はIncusも選択肢になります。用途や将来性等に応じて判断してください。ちなみに2024年1月頭時点では、UbuntuにIncusをインストールするにはサードパーティのリポジトリを追加する必要があります。もしそれが弊害になる場合は、やはりLXDを使い続けることになるでしょう。
さらにIncusをDebianの公式リポジトリに入れようという動きは既に存在します。依存パッケージについても順調に対応が進み、つい先日の1月13日にはDebian sidの公式リポジトリに取り込まれました。そのうちDebianの次期リリースであるtrixieでもインストールできるようになるでしょう[7]。
Debian側の動きを受けて、Ubuntu 24.04 LTSでもIncusを公式リポジトリからインストールできるようになる見込みです。ただしLTS版のIncusが、Ubuntu 24.04 LTSにうまく取り込まれるかは現時点では不確実となります。LTS版のIncusが2月から3月にかけてリリースされて、それがDebian側にもスムーズに取り込まれたら、Ubuntu 24.04 LTSでもLTS版のIncusが取り込まれる可能性はあるでしょう[8]。
LXDのCanonicalへの移管やIncusの登場とLinux Containersでの採用は急転直下で行われた感じではあるため、この先LXD/Incusが歩み寄って元のさやに収まるという可能性もゼロではありません。しかしながら、外から見る限り、そんなかんたんには歩み寄れなさそうな雰囲気も感じています。おそらくユーザー側も、どちらを使うかの選択を迫られることになるでしょう。
