Linux Containers - Incus

2023/10/07

はじめに ¶

Linux Containers チームは、Incus の最初のリリースアナウンスができて、とてもうれしいです!

Incus は @cyphar による Canonical LXD のコミュニティーフォークで、今では Linux Containers プロジェクトの一部です。

この初期リリースは LXD 5.18 とほぼ同じです。しかし、明確な名前の変更に加えて、いくつか大きな変更があります。

オンラインでご自身で試せます: https://linuxcontainers.org/incus/try-it/

変更点 ¶

Incus の初期リリースでは、LXD から、多数の使っていない機能や、問題のある機能を削除する機会を得ました。これらの変更のほとんどは、LXD でやりたかったことですが、下位互換性の維持のためにできませんでした。

Incus は、将来的には同様に下位互換性を厳格にする予定です。しかし、この fork の最初のリリースですので、それを実行する絶好の機会でした。

とはいえ、API と CLI は依然として非常に LXD と近いので、LXD から Incus への移行は完全にシームレスではないにせよ簡単です。

API¶

`/1.0/containers` と `/1.0/virtual-machines` の削除 ¶

LXD はコンテナ向けのプロジェクトとして開始しました。そのため、REST API は /1.0/containers を使いました。

仮想マシンが使えるようになったとき、新たに /1.0/instances エンドポイントが、コンテナと仮想マシンの両方のすべての操作を引き継ぎました。しかし、/1.0/containers はレガシーなクライアントのために維持されました。さらに、利便性のために /1.0/virtual-machines エンドポイントも追加されましたが、使われることはありませんでした。

Incus では、これら2つのレガシーなエンドポイントが削除されました。そして、インスタンスとやりとりするための唯一の方法は、/1.0/instances を使うことです。

/dev/lxd の /dev/incus への変更 ¶

LXD から Incus への名称変更の一部として、ゲスト API も /dev/lxd から /dev/incus へ変更されました。

現在は、利便性のためシンボリックリンクが提供されています。ですので、既存のワークロードは LXD からマイグレーションしたあとも、動作しつづけるでしょう。

サーバー設定の型の変更 ¶

LXD サーバーの設定は、通常使われる map[string]string ではなく、map[string]any という、少し変わった型付けがされています。この不一致の理由は、初期の LXD が使っていたレガシーな認証方法で使われていた core.trust_password が原因でした。

これは、LXD がパスワードをクリアテキストで保存せず、代わりにハッシュ化して、ハッシュで保存するためです。これにより、完全な設定をユーザーに返すことができなくなりました。代わりに、パスワードが設定されると、文字列のかわりに true という真偽値が返されます。

前述のように、core.trust_password は認証を扱う古い方法であり、トークンベースの認証、TLS 証明書の信頼、外部の認証に置き換えるべきです。

Incus は core.trust_password のサポートを削除しました。そのため、すべてのサーバーの設定は、標準的な map[string]string に合致するようになりました。

Go API からのレガシーな `Container` 関数の削除 ¶

先に述べたように、/1.0/containers と /1.0/virtual-machines が削除されたため、それに続いて、Go クライアントパッケージ内の一致する関数も削除されました。

これらの Container 関数と同等の Instance を使う必要があります（例: CreateContainer の代わりに CreateInstance）。

CLI¶

`incus snapshot` サブコマンドの導入 ¶

LXD の CLI では、長い間スナップショットの管理に悩まされおり、一貫性がありませんでした。他のほとんどの操作には、専用のサブコマンド（file、config など）が用意されていますが、スナップショットは snapshot と restore というトップレベルが維持されてきました。

このため、lxc rename や lxc delete を使ってスナップショットのリネームや削除などの処理を行う必要がありました。代わりに、lxc snapshot サブコマンドで lxc snapshot create とするほうがはるかに合理的です。しかし、lxc snapshot を使用するすべてのスクリプトを壊すことなしに、そのようなことは行えませんでした。

今こそ、それを直すときです。incus snapshot はサブコマンドになりました。次のように使います:

incus snapshot create
incus snapshot delete
incus snapshot list
incus snapshot rename
incus snapshot restore

`incus config trust add` と `incus cluster add` の扱い¶

Incus では、パスワードベースの認証を廃止し、トークンに重点を置いているため、トークンの発行の使い勝手を簡単で一貫性のあるものにすることが重要でした。

その結果、incus config trust add と incus cluster add はどちらも、単に引数として名前を受け取り、トークンを返すようになりました。

incus config trust add の証明書を扱う機能は、代わりに incus config trust add-certificate に移されました。

`incus admin` サブコマンドの導入 ¶

