なぜsystemd-nspawnはシステム管理者の「秘密兵器」なのか？
FedoraをメインPCとして2年間使って気づいたのは、DockerやPodmanは時として「買い物にトラックで行く」ようなものだということです。これらは非常に強力ですが、bashスクリプトのテストや古いディストリビューションでのアプリ試行のためにクリーンなサンドボックスが必要なだけなら、少し過剰です。
そこで登場するのがsystemd-nspawnです。このツールはよく「ステロイドを打ったchroot」と冗談めかして呼ばれます。カーネルの名前空間（namespaces）を利用してファイルシステム、プロセスツリー、ネットワークを仮想化しますが、systemdに深く統合されています。nspawnコンテナはほぼ瞬時に起動し、通常は1秒以内に完全なシェルが手に入ります。
最大の違いは何でしょうか？バックグラウンドで動くデーモンもなく、複雑なストレージドライバーもありません。シンプルで直接的、 …
Fedoraでは、このツールはsystemd-containerパッケージに含まれています。ターミナルを開いて次のように入力してください。
sudo dnf install systemd-container -y次に、ルートファイルシステム（OSの骨格）が必要です。Docker Hubからイメージをプルする代わりに、dnfを使って最小限のFedoraを/var/lib/machinesディレクトリにインストールします。ここがmachinectlでコンテナを一元管理する場所になります。
# コンテナ（仮想マシン）用ディレクトリの作成
sudo mkdir -p /var/lib/machines/fedora-sandbox
# Fedora 39 Minimalのインストール（ディスク容量は約250-300MB）
sudo dnf --installroot=/var/lib/machines/fedora-sandbox --releasever=39 \
groupinstall "Minimal Install" -yこのプロセスで、最も基本的なパッケージがダウンロードされます。ディレクトリの中に、最小限にまとめられたFedora OSが構築されます。
コンテナの起動と設定
コンテナに直接入るには、コマンドを1つ実行するだけです。ただし、独自のinitプロセスを持つ本物の仮想マシンのように動作させるには、-b（boot）フラグを追加します。
Rootパスワードの設定
最初に起動する前に、ログインできるようにパスワードを設定しておきましょう。このステップを忘れると、ログイン画面で立ち往生することになります。
sudo systemd-nspawn -D /var/lib/machines/fedora-sandbox passwdシステムの起動
では、そのスピードを体験してみましょう。
sudo systemd-nspawn -bD /var/lib/machines/fedora-sandbox起動画面がすぐに表示されます。終了するには、Ctrl + ]を3回連続で押します。これはsystemd特有の「脱出」キーコンビネーションです。
ネットワークの簡単な設定
デフォルトでは、コンテナはホストマシンと同じネットワークを共有します。独自のIPを持ち、完全に分離したい場合は、-nフラグを使用します。
sudo systemd-nspawn -bD /var/lib/machines/fedora-sandbox -nこれにより、systemdは仮想ネットワークインターフェース（veth）のペアを自動的に作成します。これでコンテナはローカルネットワーク内の独立したエンティティのように見えます。
machinectlによるプロフェッショナルな管理
もしsystemd-nspawnがエンジンなら、machinectlはハンドルです。これを使えば、コンテナのリスト管理が非常に楽になります。
実行中のコンテナを確認する：
machinectl listコンテナ内で新しいシェルを開く（docker execに相当）：
machinectl shell fedora-sandbox私のお気に入りの機能の1つはリソース制限です。各コンテナは実質的にsystemdサービスであるため、複雑な設定ファイルなしで直接RAMを制限できます。
# コンテナが512MB以上のRAMを使用しないように制限する
sudo systemctl set-property [email protected] MemoryMax=512M実践的な経験：いつsystemd-nspawnを選ぶべきか？
私の試行錯誤の経験に基づくと、次のような場合にsystemd-nspawnを使うのがベストです。
- RPMパッケージのビルド: メインマシンの依存関係の競合を避けるためにクリーンな環境が必要なとき。
- 内部でSystemdを実行: Dockerは本来、コンテナ内でsystemdを動かすのを「嫌い」ますが、nspawnではこれが標準機能であり、回避策は不要です。
- システムラボ: 実際のマシンを壊す心配をせずに、
rm -rf /を実行してシステムがどのように崩壊するか試してみたいとき。
もちろん、プロジェクトをKubernetesで数百ノードにスケールさせる必要があるなら、やはりPodmanが第一選択肢です。しかし、軽量なアプリケーションの隔離と最高のパフォーマンスを求めるなら、Fedoraにおいてsystemd-nspawnに敵うものはありません。
ホストとコンテナ間でのブリッジネットワークの設定やフォルダのマウントで困っていることはありませんか？ぜひコメント欄で議論しましょう！
