Revision as of 07:02, 23 July 2026

ITコスト診断	お問い合わせ	メルマガ登録	ブログ	パートナー
Cost Assessment	Questions?'	Weekly Letter	Monthly Blog	Our Partners

LXDからIncusへの移行：オープンソース・システムコンテナの新たな標準

長年、Linuxにおけるコンテナ化は2つの主要なパラダイムによって支配されてきました。一方には、単一プロセスのマイクロサービスを分離してパッケージ化するために設計された、DockerやPodmanなどのアプリケーション・コンテナ・エンジンが存在します。もう一方には、完全なハードウェア仮想化に伴うパフォーマンスのオーバーヘッドなしに、完全なLinux OSと全く同じように動作する軽量な仮想環境を提供するシステムコンテナ技術が存在しました。

このシステムコンテナ領域の中心にいたのがLXDです。しかし、プロジェクトの統治（ガバナンス）の大きな変化、ライセンスの変更、そして企業の戦略的決定により状況は一変し、オープンソースのシステムコンテナおよび軽量仮想マシンの新たな標準旗手として、フォークされたIncusが台頭しました。この進化の背景、エコシステムが分裂した理由、そして移行の実行方法を理解することは、システム管理者、DevOpsエンジニア、インフラストラクチャ・アーキテクトにとって極めて重要です。

LXDの背景

システムコンテナ管理の現状を理解するには、まずLXDを振り返る必要があります。元々、Canonicalの主な支援を受けながら「Linux Containers」プロジェクトの傘下で立ち上げられたLXDは、LXC (Linux Containers) の上に構築されたREST API駆動のデーモンでした。素のLXCがカーネルネームスペース、cgroups、ケイパビリティを操作するための低レベルなプリミティブを提供したのに対し、LXDはコンテナのライフサイクル、ストレージプール、ネットワーク、クラスターデプロイメントを管理するための、洗練されたユーザーフレンドリーなインターフェースをもたらしました。

LXDは、KVMやVMwareのような従来のハイパーバイザーと、Dockerのようなアプリケーションコンテナの間のニッチを埋めました。数秒で起動し、メモリ消費を最小限に抑えた分離されたカーネルコンテナ内で、systemdなどのinitシステム、SSHデーモン、パッケージマネージャー、cronジョブを備えた完全なLinuxディストリビューションを実行することを可能にしました。その後のバージョンでは、まったく同じ統一されたREST APIとCLIを通じてQEMUベースの完全な仮想マシン（VM）の管理まで拡張され、運用者に軽量なコンテナと重量級のVMの両方を管理する単一のツールを提供しました。

Incusの登場

Incusは、システムコンテナと仮想マシンを管理するために設計された、完全なオープンソースでコミュニティ主導のデーモンです。2023年半ばにLinux Containersプロジェクトの傘下で作成されたIncusは、LXDの直接のフォーク（派生）です。LXDを人気にした基盤となるアーキテクチャの強みを維持しつつ、プロジェクトをコミュニティ主導の開発、オープンなガバナンス、および伝統的なオープンソース・ソフトウェア・ライセンスへと引き戻しています。

このプロジェクトは、Aleksa Sarai氏と長年のLXDリードデベロッパーであるStéphane Graber氏、そして元プロジェクトの他のコア貢献者たちによって主導されました。Incusは、単一ノードのホームラボから多ノードのエンタープライズ本番クラスターまで、多様なデプロイメント環境でコンテナとVMを実行するための信頼性の高い柔軟なプラットフォームを提供することを目指しています。親しみやすい運用パラダイムを維持しつつ、Incusは技術的負債の排除、セキュリティデフォルトの改善、OCIコンテナイメージのネイティブサポートの導入、そしてOpenFGAやOpenID ConnectのようなIDプロバイダーとの統合拡大によって、LXDからの差別化を図っています。

分裂の決定的な要因

LXDとIncusの分裂は、ソフトウェアアーキテクチャに関する技術的な意見の相違によって引き起こされたものではなく、企業戦略とプロジェクト・ガバナンスの根本的な変化によって生じました。

