Ryo (talk | contribs)
No edit summary
Ryo (talk | contribs)
No edit summary
 
Line 1: Line 1:
{{#seo:
|title=Incus vs Proxmox VE:単一CLIで実現するコンテナとVMの統合管理
|description=IncusとProxmox VEの違いを徹底比較。単一CLIによるコンテナと仮想マシンの統合管理、API設計、クラスタリング、ストレージ・ネットワーク抽象化まで詳しく解説。
|keywords=Incus, Proxmox VE, LXC, KVM, QEMU, コンテナ, 仮想マシン, CLI, API, 仮想化, クラスタ, dqlite, Corosync, ストレージ, ネットワーク, DevOps
|site_name=mintarc
|locale=ja_JP
|type=article
|canonical=https://mintarc.com/minthome/index.php?title=Incus_vs_Proxmox_Unified_Management_JP
}}
<div class="noexcerpt">
<div class="noexcerpt">
[[File:Logo_with_name.png|frameless|left|upright=.5|link=https://mintarc.com/minthome/index.php?title=Main_Page|alt=Mintarc]]
[[File:Logo_with_name.png|frameless|left|upright=.5|link=https://mintarc.com/minthome/index.php?title=Main_Page|alt=Mintarc]]

Latest revision as of 05:52, 27 July 2026


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

Email us |TEL: 050-1720-0641 | LinkedIn | English | 日々のブログ | Q & A

単一のCLIからのコンテナと仮想マシンの統合管理

軽量なシステムコンテナ技術は、ホストカーネルを共有することで、瞬時の起動時間と最小限のリソースオーバーヘッドを実現してきました。その一方で、従来のハイパーバイザーは、高いメモリ消費と遅い初期化速度と引き換えに、完全なカーネルの分離とクロスプラットフォームの柔軟性を提供してきました。これら双方の環境を同時に運用することは、通常、異なるツールチェーン、個別のネットワーク構成、そして独立したストレージメカニズムを維持・管理することを意味していました。

IncusProxmox VE (PVE) は、どちらも「システムコンテナ(LXC)と完全な仮想マシン(QEMU/KVM)を単一のプラットフォームから管理する」という共通のコア課題を解決しようとしています。しかし、その設計思想、システムアーキテクチャ、およびターゲットとするユースケースは大きく異なります。


Proxmox VE vs. Incus:設計思想とアーキテクチャの比較

オーケストレーションエンジン vs. ターンキーOS
Proxmox VE (ターンキーOS): DebianをベースとしたカスタムOSであり、ベアメタルサーバーを箱出し(アウトオブザボックス)の状態で即座にハイパーバイザーへと変貌させます。Debian、LXC、QEMU/KVM、Corosync、および独自のWebインターフェースが統合されたモノリシックなプラットフォームとして提供されます。
Incus (コンポーザブルなデーモン/CLI): 既存のほぼすべてのLinuxディストリビューション(Ubuntu、Debian、Fedora、Arch、Alpineなど)の上で動作するアプリケーション / サービスです。REST APIとCLIツール(incus)を備えた軽量デーモン(incusd)として機能し、ユーザーが好みのホストOSを用意し、その上でコンピュート・オーケストレーターとして動作します。
APIファーストCLI vs. Webファースト管理
Proxmox VE (Web中心): Web GUI(PVE Web UI)を中心として構築されています。コマンドラインユーティリティ(コンテナ用の pct、VM用の qm、クラスター用の pvecm)も存在しますが、これらは単一の統合クライアントではなく、特定のサブシステム用に構築された個別のツールです。
Incus (API / CLI中心): コンテナ、VM、ストレージ、およびネットワークの管理において、まったく同じ構文を使用する単一の統合CLI(incus)を提供します。Incusのすべての操作は単一のREST APIを介して行われるため、Webインターフェースなしでもリモート実行、自動化、CI/CDパイプラインとの統合が容易に実現します(サードパーティ製のGUIも存在します)。
LXCとVMの操作パラダイム
Proxmox VE: CLIにおいてコンテナとVMを明確に区別します。コンテナは pct create で作成され、VMは qm create で作成されます。設定ファイル、パラメータ形式、管理レイヤー内の機能セットも個別に分かれています。
Incus: 抽象化レイヤーにおいてコンテナとVMを同一のものとして扱います。Incusでは「インスタンスはインスタンス」です。コンテナは incus launch images:ubuntu/22.04 my-container で起動し、完全な仮想マシンは incus launch images:ubuntu/22.04 my-vm --vm というフラグを追加するだけで起動できます。プロファイルシステム、ストレージ構文、ネットワーク接続ロジック、ライフサイクルコマンド(起動、停止、スナップショット、マイグレーション)を完全に共有しています。
クラスタリングとデータベース構造
Proxmox VE: pmxcfs(Corosync経由で同期されるFUSEベースのクラスタファイルシステム)に依存します。小〜中規模クラスター(通常3〜32ノード)に最適化されており、クォーラムの問題を防ぐために低レイテンシな専用クラスタ通信ネットワークが必要です。
Incus: incusd デーモンに直接組み込まれた、Raft合意アルゴリズム駆動のネイティブな分散SQLiteデータベース(dqlite)を採用しています。クラスター内のどのノードでもAPI呼び出しを処理でき、Corosyncのような外部のクラスタファイルシステムレイヤーを必要とせずにスケールします。
  • 総括的な視点:
    • Proxmox VE: VMware vSphereやNutanixのオープンソース代替――インフラを視覚的に管理するためのWebダッシュボードを備えた、アプライアンス型のハイパーバイザー。
    • Incus: ベアメタルLinux上で直接動作する軽量なパブリッククラウドスタイル(AWS EC2やOpenStackのプリミティブに類似)のエンジン――高速なCLI操作、宣言型プロファイル、スクリプト実行、そして最小限のオーバーヘッドを好む開発者やシステム管理者に最適。

Incusのコアアーキテクチャ:デーモンと統一REST API

Incusのアーキテクチャの中核は、Go言語で書かれた単一のバックグラウンドサービス incusd です。このデーモンは、ホストシステム上のすべてのインスタンス、ストレージプール、ネットワークインターフェース、およびセキュリティポリシーのライフサイクル全体を管理する責任を負います。管理ロジックをCLIクライアントに直接結びつけるのではなく、クリーンでイベント駆動型のREST APIを通じてすべての機能を公開しています。

Incus CLIツール(incus)は、純粋にRESTクライアントとして機能します。ローカルのUnixドメインソケット経由で実行しても、暗号化されたTLS接続を介してリモートで実行しても、基礎となるAPIエンドポイントは同一です。この設計により、ユーザーエクスペリエンスがハイパーバイザーホストの物理的な場所から完全に切り離されます。開発者は手元のノートパソコンから、ローカルのコンテナ、リモートのベアメタルサーバー、さらには遠隔地のマルチノード・クラスターに対して、特別なミドルウェアやプラグインなしでまったく同じコマンドを実行できます。


コンテナと仮想マシンのランタイムエンジン

Incusはユーザーに対して均質な管理インターフェースを提供しながらも、要求される分離レベルに応じて、内部で2つの異なるランタイムエンジンをインテリジェントに使い分けます。

  • システムコンテナ (liblxc):
    • システムコンテナを起動する際、Incusは liblxc と直接連携し、ネームスペース、cgroups、seccompフィルタリングといったLinuxカーネルのネイティブ機能を活用します。システムコンテナは、ホストのカーネルを共有しながら、systemd initプロセス、システムログ、バックグラウンドサービスを含む完全なLinux OS環境をシミュレートします。
    • Incusはデフォルトのセキュリティを重視しており、ユーザーネームスペースのマッピングを使用して 特権なし(アンプリビレッジド)インスタンス としてコンテナを実行します。これにより、コンテナ内のrootがホストシステム上の非特権ユーザーIDにマッピングされ、コンテナからのブレイクアウト(脱出)リスクが劇的に低減します。
  • 完全な仮想マシン (QEMU / KVM):
    • 完全なハードウェア分離や非Linuxカーネルが必要な場合、IncusはバックエンドドライバーをQEMUおよびKVMハードウェア仮想化へと切り替えます。
    • 運用の一貫性を保つため、IncusはVMのゲストイメージ内に軽量なヘルパーユーティリティである incus-agent を組み込みます。このエージェントが親の incusd デーモンと通信することで、ファイル転送、ライブコンソールの接続、ゲストシステムのアトリメトリクス収集といった機能を実現します。IncusがQEMUのCLIフラグとドライバーのインスタンス化を内部で完全に処理するため、ユーザーはコンテナと同じコマンド構造に --vm フラグを付与するだけで、完全に分離された仮想マシンを起動できます。

ストレージとネットワークの抽象化レイヤー

Incusのアーキテクチャ上の大きな強みは、カスタムハードウェア構成を必要とせずに、ストレージバックエンドとネットワークトポロジーをコンテナと仮想マシンの双方で共有できる点にあります。

ストレージの抽象化
Incusのストレージドライバーレイヤーは、ZFS、Btrfs、LVM、通常のディレクトリ構造、および分散型のCephストレージなど、複数のエンタープライズバックエンドをサポートしています。ストレージプールはコンピュート・ワークロードとは独立して定義されます。インスタンスが起動すると、Incusはドライバーの機能(ZFSやBtrfsのコピー・オン・ライトによるデータセットクローニング、LVMのシンプロビジョニング論理ボリュームなど)を活用して、自動的にストレージボリュームをプロビジョニングします。この設計により、コンテナとVMの両方において、瞬時のスナップショット、高速なテンプレートクローニング、物理ストレージノード間のライブマイグレーションが容易になります。
ネットワークの抽象化
ネットワークも同様に抽象化されたモデルに従います。管理者は、ネイティブなLinuxブリッジ、Open Virtual Network(OVN)オーバーレイネットワーク、またはmacvlan構成を作成できます。Incusは、接続されたインスタンスのDHCP割り当て、DNS解決、ファイアウォールルールを自動的に管理します。さらに、NIC、物理GPU、USBデバイス、rawディスクパスなどのデバイスは、ターゲットのゲストが軽量なコンテナであってもQEMU仮想マシンであっても、統一されたAPI呼び出しを通じて稼働中のインスタンスに動的にアタッチまたはホットプラグすることが可能です。

プロファイルベースの構成管理

Incusのアーキテクチャには、「プロファイル」 を使用した宣言型の構成管理が組み込まれています。プロファイルは、リソース制限、アタッチされるデバイス、ストレージプール、環境変数、ネットワーク接続を定義する「再利用可能な構成テンプレート」として機能します。

複数のプロファイルをカスケード(重ね合わせ)して、起動時にインスタンスに適用したり、稼働中に動的に更新したりすることができます。例えば、デフォルトプロファイルで標準的なネットワークブリッジとプライバリストレージプールの接続を定義し、セカンダリプロファイルでメモリ制限、CPUピニング制約、カスタムファイアウォールルールを強制するといった運用が可能です。プロファイルはシステムコンテナと仮想マシンの両方に透過的に適用されるため、運用チームは異なる仮想化ツールのために個別のスクリプトを書くことなく、異種混在のワークロード全体でセキュリティの基準値とリソース割り当てを強制・管理できます。


分散クラスタリングと高可用性(HA)

Incusは、単一の開発者用マシンから、大規模なエンタープライズ・データセンター・クラスターまでシームレスにスケールします。CorosyncやPacemakerのような外部のエンタープライズ・クラスターマネージャーに依存する従来の仮想マシン管理者とは異なり、Incusはネイティブで組み込みの分散アーキテクチャを備えています。

Incusクラスターは、環境の単一の統合されたビューを共有するために接続された複数の物理ノードで構成されます。クラスターの状態は、Raft合意アルゴリズム駆動の組み込みリレーショナルデータベースエンジン(dqlite を使用して同期されます。この分散トランザクション・データベースにより、単一障害点なしにすべてのクラスターノード間で一貫性が保証されます。

クラスター管理において、どのノードもCLIリクエストを受信し、ターゲットホストへ透過的に操作をルーティングできます。ノードに障害が発生した場合、Incusは残りの健全なノード上で高可用性ワークロードを自動的に再配置・再起動し、最小限の運用オーバーヘッドでインフラストラクチャの回復力を提供します。