Docker以外のコンテナエンジン完全ガイド：初心者から実践まで

はじめに

「コンテナ = Docker」と思っている方も多いのではないでしょうか？実は、コンテナ技術の世界にはDocker以外にも様々な選択肢が存在します。本記事では、コンテナの基礎から始めて、Docker以外の主要なコンテナエンジンについて詳しく解説します。

この記事で学べること

• コンテナ技術の基本概念
• Docker以外の主要なコンテナエンジンの特徴
• 各エンジンの使い分け方
• 実際のインストール手順と使用例

1. コンテナ技術の基礎知識

1.1 コンテナとは？

コンテナは、アプリケーションとその依存関係をパッケージ化し、隔離された環境で実行する技術です。仮想マシン（VM）と比較すると以下のような特徴があります：

仮想マシン vs コンテナ

項目	仮想マシン	コンテナ
起動時間	数分	数秒
リソース消費	大きい（OS全体）	小さい（必要な部分のみ）
隔離レベル	完全に隔離	プロセスレベルで隔離
ポータビリティ	低い	高い

1.2 コンテナエンジンとは？

コンテナエンジンは、コンテナのライフサイクル（作成、実行、停止、削除）を管理するソフトウェアです。主な機能は：

• イメージ管理: コンテナの元となるイメージの作成・保存・配布
• コンテナ実行: イメージからコンテナを起動・管理
• ネットワーク管理: コンテナ間の通信設定
• ストレージ管理: データの永続化

1.3 コンテナの標準規格

コンテナ技術には以下の標準規格があります：

• OCI（Open Container Initiative）: コンテナの実行形式とイメージ形式の標準
  • OCI Runtime Spec: コンテナの実行方法の仕様
  • OCI Image Spec: コンテナイメージの形式仕様
• CRI（Container Runtime Interface）: Kubernetesとコンテナランタイム間のインターフェース

これらの標準があることで、異なるコンテナエンジン間での互換性が保たれています。

2. なぜDocker以外の選択肢が必要？

Dockerは素晴らしいツールですが、以下のような理由で代替手段が求められています：

2.1 ライセンスとコストの問題

• Docker Desktop（2021年9月以降）は大企業での商用利用が有料化
• 小規模チームには無料だが、組織の規模によっては年間費用が発生

2.2 アーキテクチャの課題

• Dockerはデーモンプロセス（dockerd）が必要
• デーモンがroot権限で動作するセキュリティリスク
• デーモンが停止すると全コンテナが影響を受ける

2.3 ユースケースの多様化

• Kubernetes環境では軽量なランタイムが好まれる
• CI/CD環境では特権なしで実行できる方が安全
• マイクロサービスアーキテクチャでは特定用途に特化したツールが有効

3. 主要なコンテナエンジン詳細解説

3.1 Podman（ポッドマン）

概要

PodmanはRed Hatが開発する、Dockerの代替として最も人気のあるコンテナエンジンです。

主な特徴

1. デーモンレスアーキテクチャ

• バックグラウンドデーモンが不要
• コンテナは通常のプロセスとして実行
• システムの安定性が向上

2. Rootless実行

• root権限なしでコンテナを実行可能
• セキュリティリスクを大幅に削減
• マルチユーザー環境で安全に利用

3. Dockerとの互換性

• dockerコマンドをpodmanに置き換えるだけで動作
• Dockerfileをそのまま利用可能
• Docker Hubなどのレジストリと互換

4. Podの概念

• Kubernetes互換のPod（複数コンテナのグループ）をサポート
• Kubernetesへの移行が容易

メリット

• セキュリティが高い
• Dockerからの移行が容易
• Red Hatの商用サポートあり
• systemdとの統合が優れている

デメリット

• Docker Composeの完全互換性はない（podman-composeで対応可能）
• Windowsネイティブサポートは限定的
• エコシステムがDockerほど成熟していない

適用シーン

• セキュリティを重視する環境
• 開発用マシンでのDockerの代替
• CI/CDパイプライン
• Linux環境での本番運用

インストールとクイックスタート

# macOS（Homebrewを使用）
brew install podman

# Podman Machine（macOS/Windows用）の初期化
podman machine init
podman machine start

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y podman

# RHEL/CentOS/Fedora
sudo dnf install -y podman

# バージョン確認
podman --version

# Nginxコンテナを実行
podman run -d -p 8080:80 --name web nginx

# コンテナ一覧表示
podman ps

# コンテナ停止と削除
podman stop web
podman rm web

Dockerコマンドとの対応

# Dockerコマンド → Podmanコマンド
docker run    → podman run
docker ps     → podman ps
docker build  → podman build
docker images → podman images

# エイリアスを設定すれば完全互換
alias docker=podman

---

3.2 containerd（コンテイナーディー）

概要

containerdは、もともとDockerのコアコンポーネントとして開発され、現在はCNCF（Cloud Native Computing Foundation）のプロジェクトです。

主な特徴

1. 軽量でシンプル

• コンテナ実行に必要な最小限の機能のみ
• 低レベルAPIを提供
• オーバーヘッドが少ない

2. Kubernetes標準ランタイム

• Kubernetesの推奨コンテナランタイム
• CRI（Container Runtime Interface）に完全準拠
• 多くのマネージドKubernetesサービスで採用

3. 業界標準

• Docker、Kubernetes、AWS ECS、Google Cloud Runなどで使用
• OCI準拠
• 安定性と信頼性が高い

メリット

