VPSでIncusシステムコンテナを構築する方法

Incus のシステムコンテナとは

VPS 上の Incus システムコンテナは、ファイルシステムを接続した単一プロセスではありません。独自の init システムとユーザーアカウントを備えた、1 台のマシンに近い環境です。コンテナはブートし、PID 1 として init を実行し、systemctl に応答します。ホストのカーネルを共有するため、仮想マシンではありません。カーネルより上の部分は、1 台のマシンと同じように動作します。

Incus は LXD から派生したコミュニティ版で、Linux Containers プロジェクトの下で保守されています。クライアントコマンドは incus です。--vm を指定すると、QEMU を使用して実際の仮想マシンも実行できます。ただし、Incus を導入する主な理由はシステムコンテナであり、このガイドの以降の内容もシステムコンテナを対象にします。

Docker の比較が誤解を招く理由

Docker は 1 つのプロセスをパッケージ化します。Incus は 1 つのオペレーティングシステムをパッケージ化します。Incus のドキュメントでは、この違いが明確に説明されています。「Docker などが提供するアプリケーションコンテナは、単一のプロセスまたはアプリケーションをパッケージ化します。一方、システムコンテナは、ホストや仮想マシンで実行するものに似た完全なオペレーティングシステムをシミュレートします。」

この違いにより、日常的な運用方法が変わります。

• Docker イメージには init がないため、その中では systemctl が失敗します。Incus コンテナは init システムを実行するため、サービスやタイマーをサーバーと同じように利用できます。
• Docker コンテナは、Dockerfile から破棄して再構築することを前提とします。Incus コンテナは、保持してパッチを適用し、スナップショットを作成することを前提とします。
• Docker イメージはレジストリへ push するビルド成果物です。Incus インスタンスはストレージプール上のディスクにある状態であり、incus export で移動します。
• Docker はワークロードを分離します。Incus はマシンを分離するため、1 つのコンテナに複数のワークロードと複数のユーザーアカウントを格納できます。

Incus のシステムコンテナ内で Docker を実行できます。Docker のアプリケーションコンテナ内で Incus を実行することはありません。イメージのビルド手順を使い、1 コンテナあたり 1 プロセスにしたい場合は、まず VPS 上の Podman と Docker を比較してください。ワークロードごとに共有カーネルではなく個別のカーネルが必要な場合は、VPS 上の Firecracker microVM が反対の選択肢です。

Incus は VPS 内で動作しますか？

VPS の仮想化方式とカーネルに依存するため、インストール前に両方を確認してください。プロバイダーの宣伝ページだけで判断しないでください。サーバー上で次の4つのコマンドを実行します。

systemd-detect-virt
uname -r
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers

systemd-detect-virt が kvm または qemu を出力する場合、VPS は専用のカーネルを持つ仮想マシンです。この場合は簡単です。Incus は物理サーバー上と同じように動作します。lxc、lxc-libvirt または openvz が出力される場合、VPS 自体がプロバイダーのカーネルを共有するコンテナです。その中の Incus コンテナはネストされたコンテナになります。ネストが機能するのは、プロバイダーがそのコンテナで有効にしている場合だけです。設定は管理できないホスト側にあるため、コンテナ内から有効にはできません。

stat -fc %T /sys/fs/cgroup は cgroup2fs を出力する必要があります。それ以外の場合、そのサーバーは cgroup（control group）v1 または hybrid 構成です。現在の Incus はこの構成を対象としていません。

cat /sys/fs/cgroup/cgroup.controllers は、利用を委任された control-group コントローラーを一覧表示します。Incus のドキュメントでは、blkio、cpuset、devices、freezer、memory、pids が必須とされています。ネストされた VPS では、プロバイダーが引き渡すコントローラーを選択するため、この一覧は KVM の VPS より短いことがよくあります。このファイルにないコントローラーは Incus が使用できません。そのコントローラーに依存するインスタンス制限も利用できません。

