これまで仮想化環境としてVMやDockerコンテナを使った方法を紹介しましたが、その中間にあたるLXDコンテナを使う方法も便利です。まず各仕組みについてAIも利用してまとめてもらいました。
VMとLXDとDockerの違い
仮想化技術やコンテナ技術は、どれも「1つのハードウェア上で複数の環境を動かす」ためのものですが、その仕組みや「重さ」が大きく異なります。仮想マシン (VM)、LXD (システムコンテナ)、Docker (アプリケーションコンテナ) の違いは次のようになります。
1. 仮想化のレイヤーと構造
それぞれの技術がどのレベルで仮想化を行っているかを比較すると、違いが明確になります。
| 項目 | 仮想マシン (VM) | LXD (システムコンテナ) | Docker (アプリコンテナ) |
| 仮想化対象 | ハードウェア全体 | オペレーティングシステム | アプリケーションプロセス |
| ゲストOS | 必要(独自のカーネルを持つ) | 不要(ホストのカーネルを共有) | 不要(ホストのカーネルを共有) |
| 分離レベル | 非常に高い(完全分離) | 高い | 中程度 |
| 起動速度 | 分単位(遅い) | 秒単位(速い) | 秒以下(非常に速い) |
| リソース消費 | 多い | 少ない | 非常に少ない |
2. 各技術の特徴
仮想マシン (VM)
- 仕組み: ハイパーバイザー(VMware, VirtualBox, KVMなど)を使用して、CPUやメモリなどのハードウェアを仮想的に再現します。
- 特徴: 各VMが独自のOS(カーネル)を持つため、ホストがLinuxでもゲストにWindowsを動かすことが可能です。
- 用途: 異なるOSを動かしたい場合や、セキュリティ上の理由で完全に環境を隔離したい場合に向いています。
LXD (システムコンテナ)
- 仕組み: ホストOSのカーネルを共有しつつ、ユーザー空間を分離します。
- 特徴: 振る舞いは「軽量なVM」に近く、コンテナの中で
systemdやsshなどのサービスが動作し、通常のサーバーと同じように管理できます。 - 用途: 開発環境の丸ごとの構築、既存の物理・仮想サーバーのコンテナへの置き換え(リフト&シフト)に向いています。
Docker (アプリケーションコンテナ)
- 仕組み: LXDと同様にカーネルを共有しますが、特定の「アプリ(プロセス)」のみを動かすことに特化しています。
- 特徴: 「1コンテナ=1プロセス」が基本思想です。不変的なイメージ(Immutable Infrastructure)として配布しやすく、スケーリングが容易です。
- 用途: マイクロサービス、CI/CDパイプライン、クラウドネイティブなアプリ実行環境に向いています。
3. 使い分けのイメージ
どれを使うべきかは「何を動かしたいか」で決まります。
- 「OSを自由に選び、完全に独立したサーバーが欲しい」→ VM (VirtualBox, AWS EC2など)
- 「Linuxサーバーを数秒で立ち上げ、普通のサーバーとして設定をいじくり回したい」→ LXD
- 「特定のアプリ(Python, MySQL, Nginxなど)をどこでも同じように即座に動かしたい」→ Docker
LXCとLXDの違い
ちなみに、LXDと似たものとしてLXCがあります。非常に関係が深く、一言で言えば「エンジン(LXC)」と「それを使いやすくした管理システム(LXD)」という関係です。LXDはLXCを内部で利用していますが、ユーザー体験や機能面で大きな違いがあります。
1. 基本的な役割の違い
| 項目 | LXC (Linux Containers) | LXD (Linux Container Daemon) |
| 位置づけ | 低レイヤーのツール / ライブラリ | 高レイヤーの管理デーモン(REST API) |
| 操作感 | 個別のコンテナを手動で制御 | クラスターやネットワーク含め統合管理 |
| ユーザーインターフェース | 低レベルなコマンド群 (lxc-startなど) | 直感的なCLI (lxcコマンド) |
| 拡張性 | 単一ホスト内での利用が基本 | 複数ホストのクラスター化、ライブマイグレーション対応 |
2. LXC:コンテナの「基盤」
LXCは、Linuxカーネルの機能(NamespaceやCgroups)を使ってコンテナを作るための「道具箱」です。
- 職人気質: 設定ファイルを手書きで編集し、コンテナ一つひとつを細かく制御します。
- シンプル: 余計なデーモン(常駐プログラム)が動かないため、非常に軽量です。
- 現状: 現在では、個人が直接LXCのコマンドを叩く機会は減り、後述のLXDや他のツールの内部エンジンとして使われることが一般的です。
3. LXD:次世代の「コンテナ管理」
LXDは、LXCの複雑な部分をラップして、「仮想マシンのような使い勝手」をコンテナで実現したものです。
- REST APIベース: バックグラウンドで
lxdデーモンが動いており、ネットワーク経由で他のツール(AnsibleやOpenStackなど)と連携しやすいのが特徴です。 - イメージ管理: Dockerのように「Ubuntu 22.04」といったイメージをリモートから取得して、即座にコンテナを起動できます。
- スナップショットと復元: コンテナの状態を保存し、いつでも戻すことができます。
- 仮想マシンのサポート: 面白いことに、最近のLXDはコンテナだけでなく、KVMを利用した仮想マシン(VM)も同じコマンドで管理できるようになっています。
4. どっちを使えばよいのか?
現代のシステム構築においては、基本的には「LXD」を選ぶのが正解です。
- LXDを選ぶべき理由: コマンド体系が整理されており、スナップショットやネットワーク設定(ブリッジ、IP割り当てなど)が圧倒的に楽だからです。
- LXCを選ぶべき理由: 極限までリソースを削りたい組み込みデバイスや、自分ですべてをカスタマイズしたい上級者、あるいはLXDが動かない非常に古い環境などに限られます。
注意: 紛らわしいことに、LXDを操作するコマンド名自体が
lxcです。
lxc launch ubuntu:22.04 my-container→ LXDの操作lxc-create -n my-container -t download→ LXCの操作ハイフン(-)がつかない
lxcコマンドを使っているなら、それはLXDを使っていることになります。
DockerとPodmanの違い
今回の内容には関係がありませんが、Dockerと似た技術としてPodmanがあります。どちらもコンテナを操作するためのツールで、コマンドの使い勝手も非常によく似ていますが、その「設計思想」と「セキュリティ構造」に大きな違いがあります。一言でいうと、「中央集権的なDocker」と「分散型のPodman」という対比ができます。
1. 主な違いの比較
Docker と Podman の比較表
| 比較項目 | Docker | Podman |
| アーキテクチャ | デーモン依存 (dockerd が常駐) | デーモンレス (プロセスが直接起動) |
| 実行権限 | 基本的にルート権限が必要 | 一般ユーザー権限 (Rootless) が標準 |
| 管理単位 | 単体コンテナが基本 | Pod単位 (複数コンテナの集合) が可能 |
| オーケストレーション | Docker Compose が標準 | podman-compose や kube コマンドで対応 |
| セキュリティ | デーモンが攻撃対象になりうる | 権限分離により攻撃の影響範囲を限定しやすい |
| 主な利用シーン | 開発環境、Mac/Windowsでの利用 | RHEL系サーバー、高セキュリティ環境 |
2. 決定的な3つの違い
① デーモンレス (Daemonless)
- Docker: バックグラウンドで
dockerdという強力なプログラム(デーモン)が常に動いています。すべての操作はこのデーモンを経由します。もしデーモンがクラッシュすると、動いている全コンテナに影響が出る可能性があります。 - Podman: 常駐プログラムを必要としません。コマンドを打った瞬間にプロセスが直接コンテナを起動します。これにより、リソースの節約とシステムの安定性が向上します。
補足:なぜ Podman は「デーモンレス」なのか?
Dockerは、ユーザーがコマンドを打つと「常駐している親玉(デーモン)」に命令が飛び、そこからコンテナが作られます。一方、Podmanはコマンドを打った瞬間に、そのコマンド自体がコンテナのプロセスを直接立ち上げます。この違いにより、Podmanは「システムの一部としてコンテナを管理する(例:systemdで管理する)」といった操作が非常にスムーズに行えるのが強みです。
② Rootless(ルートレス)によるセキュリティ
- Docker: デーモンがルート権限で動くため、コンテナ内からホストOSへの攻撃(コンテナ脱出)のリスクが比較的高いとされてきました。
- Podman: 最初から「一般ユーザー権限」でコンテナを動かすことを前提に設計されています。万が一コンテナが乗っ取られても、ホストOSの重要な部分まで被害が及びにくい構造です。
③ Pod(ポッド)という概念
- Podman: 名前の由来(Pod Manager)の通り、Kubernetesでおなじみの「Pod」という単位を扱えます。複数のコンテナ(例:アプリとデータベース)を1つのグループとしてまとめ、同じIPアドレスを共有させることができます。
- Docker: 基本的に1つずつのコンテナを独立して扱います(Docker Composeでグループ化は可能ですが、ネットワーク層などは異なります)。
3. どちらを選ぶべきか
Dockerを選ぶべきケース
- 学習コストを下げたい: ネット上の情報やチュートリアルが圧倒的に多いです。
- Windows / macOSでの利用: Docker Desktopの完成度が高く、GUIでの管理も容易です。
- 開発標準に合わせたい: 多くのプロジェクトで標準採用されています。
Podmanを選ぶべきケース
- セキュリティを最優先したい: 本番環境や、ルート権限を渡したくない共有サーバーなどで有利です。
- Kubernetesへの移行を見据えている: コンテナの定義をYAML形式で書き出し、そのままKubernetesに持っていくのが得意です。
- RHEL(Red Hat Enterprise Linux)環境: 標準のコンテナエンジンとして採用されています。
豆知識:エイリアスの魔法
PodmanはDockerとコマンドの互換性が非常に高いため、以下の設定をするだけで、多くのユーザーが違和感なく移行できてしまいます。
alias docker=podman
これで、いつもの docker run や docker ps がそのままPodmanで動作します。
LXDコンテナをWebブラウザから簡単に扱う
長い説明になりましたが、LXDの位置付けを理解したところで、実際にLXDを扱う方法についてです。
LXDはLinuxコンテナおよび仮想マシンを管理するためのシステムですが、LXD UIを導入することで、コマンドラインを使わずにブラウザからコンテナの作成・管理ができるようになります。ここではUbuntu25.10に導入していきます。
Step 1: LXDのインストール
snapを使ってLXDの最新安定版をインストールします。
sudo snap install lxd --channel=latest/stable
インストールが完了すると以下のように表示されます。
lxd 6.7-1f11451 from Canonical✓ installed
Step 2: LXDの初期化と設定
LXDを初期化し、HTTPS APIを有効にします。
sudo lxd init --minimal
sudo lxc config set core.https_address :8443
sudo snap set lxd ui.enable=true
sudo systemctl reload snap.lxd.daemon
これによりポート8443でHTTPS APIが有効になり、LXD UIにアクセスできるようになります。
https://<サーバーのIPアドレス>:8443
Step 3: クライアント証明書の作成
アクセスすると警告が表示されますが、そのまま進めると次のような画面が表示されるので、右側の「TLS」を選択。

まずは「Generate certificate」をクリックして証明書をダウンロードします。

必要に応じてパスワードを設定。環境によってはパスワードが無いと取り込めない事があるようです。

Firefoxの場合、「設定」-「プライバシーとセキュリティ」項目で、「証明書を表示」を押します。

「あなたの証明書」で「インポート」を押して、先ほどダウンロードした証明書をインポートします。

トークンの生成
トークンを生成します。
サーバ側のターミナルに、表示されているコードをコピーして貼り付けます。次のようなコードです。
if ! lxc auth group show admins ; then lxc auth group create admins; fi && lxc auth group permission add admins server admin && lxc auth identity create tls/lxd-ui --group admins
すると、次のような文字列が表示されるので、それを貼り付けます。
Client trust token:
xxxxxx-xxxxxx-xxxxxx

Step 4: ブラウザへの証明書インポート(Firefox)
Firefoxに証明書をインポートしてLXD UIにログインします。
- Firefoxのアドレスバーに
about:preferences#privacyを入力 - ページ下部の「証明書を表示」をクリック
- 「あなたの証明書」タブで「インポート」をクリック
lxd-client.pfxを選択し、設定したパスワードを入力- Firefoxを再起動
Step 5: LXD UIへのアクセス
ブラウザをリスタートして以下のURLにアクセスすれば表示されるはずです。
https://<サーバーのIPアドレス>:8443

Step 6: Ubuntuコンテナの作成
LXD UIからコンテナを作成するには、まず「Create instance」をクリックして、インスタンス名(コンテナ名)を入力し、「Base Image」を選択します。

「Browse images」ボタンを押すと対応イメージが表示されます。ここでは「Ubuntu 25.10」を選択しています。

そのほかにもパススルーするUSBなどを指定したりも出来ますが、ひとまず起動するならこれでOK。右下の「Create and start」を押します。

ダウンロードが開始します。パーセントが進んでいくので少し待ちます。

Runningになれば完了。すでに起動しています。コンテナ名の部分をクリックします。

コンテナはパスワード不要で直接rootに入れます。「Terminal」でターミナルが表示されますが、rootでログインしている状態です。

以下のコマンドなどで状況を確認してみましょう。
# ファイルシステム全体を見る
ls /
# OSバージョン確認
cat /etc/os-release
# ネットワーク確認
ip a
今回作成したコンテナはデフォルトでは自動起動になっているので、サーバマシンを再起動しても自動で起動します。これは「Configuration」の「Boot」項目で設定出来ます。そのほかにもスナップショットを取ったり、コンテナをエクスポートしてダウンロード出来たりと便利に使えます。基本的な操作はVMと変わらないのですぐに分かるでしょう。
パスワードの設定やユーザーアカウントの設定など
もし、LXD UIのConsoleタブからログインする場合は、先にターミナルで入ってからパスワードを設定する必要があります。
# パスワードを設定
passwd root
一般ユーザーが必要な場合はログイン後に下記で作成できます。
usermod -aG sudo yourname
rootから一般ユーザーへ切り替える場合は下記で変更出来ます。ハイフンを忘れないように。
su - <ユーザー名>
もし今後、新しいコンテナを作る際に最初から一般ユーザーでログインさせたい場合は、プロファイル(Profile)で user.user-data を設定しておくのがスマートです。既存のプロファイル(例: default)を編集するか、新しいプロファイルを作成します。
lxc profile edit default
エディタが開くので、config: セクションの中に user.user-data を追加します。このプロファイルを使ってコンテナを起動すると、初回起動時(Cloud-init実行時)に自動的にユーザーが作成されます。
config:
# ここから追記
user.user-data: |
#cloud-config
users:
- name: user # 作成するユーザー名
groups: sudo # sudoグループに追加
shell: /bin/bash # デフォルトシェル
sudo: ALL=(ALL) NOPASSWD:ALL # 必要ならパスワードなしsudo
lock_passwd: false # パスワードを有効化
passwd: "your_password_hash" # ハッシュ化したパスワード
# ここまで追記
注意点:すでに存在するコンテナには効かない
user-data はコンテナの初回起動時(初期化時)にのみ実行されます。すでに作成済みのコンテナの設定を後から変える場合は、lxc exec の方法を使うか、直接コンテナ内の設定ファイルを書き換える必要があります。