Canonicalによる直接統治の開始 (2023年7月):
- CanonicalはLXDプロジェクトの直接制御を引き受けるという突然の決定を下しました。それまでLXDは、Canonicalが主な資金提供者でありコアメンテナーの大多数を雇用していたものの、Linux Containers傘下のコミュニティプロジェクトとして運営されていました。 CanonicalはLXDのコードベースをLinux Containersリポジトリから移動し、ディスカッションフォーラムを自社プラットフォームへ移転させ、貢献者に対してCanonical Contributor License Agreementへの署名を要求しました。この戦略的理由は、LXDを自社の商用製品ポートフォリオ（特にUbuntu Server、MicroCloud、エンタープライズサポート提供）へ統合し、製品ロードマップを合理化したいという願望に由来していました。
ライセンス変更とイメージサーバーの制限:
- 数か月後、CanonicalがLXD全体のコードベースを許容的な「Apache 2.0」ライセンスからコピーレフトの「AGPLv3 (Affero General Public License)」へ変更したことで、摩擦は激化しました。この変更は、AGPLの制限を採用したくないサードパーティのインテグレーター、クラウドプロバイダー、およびオープンソースプロジェクトにとって大きな障壁となりました。
- さらに、CanonicalはLXDクライアントに対する公開イメージサーバー（images.linuxcontainers.org）へのアクセスを制限し、Incus以外のユーザーをコミュニティ管理のディストリビューションイメージから事実上切り離しました。これを受けて、Stéphane Graber氏を筆頭とするコアメンテナーたちは永続的なフォークとしてIncusを作成し、元のApache 2.0ライセンスを維持してLinux Containersプロジェクト内での独立したガバナンスを保ちました。

Incusプロジェクトの未来

Incusの未来は、コミュニティ中心のイノベーションと中立的なオープンソース・ガバナンスによって定義されています。Canonicalの商用エコシステムやUbuntu中心のデプロイモデルに結び付けられている現在のLXDとは異なり、Incusはディストリビューションに依存しません（アグノスティック）。Debian、Fedora、Arch Linux、Alpine、そして独立したリポジトリ経由でのUbuntuなど、主要なLinuxディストリビューション全体でファーストクラスのパッケージングが提供されています。

現在、Incusは以下のロードマップの優先事項に向けて前進しています。

OCIコンテナイメージのサポート強化: システムコンテナと並行して直接実行できるようにし、アプリケーションコンテナのランタイムとシステムコンテナマネージャーの間の架け橋となります。
エンタープライズIAM機能の推進: OpenFGAを介したきめ細かなロールベースのアクセス制御（RBAC）を統合しています。
先進的なインフラ統合: 仮想マシンにおける共有ストレージパスやデバイスのライブホットプラグ機能の導入や、OVNやBGPといった高度なネットワークスタックとの統合を深めています。

Apache 2.0ライセンスの下で維持されているため、開発者やソフトウェアベンダーはライセンスの摩擦なしに、Incusの上に商用およびオープンソースのインフラストラクチャ・サービスを自由に構築できます。

なぜLXDからIncusへ移行すべきなのか

現在LXDを運用している管理者にとって、Canonicalのスタックに留まることは、長期的な運用リスクと制限の増大を意味します。

長期的な持続可能性とエコシステムへのアクセス: Canonicalが公式のLinux ContainersイメージリポジトリへのLXDクライアントのアクセスをブロックしたため、LXDユーザーはCanonicalのイメージインフラに依存するか、カスタムのイメージ配信パイプラインを構築しなければなりません。対照的に、Incusはコミュニティが構築したLinuxディストリビューションイメージの完全なライブラリへのネイティブアクセスを維持しています。

開発のモメンタム（推進力）: 元のコアメンテナーと主要なコミュニティ貢献者が注力先を完全にIncusへ移したため、新機能の開発、パフォーマンスの最適化、バグ修正は主にIncusのコードベース内で行われています。

Snapパッケージからの脱却: IncusはユーザーをCanonicalのSnapパッケージ・エコシステムに強制することを回避し、運用者がディストリビューションのリポジトリやカスタムビルドからネイティブにパッケージ化されたバイナリを実行できるようにします。これにより、システムの安定性、起動パフォーマンス、およびバックアップの柔軟性が向上します。

準備と前提条件

移行を実行する前に、データ損失をゼロにするための適切な準備が不可欠です。移行プロセスは、公式ツールである lxd-to-incus を使用した「インプレース変換」として設計されています。このツールは、既存のLXDのストレージ、ネットワーク、プロファイル、およびインスタンスを検査し、それらを直接Incusのリソースに変換します。

システム準備のチェックリスト:
- 稼働中のコンテナ、仮想マシン、ストレージプール（ZFS、Btrfs、LVMなど）、カスタムネットワークブリッジ、および構成プロファイルの詳細なインベントリを作成する。
- ホストOSが完全に更新されており、LXDデーモンが互換性のあるバージョンを実行していることを確認する。
- 自動移行スクリプトを開始する前に、すべての重要なコンテナデータのオフサイトバックアップまたはストレージレベルのスナップショットを必ず作成する。
- 移行を実行する前にホストシステムにIncusデーモンのパッケージをインストールする。