カーネルのバージョンは、以前より重要です。2026年8月時点で、Incus のドキュメントには upstream が保守する2つのブランチについて、異なる最低バージョンが記載されています。6.0 LTS（long term support）ブランチでは、「サポートされる最低カーネルバージョンは 5.4」とされています。現在の stable ブランチでは、「サポートされる最低カーネルバージョンは 6.12」とされています。Ubuntu 24.04 は独自のリポジトリで 6.0 LTS 系列のパッケージを提供し、6.8 カーネルと組み合わせます。これはサポートされる組み合わせです。同じ 6.8 カーネルに upstream リポジトリから現在の stable ビルドをインストールすると、記載された最低バージョンを下回ります。そのため、リポジトリを選ぶ前に uname -r を確認してください。

コンテナではなく完全な仮想マシンが目的の場合、制約は異なり、より厳しくなります。VPS が /dev/kvm を公開できるかどうかについては VPS でのネストされた仮想化 を、ハードウェアを所有している場合については レンタル VPS 上の Proxmox を参照してください。

Ubuntu または Debian に Incus をインストールする

Debian 13 と Ubuntu 24.04 以降には、独自のリポジトリに Incus が含まれています。

sudo apt update
sudo apt install -y incus

Debian では、incus-base により仮想マシン機能を含めずにコンテナのサポートをインストールします。Ubuntu で --vm インスタンスも使用する場合は、qemu-system を追加します。

ディストリビューションが提供するものより新しいリリースを使用する場合、アップストリームのパッケージは pkgs.zabbly.com にあります。次のコマンドは、プロジェクト独自のリポジトリ README に記載されているものです。

sudo apt update && sudo apt install -y curl
sudo mkdir -p /etc/apt/keyrings/
sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'
sudo apt-get update
sudo apt-get install -y incus

次に、ユーザーがデーモンのソケットへアクセスできるようにします。

sudo usermod -aG incus-admin "$USER"
newgrp incus-admin
incus info

incus info でサーバーの設定が表示されれば、ソケットは機能しています。権限エラーが表示される場合、グループ変更が現在のシェルに反映されていません。newgrp incus-admin は現在のシェルに反映し、新しいログインでは適切に反映されます。incus-admin のメンバーシップは、ホスト上の root と同等に扱ってください。このソケットへのアクセスにより、root として実行されるデーモンを完全に制御できるためです。ディストリビューションによっては、制限付きのユーザーアクセス用に通常の incus グループも作成されます。

次に、デーモンを初期化します。

sudo incus admin init

incus admin init --minimal を使わず、質問に回答してください。最小構成では dir ストレージドライバーが選択されます。次のセクションでは、この選択が長期的に影響する理由を説明します。

何かを起動し、動作を確認します。

incus launch images:debian/13 web
incus list
incus exec web -- bash

incus list には、web が RUNNING として incusbr0 サブネット上の IPv4 アドレスとともに表示されるはずです。アドレスがない場合、DHCP（動的ホスト構成プロトコル）が完了していません。これについてはネットワークのセクションで説明します。コンテナの起動に失敗した場合、その理由は incus info web --show-log に出力され、デーモンレベルの障害は sudo journalctl -u incus -n 50 に記録されます。VPS で systemd-detect-virt が lxc または openvz を返した場合、この起動によって nesting を利用できるかどうかを正しく確認できます。

デフォルトのストレージバックエンドが重要な理由

ストレージバックエンドによって、スナップショットが即座に作成されるか、コンテナのディスク全体をコピーするかが決まります。インストール時に選択する項目のうち、後から低コストで変更できない唯一の選択肢です。

Incus は dir、btrfs、lvm、zfs、Ceph、および複数のリモートドライバーをサポートしています。単一ディスクの VPS では、実質的な選択肢は dir と btrfs です。