• 非常に軽量でパフォーマンスが高い
• Kubernetesとの相性が抜群
• 安定した本番環境実績
• CNCFプロジェクトで中立的

デメリット

• CLIが基本的（高度な操作はnerdctlが必要）
• 初心者向けではない
• Dockerのような統合開発体験はない
• イメージビルド機能は別ツール（BuildKit）が必要

適用シーン

• Kubernetesクラスタのランタイム
• 本番環境での軽量ランタイム
• コンテナランタイムを組み込むプロダクト開発
• クラウドネイティブアーキテクチャ

インストールとクイックスタート

# Ubuntu/Debianでのインストール
# 依存関係のインストール
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release

# Dockerの公式GPGキーを追加
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# リポジトリ設定
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# containerdのインストール
sudo apt-get update
sudo apt-get install -y containerd.io

# containerdの起動
sudo systemctl enable --now containerd

# nerdctl（Docker互換CLI）のインストール
wget https://github.com/containerd/nerdctl/releases/latest/download/nerdctl-full-1.7.0-linux-amd64.tar.gz
sudo tar Cxzvf /usr/local nerdctl-full-1.7.0-linux-amd64.tar.gz

# コンテナ実行（nerdctlを使用）
sudo nerdctl run -d -p 8080:80 --name web nginx

# コンテナ一覧
sudo nerdctl ps

# イメージ一覧
sudo nerdctl images

containerdの設定

# デフォルト設定の生成
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# 設定の編集（systemd cgroupドライバーを使用する場合）
sudo nano /etc/containerd/config.toml
# [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
#   SystemdCgroup = true に変更

# containerdの再起動
sudo systemctl restart containerd

---

3.3 CRI-O（クライオー）

概要

CRI-OはKubernetes専用に設計された軽量コンテナランタイムです。Kubernetesとの統合に特化しています。

主な特徴

1. Kubernetes専用設計

• CRI（Container Runtime Interface）の実装に特化
• Kubernetesに不要な機能は一切なし
• Kubernetesのバージョンに完全追従

2. OCI準拠

• Open Container Initiative標準に完全準拠
• runc、crun、Kataなど複数のランタイムをサポート
• 柔軟なアーキテクチャ

3. セキュリティ重視

• 最小権限の原則
• SELinux、AppArmorとの統合
• Seccompプロファイルのサポート

メリット

• Kubernetes環境で最適化されたパフォーマンス
• セキュリティが強化されている
• Red Hat OpenShiftでデフォルト採用
• Kubernetesとのバージョン同期が保証

デメリット

• Kubernetes以外での使用は想定されていない
• スタンドアロンでの開発用途には不向き
• ドキュメントがKubernetes前提
• 学習リソースが限定的

適用シーン

• Kubernetesクラスタ（特にセキュリティ重視）
• Red Hat OpenShift環境
• エンタープライズKubernetes環境
• コンプライアンスが厳しい環境

インストール（Kubernetesノードでの例）

# Ubuntu 20.04でのインストール
# 前提条件
sudo apt-get update
sudo apt-get install -y software-properties-common curl

# CRI-Oリポジトリの追加（バージョン1.28用）
export OS=xUbuntu_20.04
export VERSION=1.28

echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list

curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add -
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -

# インストール
sudo apt-get update
sudo apt-get install -y cri-o cri-o-runc

# CRI-Oの起動
sudo systemctl enable --now crio

# ステータス確認
sudo systemctl status crio

# crictl（CRI-O CLI）の使用
sudo crictl version
sudo crictl images
sudo crictl ps

Kubernetesとの連携

# kubeadm設定例（/etc/kubernetes/kubeadm-config.yaml）
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
containerRuntimeEndpoint: unix:///var/run/crio/crio.sock

---

3.4 LXC/LXD（Linux Containers）

概要

LXCはLinuxコンテナの老舗で、LXDはその上位レイヤーです。仮想マシンとコンテナの中間的な「システムコンテナ」を提供します。

主な特徴

1. システムコンテナ

• 完全なLinuxシステムを実行
• initシステム（systemd）を含む
• 仮想マシンに近い使用感

2. 長時間実行に最適化

• ステートフルなワークロード向け
• 仮想マシン代替として利用可能
• マイグレーション機能

3. LXD独自機能

• RESTful API
• イメージサーバー
• クラスタリング機能
• スナップショットとバックアップ

メリット

• 仮想マシンより軽量で高速
• 完全なLinux環境が利用可能
• ネットワークとストレージの柔軟な管理
• Canonicalのサポートあり

デメリット

• アプリケーションコンテナ（Docker等）とは思想が異なる
• イメージエコシステムが小さい
• クラウドネイティブな用途には不向き
• 学習曲線がやや高い

適用シーン

• 開発・テスト環境
• 仮想マシンの軽量代替
• ステートフルなアプリケーション
• マルチテナント環境

インストールとクイックスタート

# Ubuntu/Debianでのインストール
sudo apt-get update
sudo apt-get install -y lxd

# 初期設定（対話式）
sudo lxd init
# デフォルト設定でEnterを押していくだけでOK

# ユーザーをlxdグループに追加
sudo usermod -aG lxd $USER
newgrp lxd

# 使用可能なイメージ一覧
lxc image list images: | grep ubuntu

# Ubuntu 22.04コンテナの作成と起動
lxc launch images:ubuntu/22.04 my-ubuntu

# コンテナ一覧
lxc list

# コンテナにシェルでログイン
lxc exec my-ubuntu -- /bin/bash