【重要】警告： Incusをインストールした際、初期セットアップコマンド（incus admin init）は決して実行しないでください。自動移行ユーティリティは、既存のLXD設定でデータベースを読み込むため、まっさらで初期化されていないIncusのインストール状態を要求します。

lxd-to-incus による移行手順

移行プロセスは、Incusチームが提供する lxd-to-incus ユーティリティのおかげで合理化されています。

移行パッケージのインストール:
- 通常、Incusツール群と共に配布される移行パッケージをホストシステムにインストールします。
ドライラン（事前検証）の実行:
- root権限で lxd-to-incus コマンドを実行します。ツールが起動すると、徹底的な事前検証チェックが行われます。稼働中のLXDデーモンとインストールされたIncusサービスの両方に接続し、APIバージョン、データベーススキーマ、ストレージドライバー、およびネットワーク構成を比較します。
- サポートされていないカスタムプロファイルキーやバージョンの不一致などの互換性の問題が検出された場合、ツールは破壊的な変更を行う前に停止し、解決すべき問題をフィードバックします。
移行の承認と自動処理:
- 検証が成功すると、スクリプトは続行の確認を求めます。承認すると、移行ツールはデータ破損を防ぐために、アクティブなすべてのLXDコンテナとVMを体系的に停止します。
- データベースレコードの移行、ストレージプールのマウントパスの更新、ネットワークブリッジ定義の転送、構成プロファイルの更新を実行します。
- データ構造が移動した後、旧LXDのディレクトリ構造から /var/lib/incus 配下の新しいIncusの場所へパスを書き換えます。
サービスの切り替えとクリーンアップ:
- 最後に、ツールはLXDデーモンサービスをシャットダウンし、Incusサービスを開始して、ホストシステムから古いLXDパッケージを自動的にアンインストールまたは完全削除（purge）することを提案します。

移行後の検証とIncusエコシステムへの適応

移行ツールが完了したら、移行された環境の動作ステータスを検証する必要があります。最も基本的な変更は、CLIコマンドの操作が legacy な lxc コマンドから incus CLIツールへ移行することです。

移行後の検証手順:
- インスタンス一覧の照会（incus list）、ストレージプールのステータス確認、およびネットワークインターフェースの検証を行う。
- 移行したインスタンスを起動し、内部のヘルスチェックを実行して、サービス、IPアドレスの割り当て、DNS解決、およびマウントされたストレージボリュームが正常に機能していることを確認する。
- ホストのユーザーアカウントに管理権限が必要な場合は、レガシーな lxd グループの代わりに、それらを incus-admin システムグループに追加してください。

自動化・CI/CDパイプラインの更新:
- 以前にLXDのREST APIエンドポイントやソケット位置を参照していた既存の自動化スクリプト、CI/CDパイプライン、Ansibleプレイブック、またはTerraformプロバイダーを更新することも重要です。Incusは独自の専用UNIXソケット（/var/lib/incus/unix.socket）でリッスンし、更新された環境変数を使用します。これらの自動化フックをIncusを指すように更新することで、インフラ管理パイプラインは、アクティブでコミュニティ主導であるシステムコンテナ化の未来へと完全に整合することになります。

LXDからIncusへのシフトは、Linuxコンテナ・エコシステムにおける重要な転換点です。Canonicalによる企業再編とライセンス変更から始まった出来事は、結果として活気があり、独立した、標準を確立するオープンソースプロジェクトの創設を促進しました。Incusは、オープンなガバナンスと許容的なライセンスの下で、柔軟で高性能なシステムコンテナと軽量仮想マシンというビジョンを守り続けています。成熟した移行パスとツールセットを利用してLXDからIncusへ移行することで、サーバーインフラは将来にわたって安全で、コミュニティにサポートされた状態を維持することができます。