dir ドライバーは、各コンテナを /var/lib/incus 配下の通常のファイルとディレクトリとして保持します。Incus のドキュメントでは、他のすべてのドライバーより「はるかに低速」と説明されています。すべてのイメージを展開し、共有ブロックを参照するのではなく実際にコピーする必要があるためです。4 GiB のコンテナのスナップショットを作成すると 4 GiB が書き込まれ、cp -a と同じ時間がかかります。ディスククォータが機能するのは、ファイルシステム側で project quota を有効にした ext4 または XFS だけです。ほとんどの VPS イメージでは、この設定がデフォルトで有効になっていないため、dir プールのディスク上限が効果を持たないことがよくあります。

btrfs と zfs は copy-on-write 方式なので、スナップショットには作成後に変更されたブロックだけが記録されます。Incus はこの 2 つを推奨バックエンドとしています。スナップショットはほぼ即座に作成されます。ディスククォータは、ファイルシステム自体のクォータ機能を通じて動作します。

ほとんどの VPS プランでは、予備のパーティションがない 1 台のディスクしか提供されません。そのため、プールは loop ファイル上に配置します。source= を指定しなければ、Incus がこれを自動的に行います。

sudo apt install -y btrfs-progs
incus storage create fast btrfs size=30GiB
incus profile device set default root pool=fast
incus launch images:debian/13 web2 -s fast

size= を指定しない場合、loop バックのプールには空きディスク容量の 20% が割り当てられます。下限は 5 GiB、上限は 30 GiB です。値は意図的に設定してください。loop ファイルは root filesystem 上のファイルです。そのため、プールとホストは同じ空き容量を共有します。プールが満杯になると、ホストのディスクも満杯になります。

Debian と Ubuntu の ZFS は、カーネルツリー内のモジュールではなく DKMS モジュールです。そのため、カーネルをアップグレードするたびに再ビルドされ、アップグレード後にビルドに失敗することがあります。毎日監視しないサーバーでは、btrfs のほうが 2 つの中で保守の負担が少なくなります。

3 つのネットワークモードと、それぞれで公開されるもの

incus admin init は incusbr0 という管理ブリッジを作成し、新しいインスタンスをすべてそこに接続します。これはコンテナを接続する3つの方法の1つです。残り2つが存在するのは、最初の方法ではコンテナが NAT (ネットワークアドレス変換) の背後に隠れるためです。

管理ブリッジ。 incusbr0 にはプライベートサブネットが割り当てられます。ホストはそのサブネットの最初のアドレスを保持してゲートウェイとして動作し、Incus はそこで DHCP と DNS (ドメインネームシステム) を提供します。外向きのトラフィックは、送信元 NAT を適用したうえでホストのパブリックアドレスから送信されます。明示的に許可しない限り、外部からコンテナには到達できません。ポートを公開するには、proxy デバイスで転送します。

incus config device add web http proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80 nat=true

nat=true は、別のユーザー空間接続を経由する proxy ではなく、netfilter ルールで転送します。そのため、クライアントの実際のアドレスがコンテナのログに残ります。Incus がこのモードをサポートするのは、ホストがインスタンスのゲートウェイである場合だけです。これはまさに incusbr0 の場合です。

macvlan。 コンテナには、ホストの物理ネットワーク上で独自の MAC (メディアアクセス制御) アドレスが割り当てられます。多くの VPS プラットフォームでは機能しません。仮想スイッチのポートが VM の MAC アドレスに紐付けられており、それ以外の MAC アドレスからのフレームを破棄するためです。動作する環境でも、もう1つ制限があります。Incus のドキュメントには、「macvlan デバイスは相互間および外部とは通信できますが、親デバイスとは通信できない。そのため、インスタンスからホスト自体への通信が必要な場合は macvlan を使用できない」と記載されています。