LXD の世界におけるもう 1 つの長年の悩みは、サーバーをセットアップするために lxc と lxd の両方を使用する必要があるという事実でした。Incus では、incusd を直接使う必要はないため、安全に incusd を隠せます。

代わりに、incus admin サブコマンドがあります:

incus admin cluster
incus admin init
incus admin recover
incus admin shutdown
incus admin waitready

依存関係 ¶

Cowsql への移行 ¶

https://github.com/cowsql/cowsql

@cyphar が LXD を Incus にフォークした後、Dqlite のオリジナル作者である @freeekanayaka も、Dqlite を Cowsql としてフォークすることにしました。@freeekanayaka も Incus のメンテナーであることを考えると、Incus では Cowsql に移行することは理にかなっています。

Incus と同様に、Cowsql は Canonical Dqlite のコミュニティーフォークであり、Dqlite とほぼ互換性があります。Incus は、移行段階で既存データを簡単にインポートできます。

これまでのところ Cowsql は、劇的にパフォーマンステストを改善し、Raft 層と Cowsql 層全体に多くの変更を加え、Incus の使用パターンに合わせて、可能な限りパフォーマンスを向上させることに重点を置いています。

Go の最小バージョン ¶

ソースから Incus をビルドする際の、必要な Go の最小バージョンは 1.20 になりました。
一般論としては、我々は、最新とひとつ前の Go バージョンでのビルドをサポートし続けるように努めます。

機能の削除 ¶

多くの LXD が持っていた機能が Incus から削除されました。
これらは、主にエコシステムの理由で追加された機能や、現在は非推奨になっている機能、メンテナンスが不十分なソフトウェアに依存する機能に焦点を当てています。

Ubuntu Fan ブリッジの削除 ¶

Ubuntu ファンブリッジは、カスタムの Ubuntu 専用カーネルパッチと、iproute2 に対するユーザー空間の変更に依存しています。この機能は、Ubuntu カーネルではまだ維持されていますが、メインラインカーネルにも他のディストリビューションのカーネルにもありません。

Ubuntu Fan ブリッジは、一部の環境では便利ですが、Incus と OVN の統合によって可能になることに比べると小さく見えます。

このため、次のネットワーク設定キーは削除されました:

bridge.mode
fan.overlay_subnet
fan.underlay_subnet
fan.type

Ubuntu shiftfs の削除 ¶

Ubuntu カーネルに固有のもう 1 つの機能である shiftfs は、カーネルレベルでの柔軟な uid/gid シフトの最初の試みでした。

LXD は何年もの間、shiftfs をサポートしてきましたが、カーネルのさまざまな問題のため、デフォルトで有効になることはありませんでした。代わりに、この問題に対するよりクリーンなカーネル内ソリューションである、VFS idmap shifting が開発されました。これは最近の Linux カーネルで利用できるようになり、存在する場合は Incus によって自動的に使用されます。

Canonical Candid 認証の削除 ¶

以前 Canonical は、Macaroons の使用をベースとした独自の認証システムを開発しました。このための中央認証サーバーは Candid でした。

LXD は Candid をサポートし、それを通して、さまざまなプロバイダー経由でユーザーを認証できるようになりました。

最近では、Candid はほとんどメンテナンスされておらず、業界標準、つまり Open ID Connect に移行することに重点が置かれています。

そのため、次のサーバー設定キーは削除されました:

candid.api.key
candid.api.url
candid.domains
candid.expiry

Incus は、すでに外部認証用の OpenID Connect をサポートしており、Candid がサポートするものと同じくらい、またはそれを超える OIDC サーバーが広く利用可能です。

Removal of Canonical RBAC authorization¶

Canonical RBAC は、Macaroons と Candid 上に構築された、独自のロールベースのアクセス制御ソリューションでした。

これは、これまで MAAS と LXD によってのみサポートされており、プロプライエタリであり、一般的にアクセスするのが難しいことを主な理由として、採用されることはほとんどありませんでした。

ほとんどメンテナンスされておらず、最近は、より業界標準のもの、つまり OpenFGA への移行に焦点が当たっています。

このため、次のサーバー設定キーが削除されました:

rbac.agent.url
rbac.agent.username
rbac.agent.private_key
rbac.agent.public_key
rbac.api.expiry
rbac.api.key
rbac.api.url
rbac.expiry

Incus は、現時点では OpenFGA をサポートしていないため、Canonical RBAC の既存ユーザーは、OIDC + OpenFGA の代替手段が利用可能になるまで、LXD を使い続ける必要があります。

Canonical MAAS との統合の削除 ¶

LXD は、MAAS API との統合をサポートし、MAAS をある種の IPAM (IP アドレス管理) ソリューションとして使用します。