# コンテナの停止
lxc stop my-ubuntu

# コンテナの削除
lxc delete my-ubuntu

実践例：Webサーバーの構築

# Ubuntu 22.04でNginxサーバーを構築
lxc launch images:ubuntu/22.04 webserver

# コンテナに入る
lxc exec webserver -- bash

# コンテナ内でNginxインストール
apt update
apt install -y nginx
systemctl enable nginx
exit

# ポートフォワーディング設定
lxc config device add webserver myport80 proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80

# ブラウザでlocalhost:8080にアクセス

---

3.5 Buildah（ビルダー）

概要

Buildahはコンテナイメージのビルドに特化したツールです。Dockerfileを使わずにスクリプトでイメージを構築できます。

主な特徴

1. ビルド専用

• イメージビルドのみに集中
• 実行はPodmanなど他のツールで行う
• 単一責任の原則

2. Dockerfileレス

• Bashスクリプトでイメージ構築
• より細かい制御が可能
• Dockerfileも使用可能

3. レイヤー制御

• レイヤーの作成タイミングを制御
• 最適化されたイメージサイズ
• キャッシュ戦略の柔軟性

メリット

• イメージサイズの最適化が容易
• root権限不要でビルド可能
• スクリプトによる自動化が簡単
• 既存のシェルスクリプト資産を活用

デメリット

• 学習曲線がDockerfileより高い
• コンテナ実行は別ツールが必要
• コミュニティがDockerより小さい
• ドキュメントが限定的

適用シーン

• CI/CDパイプライン
• イメージサイズの最適化が重要な場面
• 複雑なビルドプロセス
• Dockerfileでは表現しにくいビルド

インストールとクイックスタート

# Ubuntu/Debianでのインストール
sudo apt-get update
sudo apt-get install -y buildah

# RHEL/CentOS/Fedora
sudo dnf install -y buildah

# バージョン確認
buildah --version

# 基本的な使い方：Dockerfileからビルド
cat << 'EOF' > Dockerfile
FROM alpine:latest
RUN apk add --no-cache nginx
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
EOF

buildah bud -t my-nginx .

# スクリプトでイメージビルド（Dockerfileレス）
#!/bin/bash

# ベースコンテナの作成
container=$(buildah from alpine:latest)

# パッケージのインストール
buildah run $container apk add --no-cache nginx

# 設定ファイルのコピー
buildah copy $container ./nginx.conf /etc/nginx/nginx.conf

# ポート公開
buildah config --port 80 $container

# 起動コマンド設定
buildah config --cmd "nginx -g 'daemon off;'" $container

# イメージとしてコミット
buildah commit $container my-nginx:custom

# クリーンアップ
buildah rm $container

# イメージ一覧
buildah images

# イメージをPodmanで実行
podman run -d -p 8080:80 my-nginx:custom

高度な例：マルチステージビルド

#!/bin/bash

# ビルドステージ
builder=$(buildah from golang:1.21-alpine)
buildah run $builder apk add --no-cache git
buildah copy $builder . /app
buildah config --workingdir /app $builder
buildah run $builder go build -o myapp .

# ビルド成果物を取得
buildah mount $builder
container_path=$(buildah mount $builder)
cp $container_path/app/myapp ./myapp
buildah umount $builder

# 実行ステージ
runtime=$(buildah from alpine:latest)
buildah run $runtime apk add --no-cache ca-certificates
buildah copy $runtime ./myapp /usr/local/bin/myapp
buildah config --entrypoint '["/usr/local/bin/myapp"]' $runtime
buildah commit $runtime myapp:latest

# クリーンアップ
buildah rm $builder $runtime
rm ./myapp

---

3.6 Kata Containers（カタコンテナーズ）

概要

Kata Containersは、コンテナをVMレベルで隔離するハイブリッド型ランタイムです。コンテナの利便性とVMのセキュリティを両立します。

主な特徴

1. ハードウェア仮想化による隔離

• 各コンテナが専用の軽量VMで実行
• カーネルレベルで完全に隔離
• 隣接攻撃（noisy neighbor）からの保護

2. コンテナAPIとの互換性

• OCIとCRIに完全準拠
• containerdやCRI-Oと統合可能
• 既存のコンテナイメージをそのまま利用

3. 軽量VM技術

• QEMUやCloud Hypervisorを使用
• 起動時間は数百ミリ秒（従来のVMより高速）
• メモリオーバーヘッドを最小化

メリット

• 極めて高いセキュリティレベル
• マルチテナント環境に最適
• コンプライアンス要件に対応
• Kubernetesとシームレスに統合

デメリット

• 通常のコンテナより重い（VM起動コスト）
• ハードウェア仮想化が必要（Intel VT-x/AMD-Vなど）
• 設定がやや複雑
• デバッグが難しい

適用シーン

• マルチテナントクラウド環境
• セキュリティが最重要の環境
• 信頼できないコードの実行
• 金融・医療などの規制業界

インストールとクイックスタート

# Ubuntu 22.04でのインストール
# Kata Containersリポジトリの追加
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/stable-3.0/xUbuntu_22.04/ /' > /etc/apt/sources.list.d/kata-containers.list"
curl -fsSL https://download.opensuse.org/repositories/home:katacontainers:releases:x86_64:stable-3.0/xUbuntu_22.04/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/kata-containers.gpg > /dev/null

# インストール
sudo apt-get update
sudo apt-get install -y kata-containers

# ハードウェア仮想化の確認
kata-runtime check