@@ Line 19: / Line 19: @@
 | [https://mintarc.com/minthome/index.php?title=Daily_posts#Answers_to_Questions '''Q & A''']
 </div>
+= LXDからIncusへの移行：オープンソース・システムコンテナの新たな標準 =
+長年、Linuxにおけるコンテナ化は2つの主要なパラダイムによって支配されてきました。一方には、単一プロセスのマイクロサービスを分離してパッケージ化するために設計された、'''Docker'''や'''Podman'''などのアプリケーション・コンテナ・エンジンが存在します。もう一方には、完全なハードウェア仮想化に伴うパフォーマンスのオーバーヘッドなしに、完全なLinux OSと全く同じように動作する軽量な仮想環境を提供する'''システムコンテナ技術'''が存在しました。
+このシステムコンテナ領域の中心にいたのが'''LXD'''です。しかし、プロジェクトの統治（ガバナンス）の大きな変化、ライセンスの変更、そして企業の戦略的決定により状況は一変し、オープンソースのシステムコンテナおよび軽量仮想マシンの新たな標準旗手として、フォークされた'''Incus'''が台頭しました。この進化の背景、エコシステムが分裂した理由、そして移行の実行方法を理解することは、システム管理者、DevOpsエンジニア、インフラストラクチャ・アーキテクトにとって極めて重要です。
+----
+=== LXDの背景 ===
+システムコンテナ管理の現状を理解するには、まずLXDを振り返る必要があります。元々、Canonicalの主な支援を受けながら「Linux Containers」プロジェクトの傘下で立ち上げられたLXDは、'''LXC (Linux Containers)''' の上に構築されたREST API駆動のデーモンでした。素のLXCがカーネルネームスペース、cgroups、ケイパビリティを操作するための低レベルなプリミティブを提供したのに対し、LXDはコンテナのライフサイクル、ストレージプール、ネットワーク、クラスターデプロイメントを管理するための、洗練されたユーザーフレンドリーなインターフェースをもたらしました。
+LXDは、KVMやVMwareのような従来のハイパーバイザーと、Dockerのようなアプリケーションコンテナの間のニッチを埋めました。数秒で起動し、メモリ消費を最小限に抑えた分離されたカーネルコンテナ内で、systemdなどのinitシステム、SSHデーモン、パッケージマネージャー、cronジョブを備えた完全なLinuxディストリビューションを実行することを可能にしました。その後のバージョンでは、まったく同じ統一されたREST APIとCLIを通じてQEMUベースの完全な仮想マシン（VM）の管理まで拡張され、運用者に軽量なコンテナと重量級のVMの両方を管理する単一のツールを提供しました。
+----
+=== Incusの登場 ===
+'''Incus'''は、システムコンテナと仮想マシンを管理するために設計された、完全なオープンソースでコミュニティ主導のデーモンです。2023年半ばにLinux Containersプロジェクトの傘下で作成されたIncusは、LXDの直接のフォーク（派生）です。LXDを人気にした基盤となるアーキテクチャの強みを維持しつつ、プロジェクトをコミュニティ主導の開発、オープンなガバナンス、および伝統的なオープンソース・ソフトウェア・ライセンスへと引き戻しています。
+このプロジェクトは、Aleksa Sarai氏と長年のLXDリードデベロッパーであるStéphane Graber氏、そして元プロジェクトの他のコア貢献者たちによって主導されました。Incusは、単一ノードのホームラボから多ノードのエンタープライズ本番クラスターまで、多様なデプロイメント環境でコンテナとVMを実行するための信頼性の高い柔軟なプラットフォームを提供することを目指しています。親しみやすい運用パラダイムを維持しつつ、Incusは技術的負債の排除、セキュリティデフォルトの改善、OCIコンテナイメージのネイティブサポートの導入、そしてOpenFGAやOpenID ConnectのようなIDプロバイダーとの統合拡大によって、LXDからの差別化を図っています。
+----
+=== 分裂の決定的な要因 ===
+LXDとIncusの分裂は、ソフトウェアアーキテクチャに関する技術的な意見の相違によって引き起こされたものではなく、企業戦略とプロジェクト・ガバナンスの根本的な変化によって生じました。
+* '''Canonicalによる直接統治の開始 (2023年7月):'''
+** CanonicalはLXDプロジェクトの直接制御を引き受けるという突然の決定を下しました。それまでLXDは、Canonicalが主な資金提供者でありコアメンテナーの大多数を雇用していたものの、Linux Containers傘下のコミュニティプロジェクトとして運営されていました。 CanonicalはLXDのコードベースをLinux Containersリポジトリから移動し、ディスカッションフォーラムを自社プラットフォームへ移転させ、貢献者に対してCanonical Contributor License Agreementへの署名を要求しました。この戦略的理由は、LXDを自社の商用製品ポートフォリオ（特にUbuntu Server、MicroCloud、エンタープライズサポート提供）へ統合し、製品ロードマップを合理化したいという願望に由来していました。
+* '''ライセンス変更とイメージサーバーの制限:'''
+** 数か月後、CanonicalがLXD全体のコードベースを許容的な「Apache 2.0」ライセンスからコピーレフトの'''「AGPLv3 (Affero General Public License)」'''へ変更したことで、摩擦は激化しました。この変更は、AGPLの制限を採用したくないサードパーティのインテグレーター、クラウドプロバイダー、およびオープンソースプロジェクトにとって大きな障壁となりました。
+** さらに、CanonicalはLXDクライアントに対する公開イメージサーバー（<code>images.linuxcontainers.org</code>）へのアクセスを制限し、Incus以外のユーザーをコミュニティ管理のディストリビューションイメージから事実上切り離しました。これを受けて、Stéphane Graber氏を筆頭とするコアメンテナーたちは永続的なフォークとしてIncusを作成し、元のApache 2.0ライセンスを維持してLinux Containersプロジェクト内での独立したガバナンスを保ちました。
+----
+=== Incusプロジェクトの未来 ===
+Incusの未来は、コミュニティ中心のイノベーションと中立的なオープンソース・ガバナンスによって定義されています。Canonicalの商用エコシステムやUbuntu中心のデプロイモデルに結び付けられている現在のLXDとは異なり、'''Incusはディストリビューションに依存しません（アグノスティック）'''。Debian、Fedora、Arch Linux、Alpine、そして独立したリポジトリ経由でのUbuntuなど、主要なLinuxディストリビューション全体でファーストクラスのパッケージングが提供されています。
+現在、Incusは以下のロードマップの優先事項に向けて前進しています。
+# '''OCIコンテナイメージのサポート強化:''' システムコンテナと並行して直接実行できるようにし、アプリケーションコンテナのランタイムとシステムコンテナマネージャーの間の架け橋となります。
+# '''エンタープライズIAM機能の推進:''' OpenFGAを介したきめ細かなロールベースのアクセス制御（RBAC）を統合しています。
+# '''先進的なインフラ統合:''' 仮想マシンにおける共有ストレージパスやデバイスのライブホットプラグ機能の導入や、OVNやBGPといった高度なネットワークスタックとの統合を深めています。
+Apache 2.0ライセンスの下で維持されているため、開発者やソフトウェアベンダーはライセンスの摩擦なしに、Incusの上に商用およびオープンソースのインフラストラクチャ・サービスを自由に構築できます。
+----
+=== なぜLXDからIncusへ移行すべきなのか ===
+現在LXDを運用している管理者にとって、Canonicalのスタックに留まることは、長期的な運用リスクと制限の増大を意味します。
+; 長期的な持続可能性とエコシステムへのアクセス
+: Canonicalが公式のLinux ContainersイメージリポジトリへのLXDクライアントのアクセスをブロックしたため、LXDユーザーはCanonicalのイメージインフラに依存するか、カスタムのイメージ配信パイプラインを構築しなければなりません。対照的に、Incusはコミュニティが構築したLinuxディストリビューションイメージの完全なライブラリへのネイティブアクセスを維持しています。
+; 開発のモメンタム（推進力）
+: 元のコアメンテナーと主要なコミュニティ貢献者が注力先を完全にIncusへ移したため、新機能の開発、パフォーマンスの最適化、バグ修正は主にIncusのコードベース内で行われています。
+; Snapパッケージからの脱却
+: IncusはユーザーをCanonicalのSnapパッケージ・エコシステムに強制することを回避し、運用者がディストリビューションのリポジトリやカスタムビルドからネイティブにパッケージ化されたバイナリを実行できるようにします。これにより、システムの安定性、起動パフォーマンス、およびバックアップの柔軟性が向上します。
+----
+=== 準備と前提条件 ===
+移行を実行する前に、データ損失をゼロにするための適切な準備が不可欠です。移行プロセスは、公式ツールである '''<code>lxd-to-incus</code>''' を使用した「インプレース変換」として設計されています。このツールは、既存のLXDのストレージ、ネットワーク、プロファイル、およびインスタンスを検査し、それらを直接Incusのリソースに変換します。
+* '''システム準備のチェックリスト:'''
+** 稼働中のコンテナ、仮想マシン、ストレージプール（ZFS、Btrfs、LVMなど）、カスタムネットワークブリッジ、および構成プロファイルの詳細なインベントリを作成する。
+** ホストOSが完全に更新されており、LXDデーモンが互換性のあるバージョンを実行していることを確認する。
+** 自動移行スクリプトを開始する前に、すべての重要なコンテナデータの'''オフサイトバックアップまたはストレージレベルのスナップショット'''を必ず作成する。
+** 移行を実行する前にホストシステムにIncusデーモンのパッケージをインストールする。
+<blockquote>'''【重要】警告：''' Incusをインストールした際、初期セットアップコマンド（<code>incus admin init</code>）は'''決して実行しないでください'''。自動移行ユーティリティは、既存のLXD設定でデータベースを読み込むため、まっさらで初期化されていないIncusのインストール状態を要求します。</blockquote>
+----
+=== lxd-to-incus による移行手順 ===
+移行プロセスは、Incusチームが提供する <code>lxd-to-incus</code> ユーティリティのおかげで合理化されています。
+# '''移行パッケージのインストール:'''
+#* 通常、Incusツール群と共に配布される移行パッケージをホストシステムにインストールします。
+# '''ドライラン（事前検証）の実行:'''
+#* root権限で <code>lxd-to-incus</code> コマンドを実行します。ツールが起動すると、徹底的な事前検証チェックが行われます。稼働中のLXDデーモンとインストールされたIncusサービスの両方に接続し、APIバージョン、データベーススキーマ、ストレージドライバー、およびネットワーク構成を比較します。
+#* サポートされていないカスタムプロファイルキーやバージョンの不一致などの互換性の問題が検出された場合、ツールは破壊的な変更を行う前に停止し、解決すべき問題をフィードバックします。
+# '''移行の承認と自動処理:'''
+#* 検証が成功すると、スクリプトは続行の確認を求めます。承認すると、移行ツールはデータ破損を防ぐために、アクティブなすべてのLXDコンテナとVMを体系的に停止します。
+#* データベースレコードの移行、ストレージプールのマウントパスの更新、ネットワークブリッジ定義の転送、構成プロファイルの更新を実行します。
+#* データ構造が移動した後、旧LXDのディレクトリ構造から <code>/var/lib/incus</code> 配下の新しいIncusの場所へパスを書き換えます。
+# '''サービスの切り替えとクリーンアップ:'''
+#* 最後に、ツールはLXDデーモンサービスをシャットダウンし、Incusサービスを開始して、ホストシステムから古いLXDパッケージを自動的にアンインストールまたは完全削除（purge）することを提案します。
+----
+=== 移行後の検証とIncusエコシステムへの適応 ===
+移行ツールが完了したら、移行された環境の動作ステータスを検証する必要があります。最も基本的な変更は、CLIコマンドの操作が legacy な <code>lxc</code> コマンドから '''<code>incus</code>''' CLIツールへ移行することです。
+* '''移行後の検証手順:'''
+** インスタンス一覧の照会（<code>incus list</code>）、ストレージプールのステータス確認、およびネットワークインターフェースの検証を行う。
+** 移行したインスタンスを起動し、内部のヘルスチェックを実行して、サービス、IPアドレスの割り当て、DNS解決、およびマウントされたストレージボリュームが正常に機能していることを確認する。
+** ホストのユーザーアカウントに管理権限が必要な場合は、レガシーな <code>lxd</code> グループの代わりに、それらを '''<code>incus-admin</code>''' システムグループに追加してください。
+* '''自動化・CI/CDパイプラインの更新:'''
+** 以前にLXDのREST APIエンドポイントやソケット位置を参照していた既存の自動化スクリプト、CI/CDパイプライン、Ansibleプレイブック、またはTerraformプロバイダーを更新することも重要です。Incusは独自の専用UNIXソケット（<code>/var/lib/incus/unix.socket</code>）でリッスンし、更新された環境変数を使用します。これらの自動化フックをIncusを指すように更新することで、インフラ管理パイプラインは、アクティブでコミュニティ主導であるシステムコンテナ化の未来へと完全に整合することになります。
+----
+LXDからIncusへのシフトは、Linuxコンテナ・エコシステムにおける重要な転換点です。Canonicalによる企業再編とライセンス変更から始まった出来事は、結果として活気があり、独立した、標準を確立するオープンソースプロジェクトの創設を促進しました。Incusは、オープンなガバナンスと許容的なライセンスの下で、柔軟で高性能なシステムコンテナと軽量仮想マシンというビジョンを守り続けています。成熟した移行パスとツールセットを利用してLXDからIncusへ移行することで、サーバーインフラは将来にわたって安全で、コミュニティにサポートされた状態を維持することができます。

Daily Post July 23 2026JP: Difference between revisions