これにより、特定の LXD ネットワークを MAAS サブネットにマッピングし、MAAS にそのネットワーク上の各インスタンスのレコードを作成させ、静的アドレスと DNS レコードを割り当てることができます。

残念ながら、この統合はほとんど採用されておらず、MAAS 自体にはこの統合の際に問題となる多くの制約があります。

MAAS の MAC アドレスはグローバルに一意であるのに対し、LXD では同じネットワーク上の実行中のインスタンス間で一意である必要があります。この違いにより、一部のインスタンスのコピー操作が不可能になります。
インスタンス名は、完全に異なる DNS ゾーンに接続されている場合でも、MAAS ではグローバルに一意であることが期待されます。これにより、インスタンスが競合しやすくなるため、LXD プロジェクトを使用することが事実上不可能になります。

これらの問題とこの機能が採用されないことで、私たちは Incus から MAAS サポートを削除することを決定し、そのため次の構成キーが削除されました。

maas.api.key
maas.api.url
maas.subnet.ipv4
maas.subnet.ipv6

トラストパスワードの概念の削除 ¶

LXD の初期の頃、リモートサーバーに接続する唯一の方法は、トラストパスワードを使用することでした。これは基本的に、クライアントが TLS 証明書をサーバーの信頼ストアに追加できるようにする固定シークレットです。

このトラストパスワードにより、トラストパスワードを知っている、またはトラストパスワードを見つけることができる人は誰でも、クライアントをトラストストアに追加できるようになり、その後の操作ではトラストストアが不要になります。

したがって、トラストパスワードを厳重に保管するか、新しいクライアントを追加した直後に設定を解除する必要がありました。残念ながら、これが当てはまるケースはほとんどなく、信頼パスワードに対するブルートフォース攻撃の扉が開かれ、最終的には攻撃者が LXD とそれが実行されているサーバーを完全に制御できるようになります。

これに対処するために、ワンタイムトラストトークンの使用のサポートが少し前に追加され、ユーザーがトラストパスワードを使用しないようにすべてのドキュメントが更新されました。

Incus ではさらに一歩進んで、トラストパスワードのサポートを完全に削除しました。新しいクライアントまたは新しいサーバーをクラスターに追加するには、ワンタイムトークンを使用するか、OIDC を通した外部認証を使用して行う必要があります。

このため、次のサーバー設定キーを削除しました:

core.trust_password

その他 ¶

DMI 情報の変更 ¶

Incus の仮想マシン内では、ベンダー（vendor）は Linux Containers に、プロダクト（product）は Incus に設定されるようになりました。

virtio-serial マーカーの変更 ¶

vsock を通したフルエージェントアクセスを確立するまで Incus との限定的な通信に使用される virtio-serial デバイスは、org.linuxcontainers.incus になりました。

LXD からの移行 ¶

Incus には、便利な lxd-to-incus ツールが付属しています。このツールを使って、LXD から Incus へシステムの移行ができます。

現時点での制限は次の通りです:

LXD の最小バージョンは 4.0
LXD の最大バージョンは 5.18
現時点では、クラスターの移行はサポートされていません（現在取り組んでいます）

ドキュメント ¶

Incus のドキュメントはこちらです:
https://linuxcontainers.org/incus/docs/main/

（日本語訳: https://incus-ja.readthedocs.io/ja/latest/）

パッケージ ¶

Incus の開発元は通常のリリース tarball をリリースするだけですので、公式の Incus パッケージはありません。以下は Incus を起動して実行するために利用可能なオプションです。

Debian と Ubuntu 向け Zabbly パッケージ ¶

Zabbly がデイリーと安定版の両方の Incus のビルドを Debian と Ubuntu のユーザー向けに提供します:
https://github.com/zabbly/incus

Incus クライアントの Homebrew パッケージ ¶

Linux と macOS の両方向けのパッケージが Homebrew 経由で利用できます。

https://formulae.brew.sh/formula/incus

Incus クライアントの Chocolatey パッケージ ¶

Windows ユーザー向けのパッケージが Chocolatey 経由で間もなく利用できるようになる予定です。

それまでは、バイナリーがこちらから取得できます: https://github.com/lxc/incus/releases/tag/v0.1.0

サポート ¶

現在は初期段階ですので、Incus の各リリースは、次のリリースが出るまでしかサポートされません。LXC と LXCFS のリリースと合わせて LTS リリースを計画していますので、この状況はここ数ヶ月で変わるでしょう。

コミュニティサポートはこちらから: https://discuss.linuxcontainers.org
バグはこちらから報告できます: https://github.com/lxc/incus/issues

Contents

Incus 0.1 リリースのお知らせ

Incus 0.1 リリースのお知らせ¶