インフラ・DevOps
ProxmoxからNixOSとIncusへの移行
Migrating from Proxmox to NixOS and Incus (nijho.lt)
要約
この記事では、筆者が数年間使用してきたProxmoxクラスターを、宣言型設定管理システムであるNixOSと仮想化管理ツールIncusに移行した経験について語られています。ProxmoxのGUI中心の命令型システムが抱える「状態のずれ」やAIエージェントとの相性の悪さといった課題を挙げ、NixOSの宣言性と再現性の高さが、複雑な設定やトラブルシューティング、さらにはAIを活用したインフラ管理においていかに優れているかを強調しています。これにより、ホームラボの運用がより柔軟かつ堅牢になったと述べています。
全文翻訳
私は完全にNixに移行しました:ProxmoxからNixOS + Incusへ\nなぜクリック可能なハイパーバイザーを宣言的なテキストファイルに置き換えたのか\nバス・ニイホルト 最終更新日 2025年12月1日 9分で読めます ソフトウェア開発、DevOps、HomeLab\n\n私は完全にNixに移行しました:ProxmoxからNixOS + Incusへ\n私は公式にProxmoxクラスターを廃止しました。単一のNUCから始まり、マルチノードクラスターにまで拡大したProxmoxで何年もホームラボを運用してきましたが、すべてをIncusを実行するNixOSに移行しました。\n\n懐疑論者から信者へ\n私は常にNixの伝道者だったわけではありません。実際、最初は言語とその構文を嫌っていました。どのように機能するのか理解できず、すでにdotfilesを設定するための自分自身の特定の方法を持っていました。シンボリックリンクにはDotbotを、バイナリ管理にはdotbinsという自作ツールを使用していました。ほとんどのツールにNixが必要だとは感じていませんでした。Macでは長い間nix-darwinを使用していましたが、Homebrewパッケージとアプリケーション設定を指定するだけでした。\n私の真の転向は、以前のローカルLLMの記事で説明したように、ゲーミングPCを購入したときに起こりました。最初はPop!_OSをインストールしました。ゲームをしたかったし、Windowsを絶対に避けたかったからです。いくつかのゲームは動作しましたが、NVIDIAドライバーの問題に常に遭遇し、修正するためにランダムな命令型コマンドを実行する必要がありました。後でこれらのデバッグ手順を再現できないため、それは悪い解決策だと感じました。そして、NVIDIAドライバーを更新するという愚かなことをしました。命令型にドライバーバージョンとリポジトリを管理することが災害の元であることに気づかず、GRUBのブートループに陥りました。苛立ちを感じながらNixOSをインストールし、そのアトミックなアップデートの約束がこれを解決してくれることを期待しました。結果は素晴らしかったです。私は、そのシステムを新しいディスクに移行するまで、すべてがバイト単位で同等になるとは本当に信じていませんでした。ドライブをクローンしたのではなく、Nixの設定を新規インストールに適用しただけです。それは起動し、データをコピーすると、すべてが同一でした。その瞬間、私はNixの真価を理解しました。\n\n命令型システムの摩擦\nProxmoxは素晴らしいソフトウェアです。それは私にとって参入障壁を下げ、仮想化、LXCコンテナ、ZFSについて知っているほとんどすべてを教えてくれました。しかし根本的に、Proxmoxはボタンをクリックすることを中心に構築されています。それはGUIファーストのパラダイムです。TerraformやAnsibleで自動化することもできますが、それはツールと戦っているように感じることがよくあります。「状態のずれ(State drift)」は現実です。デバッグのためにUIで設定を変更し、それを忘れ、6ヶ月後には「インフラストラクチャ・アズ・コード」が現実と同期していません。システムを手動で管理する人間にとっては、これは煩わしいことです。しかし、AIエージェントを導入すると、これはオペレーターにとって災害となります。「YOLOモード」で実行されているエージェントは、問題を修正するために何百もの命令型コマンドを実行するかもしれません。それは成功するかもしれませんが、システムを未定義で再現不可能な状態にし、エージェントでさえ後で完全に理解したり再現したりすることはできません。\n\nこの摩擦はハードウェア管理にも現れます。私のHP EliteDeskでは、Intel I219-LMネットワークカードに、ハードウェアオフロードが有効になっているとハングするという既知のバグがあります。何年も前にProxmoxでこれを修正したことを漠然と覚えていましたが、詳細は忘れていました。NixOSを設定したとき、同じ問題に遭遇しました。ネットワークがランダムに切断されるのです。しかし今回は、修正はルートシェルの履歴に残された忘れられたコマンドではありません。私の設定ファイルに文書化されたsystemdサービスです。tso off gso offが必要な理由を正確に説明するコメントを追加し、フォーラムのスレッドを引用しました。もしこのマシンを再インストールしても、修正は自動的に適用されます。Proxmoxでは、この苦痛を再び発見しなければならなかったでしょう。\n\n別の例は私のIntel NUCです。私のホームラボはテレビの後ろにあるので、Home Theater PC(HTPC)としても使用できるかと考えました。Proxmoxでは、ビデオ出力を得るためにGPUをVMにパススルーする必要がありました。しかし、そうするとProxmoxホストはGPUへのアクセスを完全に失い、問題が発生した場合にローカルコンソールが利用できなくなります。それは厳密なトレードオフでした:メディアプレーヤーか、デバッグ可能なハイパーバイザーか。試してみましたが、非常に手間がかかったため、すぐに元に戻しました。NixOSでは、選択する必要はありません。ホストOSはKodiを直接実行し、ネイティブハードウェアアクセラレーションとビデオ出力を提供します。同時に、incusはバックグラウンドで実行され、コンテナをホストします。私は仮想化のオーバーヘッドや「ヘッドレスホスト」の制限なしに、同じハードウェア上でHTPCとサーバーの両方を手に入れることができます。\n\nより深い哲学的違いもあります。ProxmoxやTrueNASのようなシステムはアプライアンスとして設計されています。ホスト上で任意のコマンドを実行することは想定されていません。パッケージのインストールや設定ファイルの調整は、ミドルウェアを破損させたり、アップグレード時に変更が失われたりする可能性があるため、推奨されません。事実上、自分のハードウェアの可能性を最大限に引き出すことができません。NixOSでは、ホストは完全に私のものです。Kodiをインストールしたり、ネットワークドライバーを調整したり、ローカルLLMを実行したりと、恐れることなくいじり回すことができます。状態は宣言的であるため、100%明確で再現可能です。ホストの設定を壊しても、数秒で動作する状態に回復できます。たとえそのマシンが重要なサービスを実行しているとしてもです。\n\nエージェント乗数\n私は以前、エージェント的コーディングへの移行について書きました。AIエージェントがタスクを実行する世界では、CLIファーストで宣言的なシステムが重要です。AIエージェントは、Webインターフェースで「ボタンをクリックして」VLANタグを設定したり、ディスクのサイズを変更したりすることは信頼できません。テキストが必要です。決定論が必要です。\n\nNixOSに移行することで、私のインフラストラクチャ全体がテキストファイルで定義されます。これは、私のAIエージェントが私のインフラストラクチャを読み、理解し、安全に変更することさえできることを意味します。Proxmoxの不透明なデータベースとUI駆動のワークフローは、私のエージェントにとってはブラックボックスでした。NixOSはオープンブックです。エージェントに「Faster Whisper APIサーバーをポート9000にデプロイし、LANに公開する」ようにさせたい場合、エージェントは「サービス」メニュー、次に「ネットワーク」メニュー、次に「ファイアウォール」メニューをナビゲートする必要はありません。単にsystemdサービス定義を書き込み、同じファイルにnetworking.firewall.allowedTCPPorts = [ 9000 ];を追加するだけです。エージェントは、git diffやアクティブな設定をチェックすることで、変更が成功したことを確認することもできます。これは、私が生きている「エージェント的コーディング」革命のインフラストラクチャ版です。\n\nNixOSを長年使用している友人が最近、私の設定がいかにうまく構造化されているか、特に8台の異なるマシンを管理していることについて褒めてくれました。面白いことに、私は自分の設定をほとんど一行も自分で書いていません。すべてを多くのセッションにわたってエージェント的AIを使って行いました。私は何度か再構築し、リファクタリングも行いました。1台のマシンから2台、そして最終的には9台のマシンにまで増やしました。AIがリファクタリングの重労働を処理し、私のPC、NUC、HPがすべて共通のモジュールを共有しつつ、それぞれのユニークな個性を保つようにしています。\n\nアーキテクチャ:Incusとシミュレーション\n永続的でステートフルなLXCコンテナとVMを管理するための純粋な「Nix」な方法があればと今でも願っています。nixos-containersやmicrovm.nixのようなプロジェクトはありますが、堅牢なハイパーバイザーのような運用上の成熟度やライブマイグレーション機能がしばしば欠けています。Incus(LXDのコミュニティフォーク)はこのギャップを完璧に埋めます。ホストにはNixOSの「群れ(cattle)」管理を提供しつつ、私の古いUbuntuコンテナやHome Assistant VMのような「ペット(pet)」のレガシーワークロードを安定した管理可能な環境で実行できます。重要なことに、IncusはクリーンなCLIを介して完全に制御可能であり、私のエージェントワークフローにおいて完璧な市民です。\n\n時が経つにつれて、私はすでにほとんどのレガシーLXCコンテナ—DNSやメディアマネージャーのようなサービス—を、VM内で実行される宣言的なDocker Composeファイルに移行していました。しかし、まだ主要な手つかずのものが一つありました:Home Assistant OSです。それに代わる良いものがありませんでした。Proxmoxのような専用のアプライアンスOSが必要だと考えていました。NixOS上のIncusを使えば、Home Assistant用の完全なVMを実行することがいかに簡単であるか、気づいていませんでした。それは単なる別のQEMUプロセスですが、コンテナと同じくらい簡単に管理できます。\n\n私が行った素晴らしいことの一つは、物理マシンと全く同じ設定を複製するIncus VMを作成したことです。実際に切り替える前に