ワードプレスをConoHaVPS+KUSANAGIに移行してみた感想(WordPressでは書けないブログ運営論#26)
以前書いていた通りレンタルサーバー(ConoHa WING)で運用しているワードプレスをVPS(ConoHa VPS)に移設しました。
移行先ワードプレスはドメイン同じなので、同じURLです。
VPSワードプレスは一応普通に見られるようになったので、WINGのワードプレスはベーシック認証と検索回避をかけてネットから見られないようにしました。
前回の記事と重なりますが、移行直後のタイミングで改めてワードプレスのVPS変更について作業内容や難易度など思った事を書きます。
作業者(自分)のスキル
ワードプレス運営:2017年以降約4年
LinuxOS・サーバー設定:講義や仕事でRHELや他のUnixOSの設定経験あり
ネットワーク・セキュリティ:簡単なLANの構築程度の知識
「Linuxやサーバー経験あるなら簡単でしょ」と思われるかもしれないが、難しいというか、ハマった時にどうやって解消するかを調べたり、試行錯誤するのが大変だった印象。
料金
プランが1GBCPU2コアで割引きっぷにより700円台まで下がる。
実用的な2GB~4GBで3000円以下なので、相場からすると十分許容範囲だと思う。
ConoHa WINGのワードプレスも利用中はVPSとは別に料金が懸かっているので、VPSでいくかWINGに戻るかは早急に決断したい所。
ワードプレス速度(2021/09/13)
移行して速度がどのくらいになったかをPageSpeed Insightsで計測。
現行ワードプレスの速度(ConoHa WING)
・プラン:リザーブド1GB メモリ1GB/CPU2Core
モバイル 39/パソコン 52
・プラン:ベーシックプラン メモリ1GB/CPU2Core
モバイル 39/パソコン 54
ConoHa WINGの場合はプランをリザーブドでもベーシックでも変わらなかった。なお、ベーシックプランとリザーブドプランの間の変更で、サーバーも変わるので、同居ドメインが多い人は、プランを変更して強引にサーバーを変えるのも可能。
VPS移行後ワードプレスの速度(ConoHa VPS)
・プラン:メモリ1GB/CPU2Core
モバイル 50/パソコン 56
(kusanagiキャッシュ:fcacheのみon)
数値的にはそれほど変わっていないが、元がモバイル30台と遅かったので、体感的にかなり速くなっている。
VPSでは、ワードプレスダッシュボードは驚くほど高速に表示される。
モバイルでは、レンサバのこれまでは数秒待つため遅過ぎる感じだったが、VPSワードプレスではストレスがギリギリないくらいの表示速度だった。
VPSはKUSANAGIという超高速ワードプレス専用環境で、キャッシュはfcacheとbcacheの2種類があるが、bcacheはレイアウト崩れが出るという情報があったので、fcacheのみ有効にしている。
また、メモリはほぼ最低クラスの1GBでもこれだけ出ているので、2GB、4GBとスペックアップの道もある。
速度改善はまずまず達成したと言っていいと思う。
追記(2021/09/21)
VPS移行後ワードプレスの速度(ConoHa VPS)
・プラン:メモリ2GB/CPU3Core
モバイル 63/パソコン 91
(kusanagiキャッシュ:fcacheのみon)
色々やって速度は大分改善してきた。
尤も、PageSpeed Insightsがずっと403エラーになり、原因不明だった。
対応にかなり苦慮していたが、ようやく解消したので速度を計測する事が出来た。
GTmetrixもまずまずの数値が出ている。
ワードプレス速度(2022/06/22)
移行後約9ヶ月後の速度をPageSpeed Insightsで計測。
久しぶりに計測するとPageSpeed Insights自体の画面やUIが大きく変わっていた。以前より見やすくなっている。
計測結果はトップページは非常に早いがモバイルの個別記事の速度が遅い状態になっている。
自分の記事は画像を沢山使っているので仕方ない面はある。
VPS移行後ワードプレスの速度(ConoHa VPS)
・プラン: メモリ 1GB/CPU 2Core
サイトトップ(https://varis.jp/)(PCブラウザ)
個別記事(https://varis.jp/gamereview-wizardry-thefiveordeals/)(PCブラウザ)
サイトトップ(https://varis.jp/)(モバイル)
個別記事(https://varis.jp/gamereview-wizardry-thefiveordeals/)(モバイル)
作業工程
以下に作業中のメモ等をしていたが、作業の後半でかなりハマりが多かった。
全体工程
全体の工程は以下のようになっている。
まず移行元となるConoHa WING現行サイトでAll-in-one WP Migrationプラグインでのエクスポート等を行う。
次に移行先となるConoHa VPSでサーバー契約し作業PC側にSSH認証等の接続環境を作りながら、KUSANAGIコマンドでOS初期設定とプロビジョニングを実施。
ワードプレスの入れ物が出来るので、そこにAll-in-one WP Migrationでエクスポートしたファイルをインポートしてワードプレス復元させる。
後はエラーが出たら逐一潰していく。
単純化して書いているが、実際にはかなり面倒だった。
ConoHa WINGワードプレス(移行元サイト)事前準備
1.ConoHa WING管理画面でPHPのサイズアップロード上限を上げる
2.キャッシュ系プラグインを停止
3.All-in-one WP Migrationでエクスポート
移行のポイントはAll-in-one WP Migrationプラグインでのエクスポート・インポートだが、エクスポート時にファイル上限に引っ掛からないよう、予めPHPのサイズ上限を上げておく。
ConoHa WING管理画面でPHPの設定が出来るので、そこでPHPの値を変更する。
その後、All-in-one WP Migrationをインストール・有効化し、エクスポートで移行元の情報を抜いておく。
PHPサイズ設定やAll-in-one WP Migrationのエクスポート方法は拙サイトに書いたものがあるので宜しければ参照頂ければと思う。
ConoHa VPS移行作業①VPS申し込み
ConoHa VPS会員アカウントがない場合は新規登録してから行う。
会員アカウントがある場合はConoHaにログインし左上のVPSをクリック。
サーバーの画面になるので「追加」をクリックするとVPSに申し込みしVPSサーバーを追加画面になる。
VPSサーバーのスペックを指定する。
後でスケールアップするなら必ず1GB以上のプランを選択しておく。
オプションの項目でrootユーザーのSSH秘密鍵もダウンロード出来る。
ConoHa VPS移行作業②KUSANAGI初期設定とKUSANAGIプロビジョニング
サーバーが作成されるので、ネームタグのvps~をクリックする。
以下のようにVPSサーバーを操作する画面になる。
ここからVPS起動やシャットダウン、イメージ保存などが行える。
コンソールを押すと、ブラウザ上でCentOSにログイン出来るが、コンソールは使い辛いことやログが残らないことから、基本は使わない。
なので、Tera TermでSSH認証してログインするのが基本の接続にする。
Tera Termにはログ保存設定をしておく。
(VPSサーバー追加時にSSH鍵ファイル(~.pemファイル)をダウンロードするのでその鍵ファイルを使用して接続する。)
Tera Termを立ち上げ、ホストにVPSのIPアドレス、TCPポート番号に22、SSHバージョンにSSH2を指定してOKを押す。
以下の画面でユーザーにroot、パスフレーズなし、RSA/DSA/ECDSA/ED25519鍵を使うにチェックを入れ、右端の[…]を押して先ほどダウンロードしたrootの秘密鍵を指定してOKを押す。
ログインすると以下のようにKUSANAGIのロゴが表示される。
当面はこのやり方でログインし、KUSANAGIの公式ドキュメントに従って必要なコマンドを打って設定する。
この辺りの手順が難しいという人は、記事末の参考サイト様の記事やQiitaの記事を見て頂ければ分かりやすいと思う。
KUSANAGIドキュメント
以下の手順に従ってKUSANAGIの初期設定とKUSANAGIのプロビジョニングを実行する。
KUSANAGIの初期設定
KUSANAGIのプロビジョニング
# yum update kusanagi -y
# yum clean all
# yum update kusanagi -y
# yum --enablerepo=remi,remi-php56 update -y
# reboot
# kusanagi init
対話形式で設定
# kusanagi provision プロファイル名
対話形式で設定
コマンド実行時の注意点
・WebサーバーはApacheとNginxが選べるが、Nginxを指定する。
・ユーザーkusanagi のSSHユーザ鍵の作成では、必ずフレーズ文字列を入力する。
フレーズ文字を指定せず空欄(空Enter)の場合、WinSCPでPuTTYgenからpemファイルをロードしてpkkファイルを作成する時に、エラーになってpkkファイルが作成出来なかった。
終わったら、ConoHa VPSの管理画面から、イメージ保存しておく。
サーバーをシャットダウンするとイメージ保存が可能になる。
イメージ保存後は再度サーバーを起動する。
この後もある段階まで作業が進んだら、サーバーイメージを保存しておくと、後からやり直す事になっても、一瞬で保存時の状態まで戻せる。
ConoHa VPS移行作業③一般ユーザー作成・SSH環境構築(鍵認証のため鍵ペア作成・初期ポート番号変更等)、hostsファイルの設定
先ほどまで、rootユーザーでSSH鍵を使って接続しているが、本来はセキュリティ的にrootは直接ログインせず別のユーザーで接続するのが正しい運用となるため、この段階で「作業用のユーザー」を作成しておく。
が、ここでは詳しい手順は掲載していない。
手順は一般的なLinuxやCentOSでのユーザー作成、SSH鍵認証設定、初期ポート番号変更と全く同じなので割愛した。
詳細が知りたいという方は記事末の参考サイト様の記事を参照頂ければと思う。
後は、先ほども書いたがQiitaの記事も参考にすべきだろう。
Qiitaの検索でVPSやKUSANAGIの記事でヒットするものは全て見ておくくらいがいい。
例えば、以下のQiitaの記事は一通りの流れが書かれているのでConoHa VPSの設定の参考になる。ただ、iptablesなど2021年時点では古い情報も載っているので、その辺りは自分で読み替える必要がある。
hostsファイルは、この時点でWINGワードプレス環境、VPSワードプレス環境があるので、ドメイン変更後に合わせて、各環境のhostsファイルを用意しておく。
記述例
111.111.999.999 test1234567890.info
111.111.999.999 www.test1234567890.info
ConoHa VPS移行作業④ワンクリック接続用Tera Termマクロ作成
Tera Termで接続する毎に毎回鍵ファイルを指定して~とやると面倒なので、ワンクリックで接続出来るようにTera Termマクロを作成する。
書式は幾つかあるが、マクロといっても定型の書式にユーザーとIPアドレスを指定するくらいで特に難しくはない。
もし作成手順が分からないという方は、「Tera Termマクロ」で検索すると手順が出てくると思うので、それを参考に作成して頂きたい。
ConoHa VPS移行作業⑤ファイアウォール設定
VPSサーバーはグローバルIPを与えられて裸同然でネットに放り出されるので、ファイアウォールを設定しないと絶え間なくアタックされ続けてしまう。そのため早い段階でファイアウォール設定を行っておきたい。
なお、kusanagiマネージャーを使うためファイアウォール設定で60000ポートを解放する必要がある。
設定例
# firewall-cmd --add-service=http
# firewall-cmd --add-service=https
# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=public --add-service=https
ConoHa VPS移行作業⑥phpMyAdminのインストールと設定
phpMyAdminは、特にインストールしなくてもワードプレス自体は動作するが、あれば便利なので入れておく。
リポジトリからphpMyAdminをインストール
# yum install --enablerepo=remi,remi-php74 phpMyAdmin
/etc/nginx/conf.d/プロファイル名_http.confにphpMyAdmin用のロケーションを追加する。
allowにVPSサーバーIP、作業用PCのIPを追記しておく。
設定例
# vi /etc/nginx/conf.d/プロファイル名_http.conf
location ^~/phpMyAdmin/ {
alias /usr/share/phpMyAdmin/;
try_files $uri $uri/ /index.php;
allow 127.0.0.1;
allow VPSサーバーの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;
}
}
# systemctl reload nginx.service
/home/kusanagi/プロファイル名/DocumentRoot/に、phpMyAdminの本体がある/usr/share/phpMyAdmin/へのシンボリックリンクを作る。
# cd /home/kusanagi/プロファイル名/DocumentRoot
# ln -s /usr/share/phpMyAdmin phpMyAdmin
# chown -h kusanagi:kusanagi phpMyAdmin
ConoHa VPS移行作業⑦ConoHa VPS側のPHPとNginxのサイズアップロード上限を上げる
/etc/php7.d/php.iniを編集してサイズ上限を上げる。
移行作業後は元の値に戻しておく。
設定例
# vi /etc/php7.d/php.ini
max_execution_time = 240
max_input_time = 120
memory_limit = 256M
post_max_size = 650M
upload_max_filesize = 600M
# kusanagi restart
ConoHa VPS移行作業⑧ワードプレスインストール
ここまでで、ワードプレスを作る準備は出来ているので、実際にワードプレスインストールを進めていく。といっても、一瞬で終わる。
ブラウザにVPSサーバーのIPアドレスを入力し以下の画面を出す。
さあ、始めましょう!をクリック
データベース名、ユーザー名、パスワード、データベースのホスト名、テーブル接頭辞を入力。
ここで入力した情報は後でインポートに移行元サイトの内容に上書きされるので、画面に入力したものは意味がないが、初回の入力にのみ使うので、ユーザー名とパスワードは控えておく。
データベースのホスト名はlocalhostと入力。
送信をクリック。
インストール実行をクリック。
ようこそ画面になる。
サイトのタイトルは適当に入力。
ユーザー名とパスワードは先ほど設定した物でログイン。
但し、インポートで復元後は移行元サイトのユーザー名とパスワードに上書きされるので、注意。
メールアドレスは使っているアドレスを適当に入力。
Wordpressをインストールをクリック。
成功しました!と出ればワードプレスの作成が完了。ログインをクリック。
先ほど設定したユーザー名とパスワードでワードプレスダッシュボードにログインする。
ConoHa VPS移行作業⑨ワードプレス復元
今ログインしているワードプレスは復元させるためのただの入れ物に過ぎない。
ワードプレスの復元を進めていく。
まずは、プラグインを押してAll-in-One WP Migrationプラグインをインストール・有効化し、ConoHa WINGでエクスポートしたファイルをインポートして移行元のワードプレスを復元する。
プラグインやテーマの操作で、「要求されたアクションを実行するには、WordPress が Web サーバーにアクセスする必要があります。」と表示される場合は、kusanagiユーザーのパスワードを入力する。
参考
Q3. WordPress の管理画面からプラグイン・テーマの追加や、WordPress 本体またはプラグインの更新を行おうとしたところ、FTP 接続情報を要求されます。
A3. KUSANAGI では、セキュリティ対策のため各ディレクトリのアクセス権限等に制限をかけているため、プラグイン・テーマ等の追加や各種更新を行う際に FTP の接続情報を要求されます。
以下のように接続情報を入力することで、作業を続行できます。
ホスト名:localhost
ユーザー名:kusanagi
パスワード:[インストール時に設定したユーザー「kusanagi」のパスワード]
(出展:https://kusanagi.tokyo/faq/)
画像も移行元のWING側からダウンロードしておいたものをVPS側にアップロードする。
画像のアップロードについてはWinSCPを使って行う。
以下を参考にWinSCPを設定してVPSサーバーに画像ファイルをアップロードする。
ご利用ガイドSFTPを使ってファイルをアップロードする(WinSCP編)
この時、WINGでは
/public_html/ドメイン/wp-content/uploads/
が画像の場所になっているが、
VPSでは
/home/kusanagi/プロファイル名/Documentroot/wp-content/uploads/
になっているので注意。
⑩DNSレコード変更
ConoHa VPS管理画面にログインし、独自ドメインのDNSレコードを変更する。
変更前
ConoHa WINGサーバーのIPアドレス
↓
変更後
ConoHa VPSサーバーIPアドレス
変えるのは@のアドレスとwwwのアドレスの2ヶ所。
ConoHa WINGのワードプレスはドメイン管理会社登録ドメインを参照しており、ドメイン管理会社ではConoHa NSサーバー(ns-a1.conoha.io)を参照するようにしている。
なので、元々ConoHa側にもDNSレコードがある状態で、今回はWINGのサーバーIPからVPSのサーバーIPにレコードを変更するだけで切り替えが完了する。
変更前
ドメイン会社ーーConoHa NSーーConoHa DNSーーConoHa WING IP
変更後
ドメイン会社ーーConoHa NSーーConoHa DNSーーConoHa VPS IP
※レコード変更により公開サイトがWING側からVPS側へ切り替わる。
※この後ドメイン浸透時間あり。hostsを切り替える事でWING側とVPS側双方が見えるようにする。
設定例
変更前
タイプ 名称 TTL 値 編集
A(通常) @ 3600 111.111.888.888
A(通常) mail 3600 777.777.777.777
A(通常) ml-cp 3600 777.777.777.777
A(通常) www 3600 111.111.888.888
(中略)
変更後
@とwwwの部分のIPをVPSのIPアドレスに変更
タイプ 名称 TTL 値 編集
A(通常) @ 3600 111.111.999.999
A(通常) mail 3600 777.777.777.777
A(通常) ml-cp 3600 777.777.777.777
A(通常) www 3600 111.111.999.999
(中略)
ConoHa VPS移行作業⑪サイトSSL化
kusanagiコマンドによりSSL化実施と、SSL証明書の自動更新設定をする。
SSLの証明局は自動的にLet's Encryptになる。
SSL化はコマンドを数行打つだけで完了する。プロファイル名は最初のプロビジョニングで設定したプロファイル名を入力する。
SSL化コマンドを入力する。
# kusanagi ssl --email 自分のメールアドレス プロファイル名
以下のようなメッセージが延々と出てくるので確認する。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Account registered.
Requesting a certificate for ドメイン名 and www.ドメイン名
Performing the following challenges:
http-01 challenge for ドメイン名
http-01 challenge for www.ドメイン名
Using the webroot path /home/kusanagi/プロファイル名/DocumentRoot for all unmatched domains.
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/ドメイン名/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/ドメイン名/privkey.pem
Your certificate will expire on 2021-12-11. To obtain a new or
tweaked version of this certificate in the future, simply run
certbot again. To non-interactively renew *all* of your
certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Enabling auto renewal certificate
Modified nginx/httpd config files and restart.
Done.
You have new mail in /var/spool/mail/root
証明書の自動更新を有効化するコマンドを入力する。
# kusanagi ssl --auto on
以下のような表示が出ればOK。
Auto renewal certificate is already enabled. Nothing to do.
Done.
ConoHa VPS移行作業⑫http⇒httpsの恒久リダイレクト設定、Let’s Encript関連確認
kusanagiコマンドにより、httpからhttpsへの恒久リダイレクト設定を行う。ほか、Let’s Encript設定関連周りの確認もしておく。
# kusanagi ssl --https redirect プロファイル名
以下のようなメッセージが出ればOK。
Set redirect all traffic on varis.jp to HTTPS.(Permanently)
Modified nginx/httpd config files and restart.
Done.
You have new mail in /var/spool/mail/root
NginxとKUSANAGIを再起動する。
# systemctl restart nginx.service
# kusanagi restart
ssl.confがletsencryptデイレクトリ内の対象ドメイン名とプライベートキーになっている事を確認する。
ssl_certificateは以下のディレクトリにある事。
/etc/letsencrypt/live/xxx.yyy.com/fullchain.pem;
ssl_certificate_keyは以下のディレクトリにある事。
/etc/letsencrypt/live/xxx.yyy.com/privkey.pem;
/etc/letsencrypt/live/ドメイン名ディレクトリ配下が以下となっている事を確認。
fullchain.pem -> ../../archive/ドメイン名/fullchain1.pem
privkey.pem -> ../../archive/ドメイン名/privkey1.pem
Let’s Encriptは3ヶ月で期限が切れてしまうため証明書の自動更新設定がされているかをcrontabで確認。
update certとなっていればOK。
# crontab -l
07 03 * * 0 /usr/bin/kusanagi update cert
ConoHa VPS移行作業⑬WordPressアドレスの変更
WordPressアドレスを「http://ドメイン」から「https://ドメイン」に変更する。
※ワードプレスダッシュボードの設定>一般設定
これをしないとサイト表示がIPアドレスになったりと安定しないため必須。
ConoHa VPS移行作業⑭yum updateとkusanagi restart実行
DNSレコード変更から、数時間経過してもブラウザの表示がhttpとhttpsで安定しなかったため実行した。
yum update後に/etc/nginx/conf.d/_http.confや_ssl.confが復活するので、削除するかリネームする。
# yum update
# kusanagi restart
ConoHa VPS移行作業⑮リダイレクト系の処理追加
/etc/nginx/conf.d/プロファイル名_http.confに、httpsに301リダイレクトする処理を追記する。
本来不要かもしれない。
# vi /etc/nginx/conf.d/プロファイル名_http.conf
return 301 https://$host$request_uri;
# nginx -t
# nginx -s reload
kusanagiのhstsを有効化した。
# kusanagi ssl --hsts on
ConoHa VPS移行作業⑯トップページのレイアウト崩れ対応
トップページが型崩れしていてソースを見るとドメインの部分がIPアドレスになっていた。
サイトアドレスを「http://IPアドレス」から「https://ドメイン」に変更することで型崩れが治った。
※ワードプレスダッシュボードの設定>一般設定
ConoHa VPS移行作業⑰<a href="http://IPアドレス">などの対応
記事などのURLの記述が<a href="http://IPアドレス">や<url="http://IPアドレス">になっていた。
本来、
<a href="https://ドメイン">
<url="https://ドメイン">
の形になっていなければいけない。
これの原因は、ワードプレス復元前にワードプレスアドレスやサイトアドレスをドメインにしないまま、復元を行ってしまったので元の情報が残っているためと思う。自分でもこの辺りの手順がはっきりしないので、こうした状態になってしまった。
修正は、ワードプレス全体に一律で文字列を置換する方向で行う。
本来、この手の文字列修正は、Search Regex(プラグイン)で行うのが一般的だが、「ワードプレスでは文字列長等のシリアル情報を保持しているため、Search Replace DBで変更する方が無難」という情報が多くあったので、Search Replace DBを使って修正することにした。
Search Replace DBをインストールして「https://ドメイン」の形に修正する。
Search Replace DBのサイトからzipをダウンロードしてWinSCPでVPSに設置。
ブラウザで「http://ドメイン/Search-Replace-DB-master/」にアクセスして置換前と置換後の文字列を入力してリプレースする。
Search Replace DBについて詳しく知りたい方は「Search Replace DB」で検索すると情報が沢山出てくるのでそちらを参考して頂きたい。
ConoHa VPS移行作業⑱VPS側ワードプレスの検索回避設定解除、広告表示設定(ads.txt設置、広告系ウィジェット設置)
ConoHa VPSを公開ワードプレスとして使うための準備をする。
ワードプレスのダッシュボードから検索回避設定を解除する、(広告を使っている場合)ウィジェットの広告表示設定やads.txtの設置等を行う。
ConoHa VPS移行作業⑲Nginx設定(nginx.conf)
ConoHa WINGでは、.htaccessというファイルにGoogleボット等のユーザーエージェント許可、国内IPレンジの許可、スパムIPの拒否を設定していて便利だったのだが、Nginxでは.htaccessを使えない。
(実際には使えるようだが、レンサバのような単純な使い方は出来ない。)
そのため、Nginxのconfファイルに、似たような制御をさせるような仕組みを作る。
が、「単純移行のやり方を書いたサイト」がなく、結局Nginxの書式をある程度理解しないと書けそうもなかった。
幸い、$http_user_agentという変数に各種エージェントを羅列してリターンコード403を返すというやり方を載せている海外のサイトがあったので、リターンコードを200にする事でやりたい事が出来るのではと思って、やってみた。
/etc/nginx/conf.d/プロファイル名_http.confとプロファイル名_ssl.confに以下を記述する。location / とtry_files $uriの間あたりに書く。
# 許可エージェントリストにHTTPステータスコード200を返す
if ($http_user_agent ~* (google|Googlebot|Mediapartners-Google|Google-Site-Verification|bingbot|msnbot|Slurp|Y!J|archive.org_bot|Applebot) ) {
return 200;
}
# 日本国内許可IPアドレスリスト
include /etc/nginx/conf.d/nginx_ip_allow.conf;
nginx_ip_allow.confには以下のような感じで書く。
# 日本国内許可IPアドレスリスト
#
allow 1.0.16.0/20;
allow 1.0.64.0/18;
略
deny all;
allow IP:で国内のIPレンジを全て許可を書いていき、最下行にdeny all;とすれば後は弾かれるはず。
順番的には、以下を想定。
①location /にアクセスが来る
②http_user_agentに書いてあるユーザーエージェントからのアクセスにはステータスコード200が返る
③nginx_ip_allow.confのIPリストがチェックされ、allowのIPアドレスから来たアクセス(=国内IPレンジ)は許可される
④allowのIPアドレス以外からのアクセス(=海外からのアクセス)は拒否される
先にユーザーエージェントを許可した上でIPレンジという順番にしないと、ユーザーエージェントがアメリカ等国外から来ていた場合、deny allで弾かれるかもしれないと思ったためだ。
conf変更後は以下を実行して反映させる。
# nginx -t
# systemctl reload nginx.service
# systemctl restart nginx.service
このやり方で合っている保証はないが、ログを見ると
>国外からのアクセスは「access forbidden by rule」
>Googleなどの許可エージェントはステータスコード200
>国内IPレンジからのアクセスはステータスコード200
となっていたので、今のところ問題ないかもしれない。
もしWAF(ファイアウォール)でホワイトリストとブラックリストが制御してくれれば一番いいが、ConoHa VPSのWAFは有料になっている。
何れにしろ物凄い数のスパムアクセスが来ているので、何らかの対応をした方がいい。
追記:
が、この運用(許可エージェントと許可IPを許可するやり方)は結局やめて、拒否IPリストをdenyするやり方に変えた。
ConoHa VPS移行作業⑳その他の設定
その他、上記以外にやった事。
・BBQ Firewall Plugin導入
・Async JavaScript Plugin導入
・Invisible reCAPTCHA Plugin導入
・SiteGuard WP Plugin導入
・Imsanity Plugin導入
・Logwatch(ログ解析・整形)導入
・Logwatchのメール送信間隔を週に一度に変更
(参考 https://ngyuki.hatenablog.com/entry/20111129/p1)
・WP-Optimize Plugin(DB最適化)導入
・xmlrpc無効化
・wp-config.phpにメモリーリミット拡張記述を追加
・Wordfence Security Plugin削除後に大量に不要テーブルが残っているため削除(phpMyAdminでテーブル削除)
・テーマやプラグインの変更時にkusanagiパスワードを聞かれないためにwp-config.phpを変更
(参考 https://ygkb.jp/5883)
・ログインページにアタックしてくるIPをNginxで規制(SiteGuard WPのログイン失敗履歴を元にアタックIPを抽出)
(参考 https://memo.appri.me/TanakaSoftwareLab/nginx-ip-address-block)
・Autoptimizeのcacheフォルダを777権限にする、「インラインの JS も連結
Autoptimize に HTML からも JS を抽出させる (Autoptimize のキャッシュサイズが急激に大きくなる可能性があるため推奨しない)」はループが発生するのでチェック無し。
・アドセンス広告の遅延読み込み対応
(参考 https://blog-bootcamp.jp/start/adsense-lazyload/)
ConoHa WING(移行元サイト)閉鎖準備
1.ads.txt削除
2.広告系ウィジェットを外す
3.検索回避設定
4.ConoHa WING管理画面からサイトにベーシック認証をかける
5.ConoHa VPS側が問題なさそうならWINGのサーバーを削除
サーチコンソールとアナリティクスの確認
サイトを移行後は、Googleサーチコンソール(Google Search Console)とGoogle アナリティクスを念のためチェックしておく。
サーチコンソールは、カバレッジとサイトマップをチェックしておく。
カバレッジでエラーになっているものがあったらチェックしてURL検査などをしておく。
サイトマップは、直近でステータスが送信成功になっている事を確認する。
サイトマップが送信成功にならない場合、原因を調査する。
Google アナリティクスは、サイト移行前・移行後も同じGoogle アナリティクスのトラッキングIDを設定しているはずなので、旧サイトを閉鎖後も、きちんとビューやセッションのカウントが取れている事を確認する。
基本的にサーチコンソール、アナリティクスとも新しい設定をする必要はなく、移行前と同様に動いている事が確認出来れば問題ない。
なお、ワードプレスを使っていて、google search consoleとGoogle アナリティクスを使っていなかった人は、必ず使う設定をしておくべきだ。
ここでは基本的な設定方法等は記さない。検索で詳しい情報が出てくるので、そちらを見て頂きたい。
VPS構築後に発生した問題
ConoHa VPSにワードプレスを移行後、様々な問題が出たが、その一部を紹介する。
投稿した後記事を修正して、スマホで見ると修正が反映されていない(解消済み)
キャッシュが原因。以下のコマンドを打って反映させる。
$ sudo kusanagi fcache clear
kusanagi管理がアクセス出来ない(解消済み)
Conohaダッシュボードのkusanagi管理にアクセスすると「このサイトにアクセスできません」と表示された。
これは、CentOS7のfirewalldの設定で60000ポートを開放しないとkusanagiマネージャーが使えないのが原因だった。
以下のようにポートを開放する。
$ sudo firewall-cmd --zone=public --add-port=60000/tcp --permanent
$ sudo firewall-cmd --reload
$ sudo restart firewalld.service
kusanagi管理でドメインのステータスがエラー(未解決)
Conohaダッシュボードのkusanagi管理にアクセスし、ベーシック認証でrootパスワードでログインすると、ドメインのステータスがエラーになっていた。
これについてはサポートに問い合わせ、ジャーナルログを送って見てもらったが、原因不明ということで解決しなかった。根本解決を目指すなら、他のVPSサーバーに移るしかないだろう。
ただ、kusanagi managerについては、KUSANAGIの動作をConoHaで用意した画面で同じ機能をGUIで操作出来る、というだけなのでコマンドでやりたい操作が実現出来ていれば問題ないらしい。
data-vocabulary.org スキーマのサポートは終了しますエラー(解消済み)
サーチコンソールからメールで「パンくずリスト問題が検出されました data-vocabulary.org スキーマのサポートは終了します」のエラーが発生と指摘された。
以前対応してschema.orgに修正したが、Lionmediaの親テーマが壊れていて入れ直したので、functions.phpも修正版から修正されていない内容に戻ってしまったのが原因だった。
対応としては、ConoHa WINGワードプレスで対応したLionmedia親テーマのfunctions.phpをConoHa VPSのLionmedia親テーマのfunctions.phpに上書きした。
以前対応した内容
Pz-Linkcardプラグインでスタイルシートの生成に失敗しましたエラー(未解決)
ブログカードプラグインのPz-Linkcardで、これまでConoHa WINGワードプレスでは何の問題もなく使えていたが、ConoHa VPSに変更してエラーが出るようになった。
Pz-Linkcardの書式設定の変更で「スタイルシートの生成に失敗しました。」と出る。
権限等を色々変更してみたが、直らない。
が、書式の設定変更自体は反映されているようなので、根本解決は出来ていないが様子見。
PageSpeed InsightsがLighthouse returned error(解消済み)
VPSに移行し、どこかのタイミングから、ワードプレス計測サイトのPageSpeed Insightsがエラーになり計測が出来なくなった。
エラーメッセージは「Lighthouse returned error:FAILED_DOCUMENT_REQUEST. リクエストしたページをLighthouse で正確に読み込めませんでした。」
原因は不明。
プラグイン無効化、海外アクセス拒否の解除など試せる事は全て試したが、直らなかった。
使っていないであろう.htaccessもコメントアウトしたが変わらない。
対策として行ったこの二つのどちらかが効いて直ったと思われる。
■対策1.ワードプレスダッシュボードの設定>パーマリンク設定で何も変更せずに保存
■対策2.kusanagiのキャッシュクリア
サーチコンソールの画面で「サイトマップを読み込めませんでした」エラー(解消済み)
サーチコンソールもConoHa WINGワードプレスでは問題なく使えていたが、ConoHa VPSに変更して「サイトマップを読み込めませんでした」が表示された。
これについては以下の二つを対策して、現在様子見。
一応、手動でサーチコンソールを送信すると更新されるので、恐らく解消したと思われる。
■対策1.ワードプレスダッシュボードの設定>パーマリンク設定で何も変更せずに保存
■対策2.サーチコンソールに登録されているサイトマップを一つ以外全て削除
投稿記事の編集から「メディアを追加」で画像ファイルをアップロードすると「ファイルをwp-content/uploads/xxxx/xxに移動できませんでした。」と言われてアップロードが出来ない。(解消済み)
ConoHa WINGでは出たことがないエラーで焦ったが、結局、画像ファイルが入っている「wp-content/uploads/xxxx/xx」フォルダの権限が775で弾かれていただけ。権限を777に変更すると画像ファイルをアップロード出来た。
作業の難易度
手順に書いた事は全てKUSANAGIの公式ドキュメントや、ネットで実際に構築した方たちの記事があるので、情報はある。
後は、自分の環境に合わせて実施出来るかどうかだが、Linuxでのサーバー設定経験がなく全くのゼロからだと、少し難しく感じるかもしれない。
大半は、/etc/nginx/conf.d/プロファイル名_http.confや_ssl.confの設定ミス、または、所有者やパーミッション系のエラーなので、ポイントが絞られている。
ConoHa VPSにはイメージ保存機能があるので、ここまでは作業完了してイメージ保存、という事が出来る。最悪、イメージ保存のポイントまでは復元出来るので、思い切った変更でもやり易い。
自分がハマッたのは、phpMyAdminのインストールと、SSL化の後の部分。
phpMyAdminはどのconfで挙動が制御されているのか分からず、デフォルトで見られているのは/etc/nginx/conf.d/_http.confと分かるまではハマった。
実際には/etc/nginx/conf.d/_http.confと_ssl.confはリネームか削除して問題ない。
/etc/nginx/conf.d/プロファイル名_http.confとプロファイル名_ssl.confが実際にkusanagi+Nginxで動作するconfになる。
SSL化前後の手順はどうなるか自分でも分からなかったので、やれる事は全部やったという感じになった。
SSL化コマンドの後に少し時間を置いたものの、DNS変更後の浸透時間もあったためか、ブラウザで表示させてもレイアウト崩れやhttpsにならずhttpで表示されるが直らなかった。
結局、ワードプレスダッシュボードの設定でサイトアドレスを「http://IPアドレス」から「https://ドメイン」に変更した事で正常に表示するようになった。
VPS移行にかかった時間
事前調査、仮手順作成:約14日
実際の構築、設定:約10日
DNS浸透時間(レコード変更):約6時間
ある程度情報が集まったと思ってから、仮手順を作成しながら開始したので、開始までにかなり時間がかかった。
DNSレコード変更するとそこからConoHa VPS側が公開サイトになってしまうので、慎重に情報を調べながらやっていた。
DNSレコード、SSL化、リダイレクト設定は順序をどうするかはっきりと分からず結論が出なかったが、9月12日の日曜の午前中からこんな時間にサイトを見ている人はいないだろうと思ったので、見切り発車で行った。
12日午後になってもサイトの表示が安定せず焦ったが、「ワードプレスダッシュボードの設定でサイトアドレスをhttps://ドメインに変更した」の対応後に一気に安定して表示されるようになったので、ドメイン浸透時間もあるので19時頃から仮眠を取り夜中にパンくずリストなどの問題を解消していった。
とにかく一つ問題を解決すると直ぐ次に別の問題が見つかるので、それが辛い。
現在もまだ問題はあるが、取り敢えずConoHa WINGのワードプレスとほとんど同じ状態まで復元出来ている。
本当に疲れた。
VPS移行はおすすめか?
まだ自分もVPSに移行して直後なので何とも言えないが、メリットとデメリットのどちらが多いかによると思う。
結論としては、VPS移行は、おすすめはしません。
メリットとしては、
・ワードプレスの表示が速くなる(可能性が高い)
・kusanagiを使ってのインストールは、対話式で選択肢を選ぶだけでワードプレスの作成だけなら比較的簡単に行える
・kusanagi側でキャッシュを持っているので、キャッシュ系プラグインを使う必要がなく結果としてプラグインの数が減って高速化に寄与する
・同居ドメインが入らず自分専用の環境で運用出来る
・Linuxのコマンドのテストやちょっとしたシェルを作ったりなどのテスト+学習環境になる
・サーバーのイメージ保存が便利で一瞬で元の状態に戻せる
・レンサバと同スペックなら料金が割安になる
・更なる高速化エンジン「WEXAL」が使える
・LinuxOSやNginx、VPS環境の改善方法に詳しくなる
・OSのroot権とDBのroot権があるので、テーブル削除や細かい修正等もやり易い
デメリットとしては、
・構築作業が大変、面倒
・ある程度のLinuxやサーバー設定知識が求められる(プログラムやPHPの知識は不要 Linuxサーバーの初級レベルの知識はあった方が良い)
・モジュールの更新やSSL証明書の更新等、レンタルサーバーに任せていた作業を全て自分でやる必要がある
・OSへの接続環境自体を管理・維持する必要がある(パスワード、認証鍵、接続ツールなど)作業PCが変更した場合に負荷が高い
・レンサバに任せていたセキュリティを自分で対処する必要がある
・日々の運用でエラーログを見てチェックや修正を求められる
・エラー対応が全て自分次第になる サポートはミドルウェア側は回答してくれない
・ConoHa VPS+KUSANAGI+Nginx環境のネット上の情報が少ない
・.htaccessからNginxのconfへの単純移行が出来ない
・KUSANAGI公式ドキュメントに記載ミスが多い
・WEXALは2019年から提供開始で2年経過し無償利用可能にも関わらず、ネット上の情報が少ない
・日々のヘルスチェックや環境改善、情報収集に時間を取られてブログを書く時間が激減する
・ConoHa VPSではWAFが有料(WINGではWAFは無料利用可能)
・ConoHa公式掲載のマニュアルが全体的に参考にならない
・完全に環境を安定させるなら、有料のWAFやバックアップ自動取得などのサービスを使う必要があり、お金がかかる(レンサバでは無料なので本来は無用の出費)
・イメージバックアップが最後の頼りだが、手動でバックアップを取る場合は一度サーバーシャットダウンしなければならず、アクティブが0のタイミングを見計らってシャットダウンするなど、運用が大変になる。
(Conoha有料バックアップであればシャットダウンは不要。)
・ConoHa VPS KUSANAGIのOS「CentOS」が終了を発表している。
■CentOS 7 サポート期限 2024年6月30日で終了
■CentOS 8 サポート期限 2021年12月31日で終了
■CentOS 9 OSリリース自体なし
総合すると、速度改善等のメリットもありますが、圧倒的にデメリットというか、面倒くささの方が上回るというのが自分の感想です。
VPSの場合、ワードプレスという枠を超えてOS全体を見なければならず、特にセキュリティの担保にかなりの労力を割かれるので、そこまでしても何としても速度を改善したいという一部の人向けのサーバーだと思います。
VPS移行代行サービスはおすすめか?
以下に関連する話題を書いています。
ワードプレスでVPSに向いている人
自分の経験から、ワードプレスをVPSで運用するのに向いている人を挙げてみました。
なお、自分は無料ブログ+独自ドメイン、ワードプレス+レンタルサーバー、ワードプレス+VPSと、(自宅サーバー以外)ブログ環境については一通り経験済みです。
ワードプレスでVPSに向いている人
・レンタルサーバーの速度やroot権限を持てない事に大きな不満がある人
・レンタルサーバーではやれる事をやって他に方法がない人
・速度の改善のためなら何でもやれる覚悟がある人
・短時間で環境を作れる程度に知識がある人
・コマンドラインでの作業が慣れている人や好きな人
・OS一台程度の構築や運用など、大した手間じゃないという人
・新しい技術や環境が好きな人
・見たことがないエラーが出たらワクワクする人
・地道に改善策を積み重ねられる人
・知識ゼロでも、エラーが沢山出ても、全てが勉強と思える人
これらの人は、VPSに移行しても大丈夫だと思います。
結局、VPS(CentOS)という環境が、面倒くさくも付き合っていけるかどうかになりそうです。
その他
noteにURLを貼り付けるとき、数秒遅延があると、「貼り付け出来ませんでした」のようなメッセージが出ることがあります。
これまで、実際ワードプレスの速度が遅かったので、URLの貼り付けが出来ず、文字列にリンクで張るというやり方をしていました。
今回速度が上がったことで、ワードプレスのURLをnoteに以下のように貼り付け出来るようになったのが、思わぬプラスでした。
以前から、遅いから貼り付けが出来ないのだろうと思っていたので、今回はそれが解消出来たのが良かったです。
VPS移行でワードプレスのURL貼り付けが出来るようになった
ConoHa VPSについて知っておいた方が良い事
ConoHa VPSについて知っておいた方が良い事をまとめました。
・ConoHa VPS料金はシャットダウンしていてもかかる
ConoHa VPSではサーバースペックによって月額料金がかかります。
料金は、仮想マシンの起動状態に関係なくかかります。
「サーバーをシャットダウンしていたのに料金がかかった!」という事のないように事前に確認しましょう。
契約したサーバーを削除すると、料金の課金が止まるようです。ただ、自分は確認していないので正確には不明です。
・サーバーのメモリは初期で1GB以上にする
ConoHa VPSでサーバー追加時にプランという選択肢がありますが、これはサーバーメモリの事で、必ず1GB以上にします。
最初に「512MB」を選んでしまうと、後から変更したくてもプラン変更が出来なくなります。
実際のサーバー追加画面ですが、「512MB」が初期選択で青く表示されています。この「512MB」は選ばず、必ず「1GB」以上のプランを選びましょう。
・アプリケーションサーバはPHP7を選択する
KUSANAGI初期設定で以下のように対話形式の選択で表示されますが、1) PHP7を選択します。
Wordpressでは通常phpの最新バージョンを使っているため、PHP7で問題ありません。
アプリケーションサーバを選択してください。
1) PHP7(デフォルト)
2) HHVM
3) PHP5
ネット上の記事によっては、HHVM(HipHop Virtual Machine)を選択しているものもありますが、HHVMはphpのサポートを段階的に終了する事を発表しているので、選択しないようにします。
(※そもそもWordPress5.2以降ではHHVMは利用出来ないらしい。)
・KUSANAGIやサーバーモジュールは自分でアップグレードする必要あり
KUSANAGIやサーバーの関連モジュールは、自分でアップグレードする必要があります。取り合えず情報を取る必要があるので、以下のプライム・ストラテジー社公式ツイッターやアップデート情報を参照するのが良さそうです。
ただ、アップデートして関連モジュールが全て最新化された結果、使っていたテーマ・プラグインが動作しなくなる可能性があるため、これまで以上に情報収集や慎重なアップデートが求められます。
Let's Encryptの証明書については、kusanagiコマンドでSSL化を行うと、cronに登録され自動で証明書を更新してくれる設定になります。
(更新が権限エラーで弾かれる可能性はあり。)
・KUSANAGIは特別にチューンされた環境なので、設定ファイルなどの場所が違っている
例えばphpの設定で、upload_max_filesize等の値を変更する場合、「/etc/php.iniをvimで開いて~」のような記事が多いですが、KUSANAGI環境では、php5.6とphp7の場合でファイルの場所が異なります。
php5.6……/etc/php.ini
php7……/etc/php7.d/php.ini
以下の記事(KUSANAGI MAGAZINE)にあるように、/etc/php7.d/php.iniが正しい設定ファイルになります。
また、php7環境では、kusanagi statusコマンドを確認すると、以下のようにphp7-fpmが表示されるのが正常です。
php-fpm.serviceがずっとFailedになっているので、かなり悩みましたが、php7-fpmが立ち上がっているのが正常なので、正しい状態でした。
このようにphp5.6とphp7では設定ファイルや表示がかなり異なるので注意が必要です。
$ kusanagi status
*** php7-fpm ***
● php7-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php7-fpm.service; enabled; vendor preset: disabled)
Active: active (running)
・Nginxでは.htaccessが使えない
ConoHa VPS+KUSANAGIではWebサーバーにApacheとNginxのどちらかから選べるようになっています。
(共存は出来ますが、どちらかのポート番号を変更したりしないと動作しないのでお奨めしません。)
Apacheでは.htaccessが使えるため、これまでレンタルサーバーでは.htaccessに301リダイレクト系の処理や、国内ホワイトリストIPレンジの許可、スパムドメインの拒否を設定していました。
が、Nginxでは.htaccessが動作しないため、これらのリダイレクト処理、許可・拒否設定はNginx側のconfに処理を記述する必要があります。
MariaDB(MySQL)のログイン方法
KUSANAGIワードプレスはWEB、AP、DBのオールインワンサーバーなので、
OSにログインして、更にDBにもログインしてSQLコマンドを打ったり出来る。
MySQLはユーザーに権限が設定されているため、ログインする時は、MySQL rootでログインする。
MySQL rootのパスワードは、KUSANAGIのOS初期設定でMySQL root passwordを設定する時に設定する。
MySQLへのログインは以下のようにする。
まずVPSサーバーにTera Term等で普通にOSログインする。
次にmysqlコマンドでDBログインする。
$ mysql -u root -p DB名
Enter password:と出たら、MySQL root用に設定したパスワードを入力する。
MariaDB [DB名]>
のようにプロンプトが出れば成功。
例えば
MariaDB [DB名]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
のようにデータベース名を表示させたり出来る。
DB接続終了はexitを入力。
ワードプレスのVPS+KUSANAGI設定の参考記事を掲載されているサイト様
構築にあたり多数のサイト様や記事を参考にさせて頂きましたが、特に見ておいたほうがいいのは以下のサイト様の記事です。作業の工程や作業イメージは、こちらのサイト様の記事を見ることで大よそ掴めると思います。
有難うございます。
参考サイト様(敬称略)
ガリガリコード
初心者向け!ConoHaでKUSANAGIの始め方(1)サーバーを作る
初心者向け!ConoHaでKUSANAGIの始め方(2)KUSANAGIの初期設定
初心者向け!ConoHaでKUSANAGIの始め方(3)WordPressのインストール
初心者向け!ConoHaでKUSANAGIの始め方(完)セキュリティ設定
有限工房
ConoHaに入会してKUSANAGIを立ち上げる
KUSANAGIを設定してWordPressを立ち上げる
KUSANAGIにSSHでつなぐためにセキュリティを強化する
きもおたねっと。
超初心者向けに公式導入マニュアルを翻訳してみた ~KUSANAGI for ConoHa
ぼっちログ
はてなブログからWordPressへの移行とhttps(SSL)化の手順まとめ
複数のWordPressをKUSANAGI for さくらのVPSに移行する手順 まとめ
注意事項
個人が自分の考えで書いたものです。必ずしも内容が正しいとは限りません。
読まれる際はご理解をお願いします。
シリーズ一覧
※作業内容についての質問には答えられません。
※掲載された内容によって生じたいかなる損害に関しても一切の責任を負いません。
※VPS移行等の作業依頼は受け付けておりません。
いつもお読みくださり有難うございます!サポートいただければ励みになります!