LXDからIncusへの本番コンテナ移行｜互換性検証とサービス継続の設計

LXDとIncus分岐の背景――なぜ今、移行が求められるか

2023年、Canonicalは長年OSS開発コミュニティが中心となって維持してきたLinux Containers（LXC）プロジェクトからLXDを引き上げ、自社管理のプロジェクトへと移行させました。この決定を受け、元LXDリードメンテナーのStéphane Graberをはじめとする開発者コミュニティが「Incus」としてフォークを立ち上げ、OSS版のコンテナ・仮想マシン管理基盤として引き継ぎました。

現時点でCanonicalのLXDは商用サポート寄りの方向性を強め、LXD 6.x系ではProライセンスモデルが導入されています。一方、Incusは完全なOSSとして開発が続いており、2026年時点ではIncus 6.x系のLTS版が主要ディストリビューション（Ubuntu 24.04、Debian 12、Alpine Linuxなど）に収録・採用されています。

運用現場では「LXD 5.x系で安定稼働しているコンテナ環境を、ライセンスや長期サポートの観点からIncusへ移行させたい」というニーズが増えています。ただし、本番環境での移行はサービス停止時間の最小化と互換性の確認が前提です。本記事ではその設計と手順を一連の流れとして整理します。

移行前に確認すべき互換性と前提条件

Incusはアーキテクチャ上LXDと非常に近い設計を持っており、公式の移行ツール lxd-to-incus を使えば多くの設定・インスタンスをそのまま引き継げます。ただし、全環境が無条件に移行できるわけではなく、事前の互換性確認が不可欠です。

• LXDのバージョン：移行ツールが対応するのはLXD 5.0 LTS以降です。LXD 4.x系はIncus移行ツールの対象外となるため、まずLXD 5.0へのアップグレードが必要です。
• クラスタ構成：LXDクラスタを組んでいる場合、移行はノード単位ではなくクラスタ全体で一括実施する必要があります。部分的な移行はサポートされていません。
• ストレージバックエンド：ZFS・Btrfs・LVMいずれもIncusで引き継ぎ可能ですが、Cephを利用している場合は設定の差異を事前に確認してください。
• ネットワーク：LXDブリッジ（lxdbr0）はIncusブリッジ（incusbr0）として再作成されます。既存のファイアウォールルールやDNS設定がブリッジ名に依存している場合は更新が必要です。
• 外部連携：LXD REST APIを叩く外部スクリプトやCI/CDパイプラインがある場合、エンドポイントとソケットパスが変わるため、移行後の修正計画を立てておきます。

また、移行前にはスナップショットでインスタンスの状態を保存しておくことを強く推奨します。移行ツールは設定とデータを移動しますが、万一のトラブル時に元の状態へ復元できる手段を持っておくことが本番環境では必須です。

lxd-to-incusを使った段階的な移行手順

移行の中心となるのは公式ツール lxd-to-incus です。このツールはIncusパッケージに同梱されており、LXDのデーモンを停止してIncusへ設定・インスタンスを転送する一連の処理を行います。

まず、ホスト側にIncusをインストールします。Ubuntu 24.04の場合はaptリポジトリに含まれていますが、Ubuntu 22.04やDebian 11などの環境では、Zabblyが提供する公式サードパーティリポジトリを利用するのが現時点での標準的なアプローチです。

# Ubuntu 22.04 / Debian 11の場合（Zabblyリポジトリを追加）
curl -fsSL https://pkgs.zabbly.com/key.asc \
  | gpg --dearmor -o /etc/apt/keyrings/zabbly.gpg

echo "deb [signed-by=/etc/apt/keyrings/zabbly.gpg] \
  https://pkgs.zabbly.com/incus/stable $(lsb_release -sc) main" \
  | tee /etc/apt/sources.list.d/zabbly-incus-stable.list

apt update && apt install incus lxd-to-incus

インストール後、移行ツールを実行します。ツールは実行前にドライランを行い、想定される変更内容を表示します。本番での移行は必ずメンテナンスウィンドウ内で実施してください。

# 移行の事前チェック（実際の変更は加えない）
lxd-to-incus --dry-run

# 問題がなければ本移行を実行
lxd-to-incus

ツールは内部で以下の処理を順に行います。LXDデーモンの停止、ストレージプールとネットワーク設定の移行、プロファイルとインスタンス定義の転送、そしてIncusデーモンの起動です。処理時間はインスタンス数とストレージ容量に依存しますが、設定のみの移行であれば数分以内で完了するケースが大半です。

移行後のCLI操作は lxc コマンドから incus コマンドに変わります。コマンド体系はほぼ同一ですが、スクリプトや運用手順書に lxc を使っている箇所は順次更新が必要です。なお、lxc コマンド自体はLXCライブラリのCLIとして引き続き存在するため、混同しないよう注意してください。

移行後のサービス継続確認――検証チェックリスト

移行ツールが正常終了したとしても、サービス継続の観点から実際の動作を確認するプロセスが欠かせません。以下の観点でIncus移行後の環境を検証します。

まずインスタンスの起動状態を確認します。

# インスタンス一覧と状態確認
incus list

# 個別インスタンスの詳細確認
incus info <コンテナ名>

# コンソールでの動作確認
incus console <コンテナ名>

次に、ネットワーク疎通を確認します。ブリッジ名が lxdbr0 から incusbr0 に変わっているため、コンテナ内からの外部通信、ホストからコンテナへのアクセス、コンテナ間通信のいずれも実際のトラフィックで確認します。

アプリケーション層の検証も重要です。Webサーバー・データベース・キューなど各サービスの正常稼働をヘルスチェックAPIや接続テストで確認し、レスポンスタイムが移行前後で大きく変化していないかも見ておきます。ストレージI/Oのベンチマークを簡易的に実行しておくと、ストレージバックエンドの引き継ぎが正常であることの裏付けにもなります。

外部からの監視システム（Prometheus/Grafana、Zabbixなど）がLXDのメトリクスエンドポイントを参照している場合は、Incusのメトリクスエンドポイント（デフォルト：/1.0/metrics）への切り替えが必要です。Incusは同様のPrometheus互換メトリクスを提供しますが、一部ラベル名に差異があるため、ダッシュボードの定義も見直してください。

切り戻し設計と移行時の注意点

本番移行において切り戻し手順を事前に定義しておくことは運用の基本です。lxd-to-incus はLXDのデータを「移動」する設計であり、LXDとIncusの共存は想定されていません。そのため、切り戻しはIncus移行後の状態からLXDへ戻すという逆順の手順が必要になります。

現実的な切り戻し設計としては、移行前にLXDの全インスタンスをエクスポートしておく方法が有効です。lxc export でインスタンスをtarballに書き出し、移行後に問題が発生した場合はLXDを再インストールしてインポートするという手順です。ただし、エクスポート・インポートには時間がかかるため、サービス停止許容時間との兼ね合いを設計段階で明確にしておく必要があります。

移行作業中の注意点として、LXDとIncusは同一ホスト上での共存が困難です。移行作業中にLXDデーモンとIncusデーモンが両方起動した状態になると、ストレージプールへのアクセス競合が発生する可能性があります。移行ツールはこの点を考慮して設計されていますが、手動で操作を行う場合は必ず一方のデーモンを停止した状態を維持してください。

snap版LXD（Canonicalが提供するsnapパッケージ）を使用している環境では、移行ツールの実行前にsnap版LXDの設定パスを確認しておく必要があります。snap版とAPT版ではデータディレクトリの場所が異なるため、lxd-to-incus が正しいパスを参照しているかを事前に検証することが推奨されます。

2026年現行環境の差分と今後の展望

2026年時点でのIncusの状況を整理すると、Incus 6.x系がLTSとして提供されており、Ubuntu 24.04 LTS（Noble Numbat）の標準リポジトリに収録されています。Debian 12（Bookworm）でもバックポートリポジトリ経由での導入が一般化しており、主要なパブリッククラウド上のUbuntu 24.04インスタンスにもそのままインストールできる環境が整っています。

機能面での注目点として、Incus 6.x系ではOVNを使ったオーバーレイネットワーク機能の成熟度が上がっており、複数ホスト間でのコンテナネットワークを柔軟に設計できるようになっています。また、コンテナと仮想マシンの混在管理もLXD時代から引き継いだ強みとして安定しており、K8sのような重厚なオーケストレーションを必要としないワークロードで特に選ばれています。

エコシステムの観点では、Terraform provider（terraform-provider-incus）やAnsibleロールがIncusに対応したバージョンを揃えつつあり、既存のIaC資産をそのまま活かしながら移行できるケースも増えています。CanonicalのLXD 6.x系は引き続き開発が進んでいますが、商用サポートの色が強まっており、OSS中心の運用環境では選択肢として選ばれにくくなっているのが現状です。

今後の移行計画を立てる運用現場では、まずステージング環境で lxd-to-incus を試し、移行後の動作確認とスクリプト修正を済ませてから本番に適用するというプロセスが定石です。LXD 5.0 LTSのサポート期間終了を見据えながら、計画的に移行スケジュールを引いておくことが、サービス継続性を損なわない移行の鍵となります。