ルーティング。 追加アドレスを利用できる VPS では、通常このモードが機能します。Incus のドキュメントでは、このデバイスを「ホストとインスタンスを接続する仮想デバイスペアを作成し、静的ルートと proxy ARP/NDP エントリを設定して、インスタンスを指定した親インターフェースのネットワークに参加させるもの」と説明しています。ARP はアドレス解決プロトコルです。コンテナはパブリックアドレスを保持します。ホストがそのアドレスへの ARP に応答するため、プロバイダーから見える MAC アドレスはホストのものだけです。

incus config device add web eth0 nic nictype=routed parent=enp1s0 ipv4.address=203.0.113.20

親インターフェース名は ip route show default から取得します。現在のイメージでは、enp1s0 や ens3 のような名前が使われ、eth0 はほとんど使われません。デバイスを eth0 という名前で指定すると、default プロファイルが提供するデバイスが上書きされます。その結果、コンテナはブリッジではなくルーティング用インターフェースに接続されます。ip a と ip route を使って、コンテナ内から結果を確認します。

コンテナがホスト上のサービスに接続できた理由

incusbr0上のコンテナには、独自のネットワーク名前空間があります。ホストとの間にファイアウォール境界はありません。ホストはゲートウェイアドレスでそのブリッジ上に存在するため、コンテナ内から見るとホストは直接到達可能な隣接ノードです。そのため、0.0.0.0にバインドされたホスト上のすべてのサービスが、そこで接続に応答します。

実際に確認します。ホスト上で待ち受け中のサービスを一覧表示します。

sudo ss -tlnp

次に、コンテナ内から、ip routeが報告するゲートウェイを宛先にします。

ip route show default
nc -zv 10.0.0.1 6379

ホスト上のデータベース、メトリクスエンドポイント、管理パネルが0.0.0.0にバインドされていれば、この確認は成功します。パケットはマシンの外へ出ていないため、プロバイダーのネットワークファイアウォールには到達していません。「なぜそこに接続できたのか」という疑問の多くは、これが原因です。コンテナはNATによってインターネットから隔離されていますが、ホストとの間には隔離機構がありません。

可能な場合は、ホスト上のサービスを127.0.0.1にバインドします。そのうえで、ホスト上のブリッジをフィルタリングします。ufw を使用するホストでは、デフォルトの deny ポリシーによってコンテナからホストへのトラフィックがすでにブロックされます。これにより Incus の DNS と DHCP が機能しなくなるため、Incus のドキュメントではsudo ufw allow in on incusbr0を修正方法として示しています。この1つのコマンドにより、すべてのコンテナからすべてのホストポートへの接続が再び許可されます。代わりに、コンテナが実際に必要とする通信だけを許可します。

sudo ufw allow in on incusbr0 to any port 53 proto udp
sudo ufw allow in on incusbr0 to any port 53 proto tcp
sudo ufw allow in on incusbr0 to any port 67 proto udp
sudo ufw route allow in on incusbr0
sudo ufw route allow out on incusbr0

2つのufw routeルールによって、インスタンスのトラフィックがホストを経由してインターネットへ通過できるようになります。これらがないと、ufw の routed ポリシーによって転送パケットが破棄されます。そのため、コンテナはアドレスを取得しても、どこにも到達できません。

スナップショットとプロファイル

スナップショットは、ストレージプール内にあるインスタンスの特定時点のコピーです。

incus snapshot create web pre-upgrade
incus info web
incus snapshot restore web pre-upgrade
incus snapshot delete web pre-upgrade

incus info web は、インスタンスが保持しているスナップショットを一覧表示します。スナップショットはインスタンス単位でスケジュールします。

incus config set web snapshots.schedule=@daily
incus config set web snapshots.expiry=4w

スナップショットは、同じプール内の同じディスク上にある、同じサーバー内のデータです。アップグレードの失敗には備えられます。ディスク障害やインスタンスの削除には備えられません。バックアップは incus export であり、ファイルをサーバーの外部へ移す必要があります。