# containerdとの統合設定
sudo mkdir -p /etc/containerd/
cat <<EOF | sudo tee -a /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
  runtime_type = "io.containerd.kata.v2"
EOF

# containerd再起動
sudo systemctl restart containerd

# Kata Containersでコンテナを実行（nerdctl使用）
sudo nerdctl run --runtime io.containerd.kata.v2 -it alpine sh

Kubernetesでの使用

# RuntimeClassの定義
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata
---
# Podの例（Kata Containersを使用）
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  runtimeClassName: kata
  containers:
  - name: app
    image: nginx:latest
    ports:
    - containerPort: 80

---

3.7 gVisor（ジーバイザー）

概要

gVisorはGoogleが開発したユーザースペースカーネルで、アプリケーションとホストカーネルの間に追加のセキュリティレイヤーを提供します。

主な特徴

1. ユーザースペースカーネル

• Linuxシステムコールをインターセプト
• ホストカーネルへの直接アクセスを制限
• Goで書かれた独自のカーネル実装（Sentry）

2. OCI互換

• Docker、containerd、Kubernetesと統合可能
• 既存のコンテナイメージをそのまま利用
• runcの代替として機能

3. サンドボックス実行

• システムコールの攻撃面を大幅に削減
• ホストカーネルの脆弱性から保護
• コンテナエスケープのリスクを軽減

メリット

• 高いセキュリティレベル
• ハードウェア仮想化不要（Kata Containersより軽量）
• Google Cloud Runなどで実績あり
• アプリケーション互換性が高い

デメリット

• パフォーマンスオーバーヘッド（特にI/O処理）
• すべてのシステムコールがサポートされているわけではない
• デバッグが難しい
• メモリ使用量が増加

適用シーン

• サーバーレス環境（Google Cloud Run）
• マルチテナントSaaS
• 信頼できないコードの実行
• セキュリティ重視のコンテナ環境

インストールとクイックスタート

# gVisor (runsc) のインストール
ARCH=$(uname -m)
URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}

wget ${URL}/runsc ${URL}/runsc.sha512 \
  ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512

sha512sum -c runsc.sha512 \
  -c containerd-shim-runsc-v1.sha512

rm -f *.sha512

chmod a+rx runsc containerd-shim-runsc-v1
sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin

# containerdとの統合
cat <<EOF | sudo tee /etc/containerd/config.toml
version = 2
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"
EOF

sudo systemctl restart containerd

# gVisorでコンテナを実行
sudo nerdctl run --runtime runsc -it alpine sh

Dockerとの統合

# DockerでgVisorを使用
sudo dockerd --add-runtime=runsc=/usr/local/bin/runsc

# gVisorランタイムでコンテナを実行
docker run --runtime=runsc -it alpine sh

Kubernetesでの使用

# RuntimeClassの定義
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
# Podの例（gVisorを使用）
apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-app
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx:latest

---

3.8 Firecracker（ファイアークラッカー）

概要

FirecrackerはAWSが開発した超軽量のマイクロVM（microVM）技術です。AWS LambdaやFargateの基盤として使用されています。

主な特徴

1. マイクロVM

• KVMベースの極小仮想マシン
• 起動時間は125ミリ秒以下
• メモリオーバーヘッドは5MB未満

2. セキュリティ重視

• VMレベルの完全な隔離
• 最小限のデバイスモデル
• 攻撃面を極限まで削減

3. サーバーレス最適化

• 高密度実行（1ホストに数千のmicroVM）
• 高速なスナップショット機能
• REST APIによる管理

メリット

• 極めて高速な起動
• VMレベルのセキュリティ
• 軽量（メモリ/CPU効率）
• AWS実績（Lambda、Fargate）

デメリット

• Linuxホストでのみ動作（x86_64、aarch64）
• OCIコンテナとは直接互換性なし
• 設定が低レベルで複雑
• コミュニティがDockerより小さい

適用シーン

• サーバーレスプラットフォーム（FaaS）
• マルチテナント環境
• エッジコンピューティング
• 短時間実行のワークロード

インストールとクイックスタート

# Firecrackerのインストール（Ubuntu/Debian）
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
arch=`uname -m`
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${arch}.tgz \
  | tar -xz

sudo mv release-${latest}-$(uname -m)/firecracker-${latest}-${arch} /usr/local/bin/firecracker
sudo chmod +x /usr/local/bin/firecracker

# カーネルとrootfsのダウンロード
curl -fsSL -o hello-vmlinux.bin https://s3.amazonaws.com/spec.ccfc.min/img/quickstart_guide/x86_64/kernels/vmlinux.bin
curl -fsSL -o hello-rootfs.ext4 https://s3.amazonaws.com/spec.ccfc.min/img/quickstart_guide/x86_64/rootfs/bionic.rootfs.ext4

# microVMの設定
cat > config.json <<EOF
{
  "boot-source": {
    "kernel_image_path": "hello-vmlinux.bin",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  },
  "drives": [
    {
      "drive_id": "rootfs",
      "path_on_host": "hello-rootfs.ext4",
      "is_root_device": true,
      "is_read_only": false
    }
  ],
  "machine-config": {
    "vcpu_count": 1,
    "mem_size_mib": 128
  }
}
EOF

# Firecrackerの起動
sudo firecracker --api-sock /tmp/firecracker.socket --config-file config.json

高度な使用例：firecracker-containerd

