レンタルサーバーで運用中のワードプレスをVPSに引越しするための検討（WordPressでは書けないブログ運営論#25）

現在、WordPress（ワードプレス）をレンタルサーバーのConoHa WINGで運用していますが、速度が一向に速くならないため、速度が遅くなるたびに他社のサーバーのスペックやプランを比較するのが面倒なので、この運用から解放されたいです。

この投稿ではレンタルサーバーの遅さを改善するために検討した結果を書いています。
なお検討段階ではまだレンタルサーバーのままです。

（出展：https://kusanagi.tokyo/）

レンタルサーバーの共有サーバーで遅くなる運用から解放されたい

レンタルサーバーの会社やプランを変えても、共有サーバーである限り、他ドメインのサイトと同居せざるを得ず、同居サイトが増えるといつかは必ず重くなって、速度が遅いという最初の問題に戻ります。

ConoHa WINGは「国内最速」が売り文句ですが、共有サーバーなので、同居ドメインが増えると結局は遅くなります。
ConoHa WINGが悪いわけではなく、レンタルサーバーの技術的な限界だと思います。

サーバーマイグレーションはかなりの同居ドメインにならないと使えない
また、ConoHa WINGでは、1サーバーに同居ドメインが増えたら収容数の少ないサーバーへ移行する「サーバーマイグレーション」というオプションもあります。
が、まだサーバーリソースに空きがあると判断された場合は使えません。
恐らく100ドメインかそれ以上の同居ドメインがないと、マイグレーション判定がOKにならないと思われます。

VPSへの移行で解決しないか

恒久的に遅さの問題を解消する方法を考えた結果、ワードプレスを置くサーバーをVPSに移行する事で解決するのではないか、と思いました。
自分の技術や知識で出来るかどうか分からないため、まずは検討と情報収集を行いました。

WordPressの移行自体はプラグインで簡単に行える
レンサバ間のWordPressの移行の場合、レンサバA社からレンサバB社にWordPressを移設するのは、難しそうに思えますが、非常に簡単です。
詳細は省きますが、All-in-One WP Migrationという無料プラグインを使います。

移行元レンサバA社のワードプレスサイトでAll-in-One WP Migrationでサイトデータをエクスポート。
移行先レンサバB社に仮の状態のWordPressサイトを作り、取得したエクスポートファイルをインポート。
これで自動的にA社で運用していたワードプレスの状態がB社で復元されます。

実際にレンサバ間で移行した内容を以下の記事に書いています。
エックスサーバーからConoHa WINGへのWordPress移行手順を作成しました。（2019年版）【事前作業・問題解決・全画像有】※All-in-OneWP使用

VPS移行でも同じ原理で、レンサバA社のWordPressでAll-in-One WP Migrationを使ってサイトデータをエクスポートし、VPS環境に立てた仮のワードプレスに、そのデータをインポートしてWordPressを復元させます。
この方法でVPSにWordPress移行したという情報もネットに沢山あります。

AWSは通信料の増額が怖い
なお当初はVPSではなくAWS（Amazon Web Services）へ引越しする事を検討しましたが、AWSでは通信料の増加で料金が増額するらしく、「AWSへ移行したけど通信料が高いのでレンサバやVPSに戻した」という記事が見られたため、AWSへの移行は取りやめVPSへの移行を検討することにしました。

検討した結果、Nginxで.htaccessが使えない事が判明

検討していった所、.htaccessの扱いがネックになってくると分かってきました。

.htaccessは、Webサーバー用の設定ファイルで、IP制限やリダイレクトを簡単に実現出来ます。
レンタルサーバーの場合も、.htaccessを使う事で、許可IPレンジ、拒否IPやドメインを記したり、301リダイレクト処理をさせる事で、簡単にセキュリティ的な設定したりリダイレクトを実現出来ました。

.htaccessは、極論すると、サーバーソフトのApacheの仕様を全く知らなくても設定出来ます。
例えば、Apacheの設定ファイル（httpd.conf）の書式を知らなくても、.htaccessの書き方さえ分かれば、.htaccessは作ることが出来ます。
.htaccessの参考情報はネットに非常に多いので、参考例に困る事はありません。

ConoHa VPS公式サイト

世界最速級 WordPressならConoHa VPS｜VPSならConoHa

Nginxでは.htaccessが動作しない
ConoHa VPS+KUSANAGI環境では、導入のコマンドで使用Webサーバーの選択があり、Apache（アパッチ）かNginx（エンジンエックス）を選ぶ事になります。（VPSやKUSANAGIについては後述。）

手順的にはConoHa VPSで導入サーバーのスペックを選んだ後、ConoHa VPSの管理画面に入り、仮想マシンの電源を投入し、コンソールからrootユーザーで仮想マシン（サーバー）にログインします。
初期設定のためコマンドを入れます。
# kusanagi init