incus export web /root/web-backup.tar.gz
incus import /root/web-backup.tar.gz

プロファイルは、インスタンスに適用する設定キーとデバイスをまとめた名前付きの定義です。特に指定しない限り、すべてのインスタンスに default プロファイルが適用されます。このプロファイルによって、ルートディスクとネットワークインターフェースが提供されます。default を編集すると、それを使用するすべてのインスタンスに変更が反映されます。これは便利ですが、20 個のコンテナからネットワークを一度に切り離す操作にも使われます。

incus profile create small
incus profile set small limits.memory=512MiB
incus profile set small limits.cpu=1
incus launch images:debian/13 api -p default -p small

プロファイルは指定した順序で適用されるため、最後に指定したプロファイルのキー設定が優先されます。インスタンスに実際に適用された設定は incus config show api --expanded で確認します。

Incus コンテナ内で Docker を実行する

Incus のシステムコンテナ内で Docker を実行するには、ネストを有効にする必要があります。Docker は独自の namespace と mount を作成しますが、コンテナではデフォルトでこれらを作成できないためです。

incus config set web security.nesting=true
incus restart web

Incus では security.nesting を「インスタンス内でのネストを許可するかどうか」と説明しており、コンテナではデフォルト値が false です。Incus FAQ には、さらに2つの注意点があります。コンテナは kernel module をロードできないため、Docker が必要とする module はホストでロードし、incus config set web linux.kernel_modules overlay,br_netfilter に記載する必要があります。また、コンテナ内に /.dockerenv ファイルを作成すると、Docker はネスト環境で失敗する一部のチェックをスキップします。

Ubuntu 24.04 のホストでは、AppArmor の unprivileged user namespace 制限によって、runc が実行する pivot_root がブロックされることがあります。コンテナ内の Docker には、次のように表示されます。

failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error jailing process inside rootfs: pivot_root .: permission denied

ホストの dmesg には、apparmor="DENIED" operation="pivotroot" class="mount" を含む行が表示されます。この場合に設定変更を検討する対象は kernel.apparmor_restrict_unprivileged_userns です。ただし、これを無効にしても確実な解決策にはなりません。この拒否に関する Incus の upstream bug report には、0 に設定しても解決しなかったと記録されています。まず dmesg で拒否の内容を確認してください。AppArmor が実際の原因かどうかを確認してから、セキュリティのデフォルト設定を変更します。

VPS 上でコンテナを直接実行し、レイヤーを1つ省きたい場合は、VPS 上で Docker を実行するでその構成を説明しています。

障害の状態と表示される文字列

ホストに Docker をインストールすると、インスタンスのネットワークがすべて失われる。 Incus のドキュメントでは原因を次のように説明しています。「Docker はグローバルな FORWARD ポリシーを drop に設定するため、Incus がトラフィックを転送できず、インスタンスのネットワーク接続が失われます。」インスタンスにはアドレスが残りますが、どこにも到達できません。/etc/docker/daemon.json で ip-forward-no-drop を true に設定し、転送を永続化して、Docker 自身のチェーンを通してブリッジを許可します。

echo "net.ipv4.conf.all.forwarding=1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo systemctl restart systemd-sysctl
sudo iptables -I DOCKER-USER -i incusbr0 -j ACCEPT
sudo iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

これらの iptables ルールは、再起動だけでは保持されません。永続化してください。

コンテナが cgroup エラーで起動しなくなる。 Incus FAQ でも説明されている事象です。Failed to mount "/sys/fs/cgroup" に関するメッセージは、通常、ホスト上の VPN クライアントが net_cls cgroup v1 コントローラーを cgroup v2 にマウントしたことを示します。Incus は cgroup v2 を使用します。sudo umount /sys/fs/cgroup/net_cls で解消できます。

インスタンスに IPv4 アドレスが割り当てられない。 incus list では、アドレス列が空のまま実行中と表示されます。ホストからの DHCP 応答が破棄されています。多くの場合、ブリッジを認識していないホストファイアウォールが原因です。ufw では sudo ufw allow in on incusbr0 to any port 67 proto udp で復旧できます。sudo tcpdump -ni incusbr0 port 67 で要求が到着しているか監視します。

ネストされた VPS でインスタンスが起動しない。 まず incus info <name> --show-log を確認し、次に sudo journalctl -u incus -n 50 を確認します。systemd-detect-virt が lxc または openvz であれば、不足している設定はプロバイダー側にあります。VPS 内の設定では変更できません。

スナップショットが遅く、ディスク容量が減り続ける。 dir プールを使用しています。incus storage list で各プールのドライバーを表示できます。コピーオンライトプールへ移行するには、新しいプールを作成し、incus copy web web-new -s fast でインスタンスをコピーします。コピーが起動することを確認してから、元のインスタンスを削除します。

FAQ

Incus コンテナは Docker コンテナと同じものですか？

いいえ。Docker は単一のプロセスまたはアプリケーションをパッケージ化します。Incus のシステムコンテナは、独自の init、ユーザー、サービス、パッケージマネージャーを備えた完全なオペレーティングシステムをシミュレートします。Incus コンテナはサーバーと同じように維持し、パッチを適用します。Docker コンテナは破棄し、イメージから再構築します。コンテナで security.nesting=true を設定すれば、Incus コンテナ内で Docker を実行できます。逆は機能しません。

VPS で Incus を実行できますか？

KVM VPS なら実行できます。systemd-detect-virt が kvm または qemu を出力する場合は、独自のカーネルがあり、Incus は物理ハードウェア上と同じように動作します。lxc、lxc-libvirt、または openvz を出力する場合、VPS 自体がコンテナです。そのため、その中の Incus コンテナは入れ子になり、プロバイダーがコンテナでネスティングを有効にした場合に限り動作します。uname -r も確認してください。2026 年 8 月時点で、現在の Incus 安定版ブランチは 6.12 以上のカーネルを必要とし、6.0 LTS ブランチは 5.4 を文書化しています。

VPS 上の Incus では、どのストレージバックエンドを選ぶべきですか？

余分なブロックデバイスを割り当てられる場合を除き、ループファイル上の btrfs を使用します。dir ドライバーは、他のドライバーより大幅に遅いと文書化されています。コピーオンライトを使わず、ファイルをコピーするため、スナップショットを作成するたびにコンテナ全体を書き直すからです。incus admin init --minimal は dir を選択するため、対話形式の質問に 2 分かけて回答する価値があります。incus storage create fast btrfs size=30GiB でプールを作成します。

Incus コンテナからホスト上で実行中のサービスに接続できるのはなぜですか？

デフォルトの incusbr0 ブリッジでは、ホストがゲートウェイアドレスでコンテナと同じサブネット上に置かれ、両者の間でパケットがフィルタリングされないからです。0.0.0.0 にバインドされたホストサービスは、そのアドレスで応答します。パケットはマシンの外へ出ないため、プロバイダーのファイアウォールも認識しません。ホストサービスを 127.0.0.1 にバインドし、ufw を使用するホストでは、包括的な sudo ufw allow in on incusbr0 ではなく、incusbr0 で DNS と DHCP だけの受信を許可してください。

Incus コンテナをバックアップするにはどうすればよいですか？

incus export web /root/web-backup.tar.gz はインスタンスとそのスナップショットを 1 つのファイルに書き出し、incus import は同じサーバーまたは別のサーバーで復元します。incus snapshot create で作成したスナップショットはバックアップではありません。同じディスク上の同じストレージプールに保存されるため、アップグレードの失敗には耐えられますが、サーバーの故障には耐えられません。incus config set web snapshots.schedule=@daily でスケジュールし、エクスポートをサーバー外へコピーしてください。