# firecracker-containerdのインストール
# containerd + Firecrackerの統合ツール
wget https://github.com/firecracker-microvm/firecracker-containerd/releases/download/v1.7.0/firecracker-containerd-1.7.0-linux-amd64.tar.gz
sudo tar -xzf firecracker-containerd-1.7.0-linux-amd64.tar.gz -C /usr/local/bin

# 設定とサービス起動
sudo mkdir -p /etc/firecracker-containerd
sudo cp /usr/local/bin/config.toml /etc/firecracker-containerd/
sudo systemctl enable --now firecracker-containerd

# firecracker-ctr でコンテナを実行
sudo firecracker-ctr run --runtime aws.firecracker --rm --tty docker.io/library/alpine:latest demo /bin/sh

---

3.9 systemd-nspawn（システムディー・エヌスポーン）

概要

systemd-nspawnは、systemdに統合されたOS-levelコンテナ技術です。軽量なコンテナ環境を提供し、デバッグや開発環境の分離に適しています。

主な特徴

1. systemdネイティブ統合

• systemdに標準で含まれる（追加インストール不要）
• systemd-machindと連携
• journalctlで統一的なログ管理

2. OS-level仮想化

• chrootの拡張版として動作
• プロセス、ネットワーク、ファイルシステムを隔離
• 軽量で高速な起動

3. システムコンテナ向け

• 完全なLinuxシステムを実行可能
• initシステム（systemd）を含む
• 開発・テスト環境の分離に最適

メリット

• systemdがあれば追加インストール不要
• systemdツールとの統合が優れている
• 軽量でシンプル
• デバッグやテスト環境に最適

デメリット

• アプリケーションコンテナには不向き
• Dockerのようなイメージエコシステムがない
• クラウドネイティブな用途には不適
• ドキュメントが限定的

適用シーン

• 開発・デバッグ環境
• システムのテスト
• クリーンな環境での検証
• systemd関連の開発

インストールとクイックスタート

# systemd-containerパッケージのインストール（Ubuntu/Debian）
sudo apt-get install -y systemd-container debootstrap

# RHEL/CentOS/Fedora
sudo dnf install -y systemd-container

# Debianベースシステムの作成
sudo debootstrap --arch=amd64 stable ~/containers/debian-container http://deb.debian.org/debian/

# コンテナの起動
sudo systemd-nspawn -D ~/containers/debian-container

# または、systemd-machindを使用した永続的な起動
sudo machinectl start debian-container

# コンテナ一覧
machinectl list

# コンテナへのログイン
sudo machinectl login debian-container

# コンテナの停止
sudo machinectl stop debian-container

ネットワーク設定

# ホストネットワークを共有（デフォルト）
sudo systemd-nspawn -D ~/containers/debian-container

# プライベートネットワークを使用
sudo systemd-nspawn -D ~/containers/debian-container --network-veth

# ポートフォワーディング
sudo systemd-nspawn -D ~/containers/debian-container --network-veth --port=8080:80

systemdサービスとして管理

# サービスファイルの作成
sudo nano /etc/systemd/system/[e-mail]

[Unit]
Description=Container debian-container
After=network.target

[Service]
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --network-veth --machine=%i
KillMode=mixed
Type=notify
RestartForceExitStatus=133
SuccessExitStatus=133

[Install]
WantedBy=multi-user.target

# サービスの有効化
sudo systemctl enable [e-mail]
sudo systemctl start [e-mail]

---

3.10 Singularity/Apptainer（シンギュラリティ/アップテイナー）

概要

Singularity（現Apptainer）は、HPC（High Performance Computing）とサイエンティフィックコンピューティング向けに設計されたコンテナプラットフォームです。研究機関やスーパーコンピュータ環境で広く採用されています。

主な特徴

1. HPC特化設計

• MPIやGPU（CUDA、ROCm）との統合
• 並列計算環境に最適化
• スーパーコンピュータでの実績

2. セキュリティモデル

• rootless実行がデフォルト
• ユーザー権限で実行可能
• 共有HPC環境で安全

3. 再現性重視

• SIF（Singularity Image Format）形式
• イミュータブルな単一ファイルイメージ
• 科学的再現性を保証

4. Docker互換性

• DockerイメージからSIFイメージへの変換
• Docker Hubからのイメージ取得
• Dockerfileの再利用

メリット

• HPC環境で実績豊富
• rootless実行で安全
• GPU、MPI対応が優れている
• 科学計算ワークフローとの親和性が高い
• 単一ファイルイメージで配布が容易

デメリット

• 汎用コンテナ用途には過剰
• Kubernetes統合は限定的
• コミュニティがDockerより小さい
• Web開発などには不向き

適用シーン

• HPC（スーパーコンピュータ）環境
• 機械学習・AI研究
• バイオインフォマティクス
• 科学計算ワークフロー
• 研究の再現性確保

インストールとクイックスタート

Apptainerのインストール（Ubuntu/Debian）

# 依存関係のインストール
sudo apt-get update
sudo apt-get install -y wget

# Apptainerのダウンロードとインストール
cd /tmp
export VERSION=1.2.5
wget https://github.com/apptainer/apptainer/releases/download/v${VERSION}/apptainer_${VERSION}_amd64.deb
sudo apt-get install -y ./apptainer_${VERSION}_amd64.deb

# バージョン確認
apptainer version

RHEL/CentOS/Fedora

# EPELリポジトリの有効化（RHEL/CentOS）
sudo yum install -y epel-release

# Apptainerのインストール
sudo yum install -y apptainer

# Fedoraの場合
sudo dnf install -y apptainer

基本的な使い方

# Docker Hubからイメージをプル
apptainer pull docker://ubuntu:22.04

# SIFイメージの実行
apptainer run ubuntu_22.04.sif

# コンテナ内でコマンド実行
apptainer exec ubuntu_22.04.sif cat /etc/os-release

# インタラクティブシェル
apptainer shell ubuntu_22.04.sif

# ホームディレクトリは自動的にマウントされる
apptainer exec ubuntu_22.04.sif ls $HOME

Definition Fileによるイメージビルド

# Definition Fileの作成（Dockerfileに相当）
cat > my-container.def << 'EOF'
Bootstrap: docker
From: ubuntu:22.04

%post
    apt-get update && apt-get install -y \
        python3 \
        python3-pip \
        vim
    pip3 install numpy pandas matplotlib

%environment
    export LC_ALL=C

%runscript
    echo "Container was created $NOW"
    python3 --version

%labels
    Author [e-mail]
    Version v1.0
EOF

# イメージのビルド（sudoが必要）
sudo apptainer build my-container.sif my-container.def

# ビルドしたイメージの実行
./my-container.sif

GPU対応（CUDA）

# NVIDIAコンテナからGPU対応イメージをプル
apptainer pull docker://nvidia/cuda:11.8.0-base-ubuntu22.04

# GPU対応で実行
apptainer exec --nv cuda_11.8.0-base-ubuntu22.04.sif nvidia-smi

# TensorFlowの例
apptainer pull docker://tensorflow/tensorflow:latest-gpu
apptainer exec --nv tensorflow_latest-gpu.sif python3 -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"

MPI並列計算

# MPIアプリケーションの実行
mpirun -np 4 apptainer exec my-mpi-app.sif /app/parallel_program

# ホストのMPIライブラリを使用
apptainer exec --bind /usr/lib64/libmpi.so my-mpi-app.sif /app/program

Docker互換性

# DockerイメージをSingularityイメージに変換
apptainer build myapp.sif docker://myrepo/myapp:latest

# Docker Hubのプライベートリポジトリからプル
apptainer pull docker://registry.example.com/private/image:tag

# Dockerfileから直接ビルド（Definition File不要）
sudo apptainer build from-dockerfile.sif docker://ubuntu:22.04

---

4. コンテナエンジン比較表

4.1 機能比較

機能	Docker	Podman	containerd	CRI-O	LXC/LXD	Buildah	systemd-nspawn	Singularity/Apptainer
デーモンレス	❌	✅	❌	❌	❌	✅	✅	✅
Rootless実行	△	✅	△	△	❌	✅	△	✅
Docker互換CLI	✅	✅	△※	❌	❌	△	❌	△
Kubernetes統合	△	✅	✅	✅	❌	❌	❌	△
イメージビルド	✅	✅	△	❌	✅	✅	❌	✅
Pod対応	❌	✅	✅	✅	❌	❌	❌	❌
システムコンテナ	❌	❌	❌	❌	✅	❌	✅	❌
HPC/GPU対応	△	△	△	△	❌	❌	❌	✅
商用サポート	✅	✅	✅	✅	✅	✅	✅※	✅

※nerdctlを使用すればDocker互換
※systemd-nspawnはsystemdの一部として商用Linuxディストリビューションでサポート

4.2 パフォーマンス比較

指標	Docker	Podman	containerd	CRI-O	LXC/LXD	systemd-nspawn	Singularity
起動時間	普通	やや速い	高速	高速	速い	高速	普通
メモリ使用量	普通	少ない	最小	最小	普通	少ない	少ない
イメージプル速度	普通	普通	高速	高速	普通	N/A	普通
ビルド速度	普通	やや遅い	-	-	普通	N/A	普通

4.3 ユースケース別推奨

ユースケース	推奨エンジン	理由
ローカル開発（Docker代替）	Podman	Docker互換で移行が容易、rootless
Kubernetesクラスタ	containerd / CRI-O	軽量で最適化されている
CI/CDパイプライン	Podman + Buildah	rootlessで安全、ビルド最適化
仮想マシン代替	LXD / systemd-nspawn	システムコンテナで完全なOS環境
イメージビルド最適化	Buildah	細かい制御、サイズ最適化
エンタープライズ本番	Docker Enterprise / Podman	商用サポート、実績
マルチテナントホスティング	LXD	分離性が高い
エッジコンピューティング	containerd	軽量、最小リソース
HPC/科学計算	Singularity/Apptainer	GPU・MPI対応、再現性重視
デバッグ・テスト環境	systemd-nspawn	systemd統合、軽量、標準搭載
機械学習・AI研究	Singularity/Apptainer	GPU対応、単一ファイルイメージ

---

5. 実践編：Dockerから他のエンジンへの移行

5.1 PodmanへのDockerからの移行

ステップ1: Podmanのインストール

# macOS
brew install podman
podman machine init
podman machine start

# Linux
sudo apt-get install -y podman  # Ubuntu/Debian
sudo dnf install -y podman      # RHEL/Fedora

ステップ2: Dockerコマンドの置き換え

# エイリアス設定（bashの場合）
echo "alias docker=podman" >> ~/.bashrc
source ~/.bashrc

# または、podman-dockerパッケージをインストール（Linuxのみ）
sudo apt-get install -y podman-docker

ステップ3: 既存のイメージとコンテナの移行

# Dockerからイメージをエクスポート
docker save -o myimage.tar myimage:latest

# Podmanでインポート
podman load -i myimage.tar

# または、Docker Hubから直接プル
podman pull docker.io/library/nginx:latest

ステップ4: Docker Composeの代替

# podman-composeのインストール
pip3 install podman-compose

# 使い方はDocker Composeと同じ
podman-compose up -d
podman-compose ps
podman-compose down

docker-compose.yml例

version: '3'
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html
  db:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

ステップ5: systemdによる自動起動設定（Quadlet使用）

注意: podman generate systemdコマンドはv4.7.0以降非推奨です。代わりにQuadlet（v4.4.0で導入）を使用してください。

Quadletとは: systemd統合を簡素化する仕組みで、.containerファイルを作成するだけでsystemdユニットが自動生成されます。

# Quadlet設定ディレクトリの作成
mkdir -p ~/.config/containers/systemd

# .containerファイルの作成
cat > ~/.config/containers/systemd/web.container << 'EOF'
[Container]
Image=docker.io/library/nginx:latest
PublishPort=8080:80
Volume=/path/to/data:/usr/share/nginx/html:Z

[Service]
Restart=always

[Install]
WantedBy=default.target
EOF

# systemd設定の再読み込み
systemctl --user daemon-reload

# サービスの有効化と起動
systemctl --user enable --now web.service

# 状態確認
systemctl --user status web.service

参考リソース:

• Quadlet導入: https://github.com/containers/podman/releases/tag/v4.4.0
• podman generate systemd非推奨化: https://github.com/containers/podman/releases/tag/v4.7.0
• Quadletドキュメント: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

5.2 Kubernetesでcontainerdを使用

既存クラスタでDockerからcontainerdへ移行

# 1. containerdのインストール（全ノード）
sudo apt-get install -y containerd.io

# 2. containerd設定
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# 3. systemd cgroup ドライバーを有効化
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

# 4. containerd起動
sudo systemctl enable --now containerd

# 5. kubeletの設定変更
sudo nano /var/lib/kubelet/kubeadm-flags.env
# --container-runtime=remote
# --container-runtime-endpoint=unix:///run/containerd/containerd.sock

# 6. kubelet再起動
sudo systemctl restart kubelet

# 7. ノードの状態確認
kubectl get nodes -o wide
# CONTAINER-RUNTIME列がcontainerdになっていることを確認

新規Kubernetesクラスタ構築（containerd使用）

# kubeadm設定ファイル
cat << EOF > kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
  criSocket: unix:///run/containerd/containerd.sock
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF

# クラスタ初期化
sudo kubeadm init --config=kubeadm-config.yaml

# kubeconfigセットアップ
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# CNIプラグインインストール（例：Calico）
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# ノード確認
kubectl get nodes

---

6. トラブルシューティング

6.1 Podman関連

問題: "permission denied"エラー

# 原因: rootlessモードでのストレージ権限問題
# 解決策: サブUID/サブGIDの設定確認
cat /etc/subuid
cat /etc/subgid

# ユーザーがない場合は追加
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $USER

# Podman設定のリセット
podman system reset

問題: "Error: short-name resolution"

# 原因: イメージ名の曖昧さ
# 解決策: 完全なレジストリパスを指定
podman pull docker.io/library/nginx:latest

# または、registries.confで優先レジストリを設定
sudo nano /etc/containers/registries.conf
# unqualified-search-registries = ["docker.io"]

問題: ポート8080が使用できない

# 原因: rootlessモードでは1024未満のポートは特権が必要
# 解決策: 高い番号のポートを使用するか、net.ipv4.ip_unprivileged_port_startを変更
sudo sysctl net.ipv4.ip_unprivileged_port_start=80
echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee -a /etc/sysctl.conf

6.2 containerd関連

問題: nerdctlでイメージがプルできない

# 原因: 名前空間の問題
# 解決策: 明示的に名前空間を指定
sudo nerdctl -n k8s.io images
sudo nerdctl -n default images

# デフォルト名前空間の設定
echo 'export CONTAINERD_NAMESPACE=default' >> ~/.bashrc

問題: Kubernetesのポッドが起動しない

# デバッグ: containerdのログ確認
sudo journalctl -u containerd -f

# crictl（CRI互換CLI）でデバッグ
sudo crictl ps -a
sudo crictl logs <container-id>
sudo crictl inspect <container-id>

# runtimeエンドポイントの確認
sudo crictl info

6.3 CRI-O関連

問題: CRI-Oサービスが起動しない

# ログ確認
sudo journalctl -u crio -f

# 設定ファイルの検証
sudo crio config > /tmp/crio-config.toml
# エラーがあればここで表示される

# 設定の再読み込み
sudo systemctl daemon-reload
sudo systemctl restart crio

6.4 共通問題

イメージレジストリへの接続エラー

# プロキシ設定が必要な場合
sudo mkdir -p /etc/systemd/system/containerd.service.d
cat << EOF | sudo tee /etc/systemd/system/containerd.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1"
EOF

sudo systemctl daemon-reload
sudo systemctl restart containerd

ストレージ容量不足

# 未使用イメージの削除（Podman）
podman image prune -a

# 未使用コンテナとイメージの削除（containerd）
sudo nerdctl system prune -a

# ストレージ使用状況の確認
df -h /var/lib/containers  # Podman
df -h /var/lib/containerd  # containerd

---

7. まとめと選択ガイド

7.1 シナリオ別最適解

シナリオ1: 開発環境でDocker Desktopの代替が欲しい

推奨: Podman

# 理由
- Docker互換のCLI
- Dockerfileがそのまま使える
- rootlessで安全
- 無料で制限なし

# クイック移行パス
brew install podman
podman machine init
podman machine start
alias docker=podman

シナリオ2: Kubernetesクラスタを構築したい

推奨: containerd または CRI-O

# containerdの場合
- 広く採用されている
- パフォーマンスが高い
- ドキュメントが豊富

# CRI-Oの場合
- Kubernetes専用で最適化
- セキュリティ重視
- Red Hat環境との相性が良い

シナリオ3: CI/CDパイプラインでイメージをビルドしたい

推奨: Podman + Buildah

# 理由
- rootlessで安全にビルド可能
- GitLab CI、GitHub Actionsで使用可能
- Dockerfileも使える
- イメージサイズの最適化が容易

# GitLab CI例
build:
  image: quay.io/podman/stable
  script:
    - buildah bud -t myimage:$CI_COMMIT_SHA .
    - podman push myimage:$CI_COMMIT_SHA

シナリオ4: 開発・テスト環境を素早く構築したい

推奨: LXD

# 理由
- 完全なLinux環境
- スナップショットで状態管理
- 複数環境の並行管理が容易

# 使用例
lxc launch images:ubuntu/22.04 dev-env
lxc exec dev-env -- bash
# 開発完了後
lxc snapshot dev-env clean-state

7.2 組み合わせ戦略

実際の開発では、複数のツールを組み合わせることで最大の効果を発揮します：

パターン1: フルPodmanスタック

開発: Podman
ビルド: Buildah
本番: Podman（systemd統合）
オーケストレーション: Kubernetes + CRI-O

パターン2: クラウドネイティブスタック

開発: Docker / Podman
ビルド: CI/CDのネイティブ機能
本番: Kubernetes + containerd

パターン3: ハイブリッドスタック

開発: Podman（ローカル）
テスト環境: LXD（複数環境）
本番: Kubernetes + CRI-O

7.3 移行のベストプラクティス

段階的移行アプローチ

フェーズ1: 評価（1-2週間）

• 非本番環境で試用
• パフォーマンステスト
• 既存スクリプトの互換性確認

フェーズ2: パイロット（1-2ヶ月）

• 特定チーム・プロジェクトで導入
• 問題点の洗い出し
• ドキュメント整備

フェーズ3: 本格展開（3-6ヶ月）

• 全チームへの展開
• トレーニング実施
• サポート体制確立

チェックリスト

□ チームメンバーのトレーニング完了
□ CI/CDパイプラインの更新
□ Dockerfileの互換性確認
□ イメージレジストリの動作確認
□ ネットワーク設定の確認
□ ストレージ設定の確認
□ セキュリティポリシーの更新
□ ドキュメントの更新
□ ロールバック手順の準備

---

8. 参考リソース

公式ドキュメント

• Podman: https://docs.podman.io/
• containerd: https://containerd.io/docs/
• CRI-O: https://cri-o.io/
• LXD: https://linuxcontainers.org/lxd/
• Buildah: https://buildah.io/

コミュニティとサポート

• Podman GitHub: https://github.com/containers/podman
• containerd Slack: https://slack.cncf.io/ (#containerd)
• Kubernetes Slack: https://slack.k8s.io/ (#cri-o, #containerd)
• LXD Forum: https://discuss.linuxcontainers.org/

学習リソース

• Red Hat Blog: https://www.redhat.com/en/blog - Podman/CRI-O関連記事
• CNCF YouTube: https://www.youtube.com/c/cloudnativefdn - containerd/Kubernetes動画
• Kubernetes Documentation: https://kubernetes.io/docs/setup/production-environment/container-runtimes/

ツールとユーティリティ

• nerdctl: containerd用のDocker互換CLI
  • https://github.com/containerd/nerdctl
• podman-compose: Docker Compose互換ツール
  • https://github.com/containers/podman-compose
• crictl: CRI互換ランタイム用CLIツール
  • https://github.com/kubernetes-sigs/cri-tools
• skopeo: コンテナイメージ操作ツール
  • https://github.com/containers/skopeo

---

おわりに

コンテナ技術の世界は、Dockerだけではありません。本記事で紹介した各コンテナエンジンは、それぞれ異なる強みと用途を持っています。

重要なポイント:

1. 目的に応じた選択: 開発、CI/CD、本番環境それぞれで最適なツールは異なる
2. 標準への準拠: OCI/CRI準拠により、ツール間の互換性が保たれている
3. 段階的な移行: 一度に全てを変える必要はなく、段階的に導入可能
4. コミュニティの活用: オープンソースコミュニティが活発で、サポートが充実

コンテナエンジンの選択は、技術的要件だけでなく、チームのスキルセット、組織のポリシー、コスト要因なども考慮する必要があります。本記事が、あなたのプロジェクトに最適なコンテナエンジンを選択する助けになれば幸いです。

---

執筆日: 2025年1月
対象バージョン: Podman 4.x, containerd 1.7.x, CRI-O 1.28.x, LXD 5.x, Buildah 1.x, Kata Containers 3.x, gVisor 2023.x, Firecracker 1.x

関連記事

• サーバーレス/FaaSにおけるセキュリティとオブザーバビリティ完全ガイド - Lambda等のFaaS環境での監視とセキュリティ戦略

---

ご質問やフィードバックがあれば、コメント欄でお気軽にお知らせください！