自宅のベアメタルサーバー環境において、CentOS Stream 9 ＋ KUSANAGI 9 から Ubuntu ＋ WordOps へ移行した際の技術的知見・ネットワーク制約のハマりどころをまとめます。

1. KUSANAGIとWordOpsの基本比較

どちらもNginx + PHP + MariaDB + 高速キャッシュ構成をCLIから一発構築できる優れたツールですが、アプローチや得意環境が異なります。

項目	KUSANAGI 9 (RHEL系)	WordOps (Debian/Ubuntu系)
対応OS	CentOS Stream / AlmaLinux / Rocky Linux 等	Ubuntu / Debian
サイト作成コマンド	`kusanagi provision ...` (オプション多数)	`wo site create ...` (自動生成メイン)
標準キャッシュ	Fcache (Nginx FastCGI) / Bcache	Redis Cache (インメモリ) / FastCGI
主な提供形態	クラウドイメージ / VM / Docker 前提	ベアメタル（OS直上） / VPS

2. MAP-E（IPv4 over IPv6）環境でKUSANAGIのProvisionが失敗する根本原因

MAP-E環境（XG-100NE等）では、利用可能なIPv4ポートが制限されており、0〜1023番のウェルノウンポート（80/443）が使用できません。

詰まるメカニズム

kusanagi provision 実行時、内部でLet's Encrypt（Certbot）のHTTP-01チャレンジ（80番ポート経由）が自動実行される
80番ポートが塞がっているため認証がタイムアウト・失敗する
プロビジョニング全体の処理が強制中断される

回避策とその限界（ポート問題）

--noemail オプション等でCertbotの起動をスキップし、プロビジョニング完了後に手動で DNS-01チャレンジ（DNSのTXTレコード認証）を通せばSSL証明書自体の取得は可能です。

しかし、自宅ルーター単体でポート開放（NAPT）を行う場合、https://example.com:50080 のように変則ポート番号付きのURLになってしまい、標準ポート（443）でのWeb公開ができません（※外部に前段リバースプロキシを置く構成が必要になります）。

3. ベアメタル運用における構成の違い

KUSANAGI 9 の制約:
公式イメージ（OVAやKUSANAGI Runs on Docker）が基本となるため、物理CentOS Stream 9の上に仮想化/コンテナ基盤を敷き、その中で再度Stream 9イメージを動かす二重構造になりがち。
WordOps の利点:
物理Ubuntu環境の直上に直接スタックを構築可能。/var/www/<domain>/htdocs/ にファイル実体が配置されるため、ディスク障害時のデータサルベージや可搬性がシンプル。

4. WordOpsによるRedis Cacheスタックの即時構築

WordOpsを採用した場合、以下の1コマンドでNginx + Redis Cache + SSL構成が自動生成されます。

# WordOpsのインストール（Ubuntu）
wget -qO wo wops.cc && sudo bash wo

# Redis Cache付きWordPressサイト作成
sudo wo site create example.com --wp --wpredis --letsencrypt

DB名やランダムパスワードは自動生成され、メモリ上で完結するRedisキャッシュがNginxに直接バインドされます。

まとめ：環境ごとの使い分け

クラウド / VPS（固定IPv4 / 80・443解放環境）:
公式イメージが一発でデプロイでき、堅牢かつ高速な KUSANAGI が圧倒的に快適。
自宅ベアメタル / ポート制限環境:
前段にVPSプロキシ等を配置し、物理OS直上で柔軟に動かせる Ubuntu ＋ WordOps が取り回しやすい。

※ブログ本編では、MAP-E環境でのルーティング構成や、DNS-01チャレンジ検証時の詳細なログなども交えて解説しています。

👉 【MAP-Eの壁】KUSANAGIのprovisionが300%コケる理由と、ベアメタル自宅サーバーをUbuntu＋WordOpsへ移行した真実