対話式の設定画面になり、Webサーバーの選択で
1) NGINX(Default)
を選んでNginxを使う事を指定します。

導入手順を検討していて、レンサバで設定している.htaccessをどの段階で移行しようかと考えているうち、「Nginx環境では、.htaccessが動作しない」という情報を目にしました。
Webサーバーで.htaccessが使えるのは半ば常識になっているので、かなり衝撃を受けました。

Nginxの解説（カゴヤのサーバー研究室）

【入門】Nginx（エンジンエックス）とは？Apacheとの違いと初期設定 | カゴヤのサーバー研究室

Apacheか、Nginxか
Nginx環境では、.htaccessが動作しないという事が分かり、思ったよりVPS環境への移行は敷居が高いと思い始めました。
Nginxの書籍もありましたが、Apacheや.htaccessに比べると圧倒的に情報が少ない印象です。

nginx実践入門 WEB+DB PRESS plus

Nginx ポケットリファレンス

方針としては、

・WebサーバーにNginxを使わず、Apacheを使う（.htaccessを使う）
・WebサーバーにNginxを使い、.htaccessと似た挙動を再現させる（.htaccessが使用不可）

のどちらかになります。

Apacheを使う場合、ConoHa VPS+KUSANAGI環境ではNginxを前提としているらしく、折角のKUSANAGIでもパフォーマンスを引き出せない事が予想されます。この情報もはっきりとソースは確認していないので間違っている可能性があります。

Nginxの場合はインフラレベルの知識が必須
Nginxを使う場合、これまで.htaccessで使っていたリダイレクトや許可・拒否設定を、Nginx側のconfファイルに設定として移行する作業が必要です。
設定を移行する場合、Nginxの仕様やconfの書き方を調べる必要があります。
この時点で、インフラレベルの知識がある程度必要になります。

また、ApacheとNginxは同サーバーに同居させる事も出来ますが、その場合、同じポート番号が使われているので、どちらかのサービスのポート番号を変更させる等の措置も必要です。
これもインフラ知識がないと難しいと思います。

ConoHaは、海外からのアクセスを許可しているので、レンタルサーバーを運用していると猛烈にスパムがきます。
そのため個人でスパム対策が必須ですが、.htaccessがスパムの抑制に役に立っているので、.htaccessが使えない場合、別の手段でセキュリティを担保する必要があります。

Nginxのconfファイル（/etc/nginx/nginx.conf）の書き方は、割と簡略化されているので、分かれば複雑ではないと思いますが、Nginxのconfファイル全体の記述をデザインする必要があります。

結局Nginxを使う

色々調べた結果、自分に出来そうなやり方を考えてNginxを使いたいと思います。

.htaccessで書いている内容で、自分で追加した部分は以下の4つです。
これらをどうにかすればNginxが使えると思っています。
・日本国内のIPレンジをAllow
・スパムドメイン、スパムIPをDeny
・httpからhttpsへのリダイレクト
・301リダイレクト関連（カテゴリーやタグ）

confの書き方としては、こちらの記事で書かれているように、許可IPや拒否IPを一括して外出しファイルに書き、それらをnginx.confでincludeして読み込ませるやり方を考えています。

nginxで遮断IPアドレス一覧を外部ファイルで管理する

リダイレクト関連の記述については、VPSかKUSANAGIのコマンドでありそうなので、そちらの周辺で調査をする予定です。

VPSとKUSANAGI

VPSは自分が好きに使える仮想マシン
VPSは「バーチャル・プライベート・サーバー」の略で、自分が好きに使える仮想マシンのことです。
ConoHa WINGと違う点は、レンサバは一つのサーバーの中で、他のユーザと同じリソースを共有（同居）するイメージですが、VPSの場合は仮想マシンですが完全に自分だけのマシン環境になり、リソースも占有出来ます。
その代わり、マシンの初期セットアップや運用など、やるべき作業がかなり増えます。
「環境を丸ごと貸す代わりに、設定は自分でやってね」というのがVPSです。

特に、ConoHa VPSでは、ほぼセキュリティのない状態でインターネットにつながる環境に放り出されるので、何も対策しないとポートスキャンされてアタックの対象にされます。
VPSでは自分である程度セキュリティ設定をする事は必須です。
以下にやるべき設定を挙げてみましたがこれは最低限で、他にも考慮すべき設定が多数あります。

VPS仮想マシンに行うセキュリティ設定の例
・一般ユーザーを作成（フル権限を持つrootを使わない）
・wheelグループに一般ユーザーを所属させる
・一般ユーザーがsudoを利用可能にする
・SSH初期ポート番号の変更
・SSHでrootのログイン禁止（一般ユーザーでログイン）
・SSHで公開鍵認証設定（パスワード認証ではログインしない）
・ConoHa管理画面から許可ポートの設定
・firewalldの設定
・.htaccessまたはNginxのconfに許可IPレンジや拒否IPを記述（スパムの抑制）

セキュリティ対策チェックリスト

基本的セキュリティ対策チェックリスト（CentOS7 @ さくらのVPS） - Qiita

一応ConoHa公式サイトに簡単なガイドは書かれていますが、最低限の情報しか書かれていないため、自分で逐一調べたほうが確実です。
VPSスタートアップガイド

レンサバのConoHa WINGでは、ワードプレスやDBの作成はボタンを押すだけでほぼ設定が完了しましたが、VPSではまず自分が使う環境の整備（仮想マシンの初期セットアップ）から行う必要があります。
マニュアルに従ってLinuxコマンドを打つだけですが、全体の手順の整合性を取ったり、エラーのリカバリーをしたりなど結局試行錯誤になります。

VPSの設定難易度はOSインストール経験があれば出来る程度
調べた所、VPSを設定するためのコマンドの一つ一つは決して高度ではなく、普通のOS初期設定のレベルなので、OSインストールしてサーバーを設定したことがあれば出来なくもない難易度という印象です。
サーバーを一台設定するので、面倒な作業には変わりないです。

ただ、仮想環境といっても、ネットワークやルーティング、LVM（logical volume manager）でのストレージやパーティションを設定する必要はないので、その点は楽です。

重要なのは、初期セットアップだけではなく、今後サーバー一台の運用も自分自身が行う必要があります。
例えばSSL証明書の更新などです。
無料ブログやレンサバであれば必要ない作業ですが、VPSでは管理者が自分しかいないので、自分がやる必要があります。

サーバーの運用にも、自動化出来る部分と出来ない部分があり、こうした設定をするのに情報収集や試行錯誤が必要になります。

レンタルサーバーとVPSの違い
レンタルサーバーとVPSの違いについては、さくらの解説サイトが分かり易かったです。

レンタルサーバーとVPSの違い（さくらのナレッジ）

「サーバーってなに？」～初心者でもよくわかる！VPSによるWebサーバー構築講座(1) | さくらのナレッジ

有名なVPSサービスとKUSANAGI
有名なVPSサービスは、さくら、ConoHa、カゴヤ等がありますが、現在ConoHa WINGを使っていることもあり、VPSもConoHa VPSがいいと思いました。

さくら、ConoHa、カゴヤのサービス比較

KUSANAGIでワードプレスの超高速サイトを簡単に作る手順を紹介

もしConoHa以外の会社にすると、DNS等設定する箇所が増えますが、ConoHaであれば既にドメインは設定されているので、作業量は少なくて済みます。

今回は、単にVPSに移行するだけではなく、KUSANAGIを使うことが目的の一つです。
KUSANAGIは超高速のWordPress専用仮想マシンです。

KUSANAGIとは
超高速CMS実行環境「KUSANAGI」（以下「KUSANAGI」）は、プライム・ストラテジーが開発・提供する世界最速クラスの仮想マシンイメージです。
（https://kusanagi.tokyo/）

KUSANAGIの導入で、Wordpressの速度が大幅に改善されることが見込めます。
さくら、ConoHa、カゴヤの各VPSサービスとも、KUSANAGIを使えます。
今後は、VPS+KUSANAGI+Wordpressが、ワードプレスのトレンドになっていくのかもしれません。

KUSANAGI

KUSANAGIは、レンタルサーバーでは使えず、VPSサービスでしか使えません。
KUSANAGIがレンタルサーバーで使えれば、自分でVPSマシンの設定する必要がないので一番楽ですが、それがいつになるか分かりません。

追記：kagoyaのレンタルサーバーではKUSANAGIが使えるらしいです。

月額440円～のWordPress専用サーバー（インストール済！）｜クラウドとレンタルサーバーのカゴヤ・ジャパン

こちらの記事のWordPress向けプラン比較にある通りWordPress高速化
KUSANAGIがWordpress専用サーバーで「○」になっています。

WordPress向けプラン比較｜WordPress専用サーバー - 初期費用無料｜クラウドとレンタルサーバーのカゴヤ・ジャパン

ただ、kagoyaのWordpress専用サーバーでは、Wordpressの入れ直しを手動で行おうとするとKUSANAGIが入らなかったり、再インストールには再契約が必要となるといった情報もあり、契約は躊躇しました。

追記：ConoHa VPS仮想マシンの設定作業取り掛かり後

こちらの追記後の記述は後で消す可能性があります。

ConoHa VPS契約し、VPS仮想マシンの環境構築に着手しました。
VPS設定メモを仮でこちらに書いていきます。
最終的な手順をWordpressサイトで公開するか、こちらのnoteで無料公開or有料公開するか、または未公開にするかはまだ決めていません。

VPS仮想マシン設定メモ
情報収集と仮手順の作成に一週間程度かかりました。
情報収集ではConoHa VPSでWordpress環境を構築した記事を中心に参考にさせて頂きました。
その過程で出た質問をサポートに問い合わせ、サポートからの回答確認に3日程度かかりました。

実際の構築はまだ完了していませんが、約2～3日程度だと思います。（慣れている人なら数時間のレベル。）
その後で、Wordpressのエラーが出ないかを確認しますが、エラーがどの程度出るか分かりません。
エラーリカバリーに1週間かかるとして、全体の作業期間としては凡そ2～3週間程度だと思います。

大まかな作業工程
大まかな移行手順としては以下の手順になりました。
多分何のことを書いているか分からないと思うので、後述の参考サイト様の記事をご覧下さい。
間に細々とした作業もありますが書くとキリがないので、大項目レベルの内容しか書いていません。
メモなので、手順の詳細には触れていません。

①ConoHa VPS申し込みしVPSサーバーを追加（契約）
②KUSANAGI初期設定
③KUSANAGIプロビジョニング
④一般ユーザー作成・SSH環境構築（鍵認証のため鍵ペア作成・初期ポート番号変更等）
⑤ファイアウォール設定
⑥仮想マシンへWordPressインストール
⑦WordPress環境復元（All-in-One WP Migration）
⑧ドメイン設定
⑨SSL化設定
⑩Nginx設定（nginx.conf）

サポートへの質問と回答
主にSSLについて、phpMyadminについて、Nginxについて質問しました。（質問内容と回答の詳細は記しません。）

SSLは、管理画面のKUSANAGI managerからLet's Encryptで常時SSL化が設定出来るとの事です。
phpMyadminは、ConoHa VPSでは自動で入らないため、別途自分でインストールする必要があるそうです。
Nginxについては、こちらの質問が悪かったのもありますが、ミドルウェア側の質問には答えられないとして、明確な回答がされませんでした。

作業上のボトルネック
SSL化をいつするか、SSL化をどうやって行うか、Nginx環境で.htaccessをどうやって移行するか等が作業上のボトルネックになりそうです。

参考サイト様によって、SSL化は作業の早い段階で行う記事と、最終段階で行う記事がありました。
自分はSSL化はドメインレコード変更後の最終段階で行うことにしています。

SSL化の方法は、これまでCertbotという無料ツールを使ったやり方が主流で、ネット上の記事の多くもCertbotを使った設定になっています。
が、その辺りをサポートに聞いた所、上述したようにKUSANAGI managerを使って問題なくSSL設定が可能という回答が得られています。

上述したように、Nginx環境では.htaccessが動作しません。
よってNginx環境ではnginx.confに.htaccessと同じような挙動をするように、confに作成する必要がありますが、ほとんど参考サイトがなく、Qiitaくらいしかないと思います。

ただ、移行元のWordpress環境の.htaccessに書いているのは、IP/ドメインの許可ホワイトリスト、IP/ドメインの拒否スパムリスト、301リダイレクト関連の主に三つなので、これだけなら何とかなりそうです。
nginx.confの書式調査については、Wordpressを構築した後で、ゆっくり取り掛かっても問題ないと思っています。

ConoHa VPS+KUSANAGI環境構築の難易度はどのくらいか？
実際にやってみて、コマンド等はそれほど難しくはありません。
自分の手順に照らし合わせて見ていきます。

【全体手順】
①ConoHa VPS申し込みしVPSサーバーを追加（契約）
②KUSANAGI初期設定
③KUSANAGIプロビジョニング
④一般ユーザー作成・SSH環境構築（鍵認証のため鍵ペア作成・初期ポート番号変更等）
⑤ファイアウォール設定
⑥仮想マシンへWordPressインストール
⑦WordPress環境復元（All-in-One WP Migration）
⑧ドメイン設定
⑨SSL化設定
⑩phpMyAdminインストール、Nginx設定（nginx.conf）phpMyAdmin設定関連、.htaccess移行関連

ConoHa VPS申し込みしVPSサーバーを追加はConoHa VPSにログインして管理画面上でサーバーを指定するだけです。
ConoHa VPSお申し込み方法

KUSANAGI初期設定とKUSANAGIプロビジョニングは、対話形式で自分の環境に合う選択肢を番号で指定するだけです。
KUSANAGIの初期設定
KUSANAGIのプロビジョニング

最初のアップデートコマンド二つは何の事か分からないと思いますが、Linux内の関連パッケージを最新にアップデートするためのコマンドです。
取り合えずこのまま入力すればいいと思います。

yum update kusanagi -y

実行後に「No packages marked for update」と出た場合は、

yum clean all

を実行して再度

yum update kusanagi -y

を実行します。また、

yum --enablerepo=remi,remi-php56 update -y

を実行して「No packages marked for update」と出た場合、アップデートすべきパッケージがない（既に最新化されている）という状態なので、次の手順に進んでいいと思います。
実際に自分も「No packages marked for update」と出ましたが特に問題なく進められています。

コマンドが「php56」とあるので、この部分も気になっていましたが、実際にアップデートコマンド後に確認するとphpバージョンは7.4になっていました。（移行元のConoHa WINGは2021年現在でphpバージョン7.4なので、出来れば同じ7.4環境が望ましいため。）

php -v
PHP 7.4.23 (cli) (built: Aug 31 2021 01:26:53) ( NTS )

コマンドを入力しての作業は、どちらかというとセキュリティ周りの作業が多くなります。
自分の作業手順で言うと「一般ユーザー作成・SSH環境構築（鍵認証のため鍵ペア作成・初期ポート番号変更等）」「ファイアウォール設定」
等です。

ConoHa VPS+KUSANAGI環境はLinux（CentOS）というOSで、Redhat等昔からあるLinuxと同じコマンド体系なので、大学や会社でLinuxのコマンド入力をしたことがある人にはそれほど難しくはないと思います。
自分は仕事で実サーバーや仮想マシンを構築経験があるので、特に難しく感じるところはありませんでした。
（実際のOSバージョンはCentOS7.9でした。）

cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

セキュリティ設定は、全くやらなくてもWordpress自体は作れます。
どの程度やるかは完全に個人の自由ですが、セキュリティ設定をしないとネットに丸裸でいるようなものなので、あっという間にポートスキャンされて蜂の巣にされるのでお奨めしません。
必ずセキュリティ設定を行ってから使うようにしましょう。
自分の構築手順でも、セキュリティ設定は出来るだけ早い段階でやるようにしています。

ユーザー作成、SSH設定、ファイアウォール設定などのコマンド作業は、全くLinuxを触ったことがないと難しく感じられるかもしれません。
が、ネット上に記事も多数あるので、その通りやれば特に難しくはないと思います。

ConoHa VPS環境では、基本的にファイルシステムやネットワーク、ルーティング等は変更しなくてもそのまま使えるので、普通の仮想環境や実サーバー環境よりも単純化されて作業も少なくて済みます。
ただ、全く初めての人が触る場合、Linuxにおける権限の概念、ユーザースイッチ、viやvimによるファイルの編集方法は知っておいたほうが良いです。
Linuxの初級者向け本を何でもいいので一冊読んでおくと、作業で詰まることが少ないと思います。

新しいLinuxの教科書

ユーザー作成やSSH設定をやる前後で、TeraTermの接続設定や、TTLマクロによる自動接続、WinSCPによるファイルの送受信なども設定しておけば、作業が楽になります。

仮想マシンへWordPressインストールは、対話入力で設定した内容をワードプレス画面に入力するだけです。
8時間目 WordPressをインストールしよう

WordPress環境復元は、All-in-One WP Migrationというプラグインを使います。プラグインの使い方は割愛しますが、エクスポートしてインポートで取り込むだけなので特に難しくはありません。
参考として、以下の記事にAll-in-One WP MigrationによるWordpress移行作業を実施しているので興味のある方はご覧下さい。
エックスサーバーからConoHa WINGへのWordPress移行手順を作成しました。（2019年版）【事前作業・問題解決・全画像有】※All-in-OneWP使用

ドメイン設定は、ConoHa VPSの管理画面でDNSレコードの編集でIPアドレスを自分の契約したVPS仮想マシンのIPアドレスに変更します。
同じく参考記事を掲載します。
エックスサーバーからConoHa WINGへのWordPress移行手順を作成しました。（2019年版）【事前作業・問題解決・全画像有】※All-in-OneWP使用

SSL化設定はKUSANAGI managerという管理画面から行います。
ご利用ガイドKUSANAGI manager

Nginx設定は、恐らくこの中では一番難易度が高いですが、喫緊の作業ではないので、調べながらやる予定です。​

追記：NginxでphpMyAdminが表示されずにはまりまくる

全体手順のうち①から⑤まで特に問題なく来ていて、ここでWordpress復元前に、Nginxの勉強を兼ねてphpMyAdminをインストールして、「ｈｔｔｐ://サーバーIP/phpMyAdmin/」でphpMyAdminログインページを表示させるようにしていた所、全く表示出来ず滅茶苦茶ハマりました。

phpMyAdminをyumインストールで入れる所は問題なかったが、Nginx側のconfにphpMyAdminをlocationで入れて「ｈｔｔｐ://サーバーIP/phpMyAdmin/」のようにブラウザから見られるようにする所が全く上手く行かなかった。

分かった事としては、
・本来、Nginxの挙動を制御しているはずの「/etc/nginx/conf.d/[プロファイル名]_http.conf」がNginxにデフォルトで見られていない。なので、幾ら[プロファイル名]_http.confにphpMyAdminのロケーション等を書いても無駄だった。

デフォルトで見られているのは/etc/nginx/conf.d/_http.confで、その記述は

location / {
       root   /usr/share/nginx/html;
       index  index.html index.htm;
}

のように、rootが /usr/share/nginx/htmlをデフォルトページとして見に行く設定になっている。
初期状態で表示されるのは「/usr/share/nginx/html/index.html」になっている。
なので、幾らブラウザに「ｈｔｔｐ://サーバーIP/phpMyAdmin/」を入れても/usr/share/nginx/html/配下にphpMyAdminディレクトリもないのでNot foundしか表示されない。

ブラウザ ｈｔｔｐ://サーバーIP
　　　　↑↓
デフォルトで読み込まれるファイル
/etc/nginx/conf.d/_http.conf
　　　　↑↓
_http.conf内記述
　location / {
　root /usr/share/nginx/html;}
　　　　↑↓
デフォルトで読み込まれるファイル
/usr/share/nginx/html/index.html
　　　　↑↓
index.html内記述（ようこそ画面）

<!DOCTYPE html>
<html>
<head><title>Welcome to nginx!</title></head>
<body>
<h1>Welcome to nginx!</h1>
・・・

この情報がネット上を探しても全く見つかなかったので、かなりハマる事になってしまった。
対策としては、/etc/nginx/conf.d/_http.confに、phpMyAdminのロケーションを含めてきちんとした書式で中身を書く。
こちらで書かれている記事を参考にさせて頂いていた。

KUSANAGI＋nginxでphpMyAdminを使いたいです！

編集した/etc/nginx/conf.d/_http.confの書式

#=======================================
# サーバー名
#---------------------------------------
server {
       listen 80;
       server_name ○○○.com www.○○○.com;
       access_log  /home/kusanagi/プロファイル名/log/nginx/access.log main;
       error_log   /home/kusanagi/プロファイル名/log/nginx/error.log warn;
       # rewrite ^(.*)$ https://○○○.com$uri permanent; # SSL ONLY
       # rewrite ^(.*)$ https://www.○○○.com$request_uri permanent; # SSL ONLY
       charset UTF-8;
       client_max_body_size 16M;
       root  /home/kusanagi/プロファイル名/DocumentRoot;
       index index.php index.html index.htm;
       location = /50x.html {
               return 403;
       }
・・・
#追加部分
       location /phpMyAdmin/ {
           alias /usr/share/phpMyAdmin/;
           try_files $uri $uri/ /index.php;
			allow 127.0.0.1;
			allow サーバー自身のNICのIP;
			allow 作業PCのIP;
			deny all;
           location ~ /phpMyAdmin(.+\.php)$ {
               fastcgi_pass    127.0.0.1:9000;
               fastcgi_index   index.php;
               fastcgi_param   SCRIPT_FILENAME  /usr/share/phpMyAdmin$1;
               include         fastcgi_params;
               fastcgi_buffers 256 128k;
               fastcgi_buffer_size 128k;
               fastcgi_intercept_errors on;
               fastcgi_read_timeout 120s;
           }
       }
#追加部分終了
       location ~ [^/]\.php(/|$) {
               fastcgi_split_path_info ^(.+?\.php)(/.*)$;
               if (!-f $document_root$fastcgi_script_name) {
                       return 404;
               }
・・・

・上記の/etc/nginx/conf.d/_http.confへの記述だけでは動作しないので、シンボリックリンクを作る。
_http.confの記述の中でドキュメントルートの指定を「/home/kusanagi/プロファイル名/DocumentRoot」と書いている。

ドキュメントルート（つまり/home/kusanagi/プロファイル名/DocumentRoot）に、「/usr/share/phpMyAdminへのシンボリックリンク」を作成してやる必要がある。
シンボリックリンクを作成しないと、「/home/kusanagi/プロファイル名/DocumentRoot/phpMyAdmin/を見に行ったが、該当ディレクトリがなかった」という判定をされてしまうため、シンボリックリンクを作る必要がある。

（調べていた時に、「/etc/nginx/conf.d/[プロファイル名]_http.conf」にちゃんと書けば動く派と、confに何も記述しなくてもシンボリックリンクを作成するだけで動く派の二つの記事に大きく対応が分かれていたので、非常に迷ったが、自分の場合は両方やる事で動作したが、[プロファイル名]_http.confではなく_http.confだったので、ネット上にこの対応で実装したという記事は恐らくないのではないか。）

シンボリックリンクには、念の為kusanagiの権限を付与する。
理由はドキュメントルート配下のファイル等には全てkusanagiの権限が付与されているため合わせたというだけ。

cd /home/kusanagi/プロファイル名/DocumentRoot
ln -s /usr/share/phpMyAdmin phpMyAdmin
chown -h kusanagi:kusanagi phpMyAdmin

・この状態でもまだエラーログにフォービッドンが出ていたので、権限かallow/deny系の設定が引っかかっているのだろうと思った。

/etc/nginx/conf.d/_http.confには、IPアドレス等の規制が.htaccessのようにallowやdenyで書けるのだが、以下のように書くとアクセスフォービッドンになってしまった。

フォービッドン書式

allow 127.0.0.1;
allow 作業PCのIP;
deny all;

ここに、サーバー自身のIPをallowに追加してやるとフォービッドンがなくなりアクセス可能になった。

サーバーのIPは「ip -a」で調べる。eth0にinet xxx.xxx.xxx.xxx/26みたいな表示が出るので、inet以下の数字の部分がIPアドレスになる。

本来は「allow 127.0.0.1」がループバックアドレスの事なので、自身からのアクセスの許可を表すはずなのだが、何故かアクセスが弾かれてしまっていた。

アクセスOK書式

allow 127.0.0.1;
allow サーバー自身のNICのIP;
allow 作業PCのIP;
deny all;

・ここまでで、phpMyAdminのページが表示出来る状態になっていたが、Chromeだとキャッシュを優先しているせいか、現在の表示が正しく行われず、「Wordpressようこそ画面」をリダイレクト表示したりしていた。

おかしいと思い、テキストブラウザLynxやFirefoxで見ると、きちんとphpMyAdminが表示されている状態になっていた。
正しい状態を見るには、LynxやFirefoxで見る方がいいようだ。

なお、ここまでで、phpMyAdmin側のconfやディレクトリ構造には一切手を加えていない。
全てNginx側だけの対応で表示させている。

ログを逐一見ることも必須。現在Not foundかフォービッドンになっているかだけでも状況が全然違うため、常にブラウザを叩いたらログをチェックする。
Nginxのログは/home/kusanagi/プロファイル名/log/nginxに出るようだ。/var/log/nginx/にも似たようなログが出るのだが、どちらが正しいのかは分かっていない。

ようやく表示されたphpMyAdminをFirefoxとLynxで表示させた所

ここまでVPS構築の感想

感想としては、難しいというよりも、ConoHa VPSのKUSANAGIからインストールした場合、Nginxが/etc/nginx/conf.d/_http.confを初期状態を見るという情報が全くなかったので、この先WordpressでNginxを運用していけるか不安になった。
WordpressはWebサーバーのNginxと密接に関連しているので、Nginxの理解なしではとても運用は出来ないと思う。
特に、ConoHaでは、Nginxは「単なるミドルウェアの一つ」の扱いなので、サポートへの回答も恐らく期待出来ない。
もし、ConoHa VPS＋KUSANAGIでWordpressの移行を検討している人がいたら、Nginxではこのようなハマリが多数あるという事を注意して欲しい。

_http.confは必要ないので削除可能だった

上記のようにNginxがデフォルトで/etc/nginx/conf.d/_http.confを見ているらしいのだが、nginx -tで書式を確かめるとコンフリクトになった。

$ sudo nginx -t
nginx: [warn] conflicting server name "○○○.com" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "www.○○○.com" on 0.0.0.0:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

そこで/etc/nginx/conf.d/プロファイル名_http.confに_http.confと全く同じ記述をした上で、/etc/nginx/conf.d/_http.confを削除しても、正常に動作した。_http.confを削除した後に、nginx -tでチェックするとコンフリクトが出なくなった。

結局、正しい手順としては、

①/etc/nginx/conf.d/_http.confはバックアップ取得した上で削除
②/etc/nginx/conf.d/プロファイル名_http.confに正しい記述をする
③ドキュメントルート（/home/kusanagi/プロファイル名/DocumentRoot/）に移動し、/usr/share/phpMyAdminへのシンボリックリンクを作成

だったようだ。

追記：ようやくワードプレス復元まで漕ぎ付ける

・php-fpm.serviceがずっとFailed
・/etc/php.iniを編集しても反映されない

の2件でかなりハマルかと思われたが、上に書いているようにあっさりクリア出来たので、助かった。先人の方たちの記事や情報が本当に助かっている。

「Wordpressをインストール」画面から、Wordpressを仮の状態で作成。
仮のWordpressにAll-in-One WP Migrationプラグインを入れて復元としようとしたが、「要求されたアクションを実行するには、WordpressがWebサーバーにアクセスする必要があります。」とメッセージが出る。
これはkusanagiのFAQにもある通り、kusanagiのパスワードを入力する事で事なきを得た。

改めてAll-in-One WP Migrationで移行元でエクスポートした～.wpressファイルをインポートしようとしたが、100％でインポートが止まってしまう。
結論から言うと原因は/etc/nginx/conf.d/[プロファイル名]_http.conf
のclient_max_body_sizeに対して.wpressファイルのサイズが大きすぎるため起きていた。client_max_body_sizeの値を200Mに修正して再度インポートした所問題なく完了した。

ようやくWordpressが表示されたが、移行元で使っていたLionMediaのテーマが壊れていると表示されてデフォルトテーマで表示された。

LionMediaの提供元のFITのサイトからテーマをダウンロードしてWordpressダッシュボードにアップロードし、改めてWordpressが表示。
まだ画像を入れていないが、ようやく移行元にかなり近い状態まで再現出来た。

多分ここまでで一番ハマッたのは本来入れなくてもいいphpMyAdminだっただろう。ただ、色々触ったため、kusanagi+Nignx環境に付いてかなり慣れてきた。

追記：kusanagi管理がエラーになる

移行元でダウンロードしておいた画像を入れたり、セキュリティ系の設定の細々とした設定を終えた後、Conohaダッシュボードのサーバーのkusanagi管理にアクセスすると
「このサイトにアクセスできません xxx.xxx.xxx.xxxからの応答時間が長すぎます。」と表示される。

プラグインを全て停止しても変わらなかった。
調べた所、こちらの記事の情報で、firewallを有効にしている場合、firewallの設定で60000ポートを開放しないとkusanagiマネージャーが使えないらしいと判明。

VPSサーバーにファイアウォールを導入しよう！ポート開放を最低限にしてセキュリティアップ！

以下のコマンドで60000ポートを有効にする。

$ sudo firewall-cmd --zone=public --add-port=60000/tcp --permanent

これでkusanagi管理にrootログイン出来るようになった。
（rootパスワードをネットに流さないようSSH認証させているのだが、平文のパスワードをネットに垂れ流して大丈夫なのだろうか？）という疑問はあった。

kusanagi管理にrootログインしたが、ステータスがエラー。
これはDNSレコードにドメインとVPSIPアドレスを設定付けていないせいだろうか？
ドメインはConoHa WING側のWordpressサイトで公開中なので、ドメインとVPSIPアドレスを設定付けるとネットから見てVPS側に一本化されてしまうので、DNSレコードの切り替えは最後にしようと思っていたが・・・。

追記：KUSANAGIキャッシュオフ時とキャッシュオン時のページスピード結果

KUSANAGIではキャッシュにfcacheとbcacheと2種類があり、これらのキャッシュオフ時とキャッシュオン時のページスピードを計測してみた。
計測サイトはpagespeed insightsを使用。
キャッシュコマンドは以下。

KUSANAGIコマンド | KUSANAGI

Conoha VPS　Wordpress計測
kusanagiキャッシュ：オフ
プラン：メモリ1GB　CPU2Core
モバイル　53
パソコン　72

kusanagiキャッシュ：オフ
プラン：メモリ2GB　CPU３Core
モバイル　53
パソコン　69

kusanagiキャッシュ：fcacheのみon
コマンド　kusanagi fcache on
プラン：メモリ1GB　CPU2Core
モバイル　61
パソコン　77

kusanagiキャッシュ：bcacheのみon
コマンド　kusanagi bcache on
プラン：メモリ1GB　CPU2Core
モバイル　55
パソコン　71

kusanagiキャッシュ：fcacheとbcache両方on
プラン：メモリ1GB　CPU2Core
モバイル　64
パソコン　75

kusanagiキャッシュ：fcacheとbcache両方on
プラン：メモリ2GB　CPU3Core
モバイル　51
パソコン　80

比較参考にConoHa WINGでの計測。

ConoHa WINGで運用中のWordpressの速度
プラン：リザーブド1GB　メモリ1GB/CPU 2Core
モバイル　39
パソコン　52

ConoHa WING
プラン：ベーシックプラン　メモリ1GB/CPU 2Core
モバイル　39
パソコン　54

結果
KUSANAGIでもモバイル50台という壊滅的な遅さ。
トップページにnoteのRSS読み込みとか色々余計な負荷を掛けている事、画像が重過ぎる事等が原因だろう。
キャッシュを使うと確かに少し数値は上がる。
メモリ1GB⇒2GBは数値的にはほとんど効果がない。
ただ、体感的にはモバイルも60台でも、これまで遅かったため物凄く速く感じる。
計測してみて、KUSANAGIにする意味はあると思った。
パフォーマンスを引き出すならキャッシュオンでメモリは2GB以上にはするべきだと思う。

注意事項

個人が自分の考えで書いたものです。必ずしも内容が正しいとは限りません。
読まれる際はご理解をお願いします。

シリーズ一覧

WordPressでは書けないブログ運営論｜G@MERZ:NOTE｜note