自宅のベアメタルサーバー環境において、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へ移行した真実