CentOS + KUSANAGIの構成から Ubuntu + WordOps へ移行して、最も「運用感が変わった」と感じるのがミドルウェア（Webスタック）の管理方法です。
KUSANAGIでは kusanagi status や monit などの組み合わせ、あるいは systemctl で個別にサービスを制御することが多かったですが、WordOpsには wo stack という強力なスタック管理コマンドが一式用意されています。
今回は、Nginx / MariaDB / Redis / PHP-FPM などを一括・個別で制御する WordOps 特有のスタック管理術と、実際の運用でよく使うコマンドについて解説します。
1. まずは死活監視の基本：wo stack status
サーバー全体のスタックが正常に動いているか確認したい時は、まずこのコマンドを叩きます。
wo stack status
実行すると、Nginx、MariaDB、Redis、各種PHP-FPM（8.1/8.2/8.3等）の動作状態（Running / Stopped）が一発で一覧表示されます。systemctl status nginx や systemctl status mariadb を個別に確認して回る必要がなく、「今どのミドルウェアが死んでいるか」が1秒で視認できるのがWordOpsの大きなメリットです。
2. サービスの再起動・再読み込み（Reload / Restart）
設定変更時や動作が怪しい時、個別または一括でサービスを再起動・リロードできます。
全スタックを一括再起動
wo stack restart
特定のミドルウェアだけをリロード／再起動
WebサイトをダウンさせずにNginxの設定変更だけを反映させたい場合は reload を使います。
- Nginxの設定再読み込み
wo stack reload --nginx - PHP-FPMだけを再起動
wo stack restart --php82 - MariaDBだけを再起動
wo stack restart --mysql
KUSANAGIの kusanagi restart 相当の動きも、wo stack restart 1本でスマートにこなせます。
3. ミドルウェアの追加・削除（Purge / Install）
WordOpsの面白いところは、後からスタックを追加・削除するのも wo stack 経由で行える点です。
- Redisキャッシュを後から追加する場合
wo stack install --redis - 不要になったスタックを完全に削除する場合
wo stack purge --redis
パッケージの依存関係を崩さずに、WordOpsの管理下で安全にスタックの構成を変更できます。
4. KUSANAGI運用者が戸惑いやすいポイントと注意点
systemctl との併用について
WordOps管理下のサービスも内部的には systemd で動いているため、systemctl restart nginx も通ります。しかし、WordOps側で設定ファイルを追跡・管理している関係上、基本的には wo stack コマンドを経由して操作するのが推奨 です。
ログの確認場所
wo stack status で異常が見つかった場合、ログは以下のパス（主に /var/log/ 配下）を確認します。
- Nginx:
/var/log/nginx/error.log - WordOps全体:
/var/log/wo/wordops.log - PHP-FPM:
/var/log/php/
まとめ：wo stack を覚えるとインフラ運用が劇的に楽になる
CentOS時代の systemctl 連打や、KUSANAGI特有のコマンド群に慣れていると最初は戸惑うかもしれませんが、wo stack の直感的な操作感に慣れると手放せなくなります。
「Nginx・MariaDB・Redis・PHPを一括で把握・制御できる」というWordOpsの強みを活かして、安定したサーバー運用を目指しましょう！
コメント