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

長年CentOS（RHEL系）でサーバーを触ってきた管理人ですが、WordOpsを使うためにUbuntuサーバーを構築し、Webサイトを移転させました。
CentOS Stream 9でWordPressを動かすとなれば、やはり第一候補に挙がるのは超高速CMS実行環境 「KUSANAGI（KUSANAGI 9）」 ですよね。管理人も長年KUSANAGIの圧倒的な速度と堅牢性にお世話になってきました。
しかし、今回我が家のネットワーク環境（XG-100NEのMAP-E環境）において、0〜1023番ポートの閉塞によるCertbotのSSL証明書取得エラー（80番ポート不可）のせいで、kusanagi provision が300%の確率で失敗するという致命的な壁に激突。
「このままではCentOS＋KUSANAGIでサイトを移転・維持できない…！」と絶望し、背に腹は代えられない思いでUbuntuへお引越し、そして海外で絶大な人気を誇る管理ツール 「WordOps」 を導入することになりました。

結論から言うと、「どちらもキャッシュを効かせた爆速環境だが、KUSANAGIがFastCGI Cache（ファイルキャッシュ）主体なのに対し、WordOpsはインメモリで爆速な『Redis Cache』をコマンド1行で組み込める手軽さがある」 ので、KUSANAGIのコマンドに手が慣れきっていると驚きの連続になります。

💡 KUSANAGIとWordOpsの基本比較

どちらも「簡単なCLIコマンド一発で、超高速なWordPress環境（Nginx + PHP-FPM + MariaDB + キャッシュ設定）を構築してくれる」という目的は共通しています。

🔍 オプションが超絶長いKUSANAGIの provision vs 1行で終わるWordOpsの site create

CentOS Stream 9＋KUSANAGI時代、サイトを1つ追加（プロビジョニング）するときに一番タイピング量が多かったのが kusanagi provision でした。

KUSANAGIはコマンドライン引数で一気にパラメータを指定するスタイルですが、WordPressサイトを建てるだけでも、以下のような画面からはみ出るレベルの長大なコマンドを打つ必要がありました。

# KUSANAGIでおなじみの「オプション指定が盛り盛りで長すぎる」コマンド例
# The classic overly long KUSANAGI command with endless options
kusanagi provision --wp --fqdn example.com --email mail@example.com --dbname mydb --dbuser myuser --dbpass mypass --admin-email mail@example.com --title "my-blog" --adminuser myadmin --adminpass myadminpass profile

# KUSANAGIでおなじみの「オプション指定が盛り盛りで長すぎる」コマンド例
# The classic overly long KUSANAGI command with endless options
kusanagi provision --wp --fqdn example.com --email mail@example.com --dbname mydb --dbuser myuser --dbpass mypass --admin-email mail@example.com --title "my-blog" --adminuser myadmin --adminpass myadminpass profile

DB名、DBユーザー、パスワード、管理者情報、ドメイン名……と、オプションをこれでもかと並べ立てる必要があり、コマンドを組むだけでも一苦労です。

それに対して、UbuntuのWordOpsでサイトを建てるときはこうです。

# WordOpsのサイト作成コマンド（Redis Cache＋SSL付き）
# WordOps site creation command (with Redis Cache & SSL)
wo site create example.com --wp --wpredis --letsencrypt

# WordOpsのサイト作成コマンド（Redis Cache＋SSL付き）
# WordOps site creation command (with Redis Cache & SSL)
wo site create example.com --wp --wpredis --letsencrypt

圧倒的にシンプルです。

WordOpsで真の爆速環境を作るなら、FastCGI Cache（--nginx-cache）ではなく --redis オプションを指定するのが鉄板です。これだけでNginxから直接Redis（メモリ上）のキャッシュを参照する超高速スタックが組み上がり、DB名やパスワード等もWordOps側が裏で自動生成してくれます。
コマンド実行後に「作成完了！WordPressのログイン情報とDBパスワードはこちらです」とターミナルにポンと表示されるのを見たとき、「KUSANAGIであんなに長いオプションを打ち込んでいたのは何だったんだ……！？」と感動と拍子抜けが同時に押し寄せてきました（笑）。

🚨 MAP-E（IPv4 over IPv6）の壁：なぜKUSANAGIを諦めざるを得なかったのか？

ここで、管理人が長年愛用したKUSANAGIを泣く泣く手放した「技術的な本当の理由」について触れておきます。
自宅や特定回線のMAP-E環境（IPv4 over IPv6）では、割り当てられるIPv4ポート番号が制限されており、何人たりとも0〜1023番のウェルノウンポート（80番や443番など）をサーバー側で開放して使うことができません。
このネットワーク制約下でCentOS Stream 9 ＋ KUSANAGIを動かそうとすると、以下の構造的な問題で詰みます。

1. kusanagi provision 内で自動実行されるCertbot（80番ポート）がコケる
   KUSANAGIのプロビジョニング手順には、標準でSSL証明書を取得する処理が含まれています。これが Let’s Encrypt の HTTP-01チャレンジ（80番ポート経由の認証） を叩きにいくため、ウェルノウンポートが塞がっているMAP-E環境では絶対に通信が届かずエラーになります。
2. 結果として kusanagi provision 自体が300%失敗して完走しない
   内部のSSL取得処理で引っかかるため、プロビジョニング全体のプロセスが途中で強制終了してしまいます。

「KUSANAGI自体は最高なのに、MAP-Eのポート制限×Certbotの仕様上、どうしてもプロビジョニングが完走しない…」という完全な詰み状態に陥ったわけです。

💡 【検証】一応KUSANAGIでも回避する「裏ワザ」はある（ただしURLに罠がある）

…と、ここまで「MAP-E環境でKUSANAGIは詰む」とお話ししましたが、実はあとから調べて分かった回避策（裏技）自体は存在します。
MAP-Eでコケる原因は、kusanagi provision の途中で実行される「80番ポートを使ったCertbot（HTTP-01チャレンジ）」です。
であれば、「プロビジョニング時のSSL発行処理を力技でスキップし、あとからポート不要の認証を通せば良い」ということになります。

具体的には以下の手順です。

1. kusanagi provision 実行時に --noemail オプションを付与して、Certbotの自動起動（メールアドレス登録とSSL取得）を強制スルーする
2. 無事にプロビジョニングを完走させた後、80番ポートを使わない 「DNS-01チャレンジ（DNSのTXTレコードに認証コードを書いて証明書を発行する方式）」 を手動で叩いて証明書を取得する

「よし！これでKUSANAGI＋MAP-EでもSSL化できた！」…と一瞬歓喜するのですが、ここでMAP-E（XG-100NE）の更なる現実が突きつけられます。
80/443番のウェルノウンポートが開けないため、XG-100NE単体でポート開放（NAPT）を行った場合、割り当てられた変則ポート（例: 50080 など）を開放するしかありません。
結果どうなるかというと、アクセスするURLが https://test-site.online:50080 のように、末尾にポート番号を付けないと外部からページが開けないサイトになってしまうのです。

一般のWebサイトとして https://test-site.online（443番）で公開したい場合、これでは到底実用に耐えません。
「DNS-01で証明書自体は通せても、結局Webサイトとしてまともに公開・運用できない」
だからこそ、変にKUSANAGIで無理をするのをやめて、前段にConoHa VPSなどのプロキシを挟みつつ、Ubuntu＋WordOpsへ乗り換えてネットワーク構成ごと見直すのが正解だった、というわけです。

🪆 究極の虚無：「Stream 9の中でまたStream 9を動かす」マトリョーシカ現象

そしてもう一つ、個人が自宅のPC（ベアメタル機）でKUSANAGIを運用しようとした際に突きつけられるのが、「ベアメタル直上での実装ができない」 というKUSANAGI（KUSANAGI 9）の提供形態の壁です。
個人向けに提供されているKUSANAGI 9の公式イメージ（OVA等）は、基本的にVMware等のハイパーバイザーかDocker（KUSANAGI Runs on Docker）前提となっています。物理OSの直上に直接組み込むスクリプトが用意されていません。
つまり、CentOS Stream 9をベアメタル（物理機）にインストールしてKUSANAGIを動かそうとすると、

「ベアメタルのStream 9の上にVMwareやDockerを立てて、その中でさらに Stream 9 ＋ KUSANAGI のイメージを展開する」

という、究極のマトリョーシカ状態（Stream 9 in Stream 9）に陥ります。
「いや、ベースOSと同じOSを中で動かしてどうすんだ！」という身も蓋もない構成を強いられるわけですｗ

📦 さらに付きまとう「データ抽出・可搬性」の罠

この「イメージ展開前提」の仕組みは、万が一のトラブルやデータ移行の際にも重くのしかかってきます。
KUSANAGIをイメージファイル（VMDK等）として運用している場合、WordPressのコンテンツデータもデータベースも、すべてその仮想ディスクイメージの中にパッケージングされます。

• KUSANAGIのデータ移行：
  イメージ丸ごとコピーして別環境へ持っていくのは楽です。しかし、「特定のWordPressサイトのデータやDBだけをさらっと抽出したい」となった場合、どうひっくり返してもサーバーを正常起動（運転）状態にして内部から出力させないと抽出できないという制約があります。万が一イメージや仮想化基盤が壊れてOSが立ち上がらなくなると、データ救出のハードルが途端に跳ね上がります。
• Ubuntu ＋ WordOps（ベアメタル）のデータ移行：
  物理OSの直上にダイレクト構築されるため、標準ディレクトリ（/var/www/ 等）に生データがそのまま存在します。最悪OSが死んでも、レスキューメディア等でストレージを読み込めば必要なファイルやDB実体をいつでも「手動でさらっと救出」できます。

📝 最終結論：KUSANAGIの真価を出したいならレンタルサーバーで使え！

ここまで自宅サーバー（ベアメタル×MAP-E）における実情を語ってきましたが、誤解のないように言っておくと、KUSANAGIというプロダクト自体はWordPressを超高速化する環境として圧倒的に優秀です。
ただし、今回の検証でハッキリした結論は一つ。

「KUSANAGIの恩恵をフルに享受したいなら、大人しくKUSANAGI対応のレンタルサーバーやVPS（AWS / ConoHa / さくらのVPS等）で使え」

ということです。
固定IPv4アドレスが割り当てられ、80/443ポートが素直に開いており、公式のKUSANAGIイメージが一発でデプロイできるクラウド環境であれば、kusanagi provision も一瞬で成功し、超強力なパフォーマンスを発揮してくれます。
逆に、自宅サーバー（特にMAP-E等の変則ネットワーク＋ベアメタル機）で無理にKUSANAGIを動かそうとすると、ネットワークと提供形態の壁に阻まれて不要な苦労を重ねることになります。

• クラウド / レンタルサーバー環境 ➔ 「KUSANAGI」一択！
• 自宅ベアメタル ＋ 特殊ネットワーク環境 ➔ 前段プロキシ ＋ 「Ubuntu ＋ WordOps」が最適解！

「自分のインフラ環境に合わせて、適切なツールを選ぶ」
長年連れ添ったCentOS Stream 9 ＋ KUSANAGIから、Ubuntu ＋ WordOpsへのお引越し劇を通じて、インフラ運用の原点を改めて学んだ気がします(´･ω･)y-~~