この記事はKUSANAGI Advent Calendar 2016の10日目の記事です。
なんだかいつの間にかリレーブログのようにはせべーこと長谷川君(がわじゃねーよ!)もとい長谷部君よりバトンが渡されておりました。
1.KUSANAGIで移設先のサーバを用意する
もちろんどこのクラウドでもいいです。
クラウドの管理画面からKUSANAGIでサーバを起動、rootでログインしたら以下のコマンドでWordPressをインストールします。
# kusanagi init # kusanagi provision kusanagi_html
特にDB名やDBユーザ名にこだわりがないのなら、移設元のwp-config.phpに書かれているDB名、DBユーザ名、DBパスで作っておくとちょっと楽かも。あまり意味はないけど。
ただし、基本的にwp-config.phpはコピーしてきません。KUSANAGI用のキャッシュコマンドなどが書かれているので上書きするとbcashとかちゃんと動かなくなるかも(対処法はある)。
2.WordPressをインストールする
ここでいくつかコツがあります。
パターン1 独自ドメインを移設 + 常時SSL化
すでに稼働中の独自ドメインでWordPressを運用していて、移設に際してLet’s Encryptで常時SSL化を行う場合。
この場合、いずれにしてもまずWordPressを新規インストールするのですが、運用中のドメインを停止したくはないため、hostsを書き換えてからWordPressをインストールします。
例)Windows10の場合
C:\Windows\System32\Drivers\etc\hosts
hostsファイルは管理権限で書き換えないとだめです。やり方は適当にググってください。
www.outbreak2000.com 192.168.0.1
最初が取得している独自ドメインで、後が新しく建てたクラウドの仮想マシンのIPアドレスです。
これで一時的に独自ドメインで新しいサーバにアクセスできるようになりました。
常時SSL化は実際にサーバに外からドメインでアクセスできないと設定できないので後から行います。
パターン2 独自ドメインを新規に取得 + 常時SSL化
独自ドメインを新規に取得する場合は、kusanagi povision の時点でLet’s Encryptを設定してしまいます。
注意するべきは、プロビジョニング時点ではクラウドに建てた仮想マシンのIPアドレスにドメインが紐づいているようにすることです。
もちろんWordPressをインストールする時点で https でアクセスすることをお忘れなく(おそらくこの時点でリダイレクト設定もされてるはず)。
3.wp-content以下をバックアップして持ってくる
wp-content以下をバックアップするにはだいたい以下のコマンドです。
# cd /var/www/html # tar cvzf wp-content_20161210.tar.gz wp-content/
移設元のサイトがシェル使えないとか、WordPressがインストールされている場所とかそれぞれ違うとか、適当にやってください。
要はwp-content以下のファイルがあれば代替大丈夫です。
注意すべきは移設元のWordPressのバージョンが極端に古いとか、wp-content以外のドキュメントルートにしこたまファイル置いているとか、個別の事情がある人は気を付けましょう。
WordPressごと移設しても良いですが、たまにはクリーンにするのも良いですよ(自己責任)。
KUSANAGIはFTPが禁止されていますので、SFTPかSSH(SCP)でファイルを持ってきます。
KUSANAGIは各プロファイルのDocumentRoot以下のファイル権限がkusanagiユーザなので、kusanagiユーザのルートディレクトリにでもとりあえず置いておけばいいんじゃないかな。
直接scpするならだいたい以下な感じ。
# scp kusanagi@192.168.0.2:~/wp-content_20161210.tar.gz /home/kusanagi/ kusanagi@192.168.0.2's password:
展開はだいたい以下な感じ。
# tar xvzf wp-content_20161210.tar.gz
この時wp-content内のユーザ権限を変更しておくと良いかもしれない。
管理画面上からアップデートをかけるpluginsやthemesなどはkusanagiユーザで、WordPressが直接編集するuploadsはhttpdユーザでグループはwwwにしておくと良いかも。
# chown -R kusanagi:kusanagi wp-content/ # chown -R httpd:www wp-content/uploads/
他にプラグインが自動生成したファイルやディレクトリがあるかもだけど、基本は上のルールと同じ。
ちなみに、プラグインやテーマがkusanagiユーザになっているので、管理画面からアップデートをかけようとするとFTPユーザやパスワードを聞いてきます。
これは間違いではなくて、kusanagiユーザで自分自身にFTPを許可して書き込みを行っているので、仮に脆弱性のあるプラグインなどがあってそれらが他のPHPファイルに書き込みを行おうとしても、権限がkusanagiユーザなので勝手に書き換えられたリされない(できない)って言うセキュリティ上の対策なのですね。
これにより管理画面からテーマの編集やプラグインの編集ができなくなるけど、もしもの時のセキュリティを気にするか、利便性を気にするかですね。
ここでの注意点は移設先のwp-content内にあるmu-pluginsを削除してしまわない事。
よくあるのがwp-contentをリネームしてまるっと置き換える方法。これやっちゃうとKUSANAGI用のオリジナルプラグインがなくなっちゃいますので、リネームしたディレクトリから移しておきましょう。
KUSANAGI用のオリジナルプラグインはWordPressの高速化の一端を担っています。
多言語に対応したWordPressが日本語で表示できるのは当たり前ですが、この翻訳が管理画面なども遅くする原因にもなっています。ですので、翻訳ファイルをキャッシュしてしまうことでWordPressの高速化を図っています。
なせ、オリジナルプラグインなのか。それはWordPressのコアを修正したりしないためです。
良く勘違いされるのがKUSANAGIで導入されたWordPressはチューニング(改造)されていると言う間違いですね。これやっちゃうとバージョンアップできなくなるので絶対やりません。
4.MySQLのダンプデータを持ってきてインポートする
MySQLをダンプするにはだいたい以下のコマンドです。
# mysqldump -u user -p dbname > dbname_20161210.sql Enter password:
これもphpMyAdminしか使えないとか、その辺は適当にググってください。移設先のWordPressがクリーンな状態ですので、dropしなくてもまあ大丈夫だとは思いますけど、phpMyAdminからダンプするならdrop入れてダンプしても良いかもしれません。
同様にFTPなりSCPなりしたらDBインポートします。
念のためdropしておくならだいたい以下な感じ。
# mysql -u root -p Enter password: ~ 省略 ~ MariaDB [(none)]> show databases; ~ 省略 ~ MariaDB [(none)]> drop database dbname; Query OK, 16 rows affected (0.21 sec) MariaDB [(none)]> create database dbname; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> quit; Bye
DBインポートは以下な感じ。
# mysql -u dbuser -p dbname < dbname_20161210.sql Enter password:
ここで元々SSLで動いていなかったサイトを常時SSL化するならwp-cliを利用してDBを書き換えたりする必要があります。
例えば新規にドメインを取得して違うドメインから移設した場合であれば以下のような感じ。
# wp search-replace 'https://www.outbreak2000.com' 'http://example.com' +------------------+-----------------------+--------------+------+ | Table | Column | Replacements | Type | +------------------+-----------------------+--------------+------+ ~ 省略 ~ Success: Made 555 replacements. # wp option update home 'https://www.outbreak2000.com' Success: Updated 'home' option. # wp option update siteurl 'https://www.outbreak2000.com' Success: Updated 'siteurl' option.
ドメインの変換をかけたあとに、homeとsiteurlも書き換えています。
これやっとかないとhttpにリダイレクトかかったり、旧サイトにリダイレクトかかったりしちゃいます。
さて、これでだいたい移設は終わりました。ドメインが同じなのであればDNSの切り替えなどが必要ですが、新しいドメインならすぐにアクセス可能ですね。
いづれにしても公開前にサイトの確認は行いましょう。まずはログインしてみて管理画面がちゃんと動作しているのか確認し、フロント側の表示も確認します。
ここで注意なのが、移設で新たにKUSANAGIにした場合、wp-contentの移設時にあったKUSANAGIオリジナルプラグインがちゃんと設定されているか確認をしておきます。
管理画面にKUSANAGIメニューがあればmu-pluginは動作していますので、上部メニューから翻訳アクセラレーターを選んで設定を確認しましょう。
確認する点は、高速化を有効にするにチェックが入っていること、タイプはAPCになっている方が良いです。
ログイン/サインアップ画面の翻訳と管理画面の翻訳はキャッシュを使用で良いと思います。サイトに表示される翻訳された文章については使用しているテーマなどによります。
例えば、自作のテーマで、テーマファイル内に直接書かれている文章がそのまま日本語になっている場合、テーマ側で翻訳を必要としませんので、翻訳を停止にしてしまうとよいでしょう。
既存のテーマを使用している場合で、サイドバーのメニュー項目やコメント欄などを翻訳して使っている場合は、キャッシュを使用にすると高速化が図れます。
5.テーマなどの高速化を行う
さて、KUSANAGIは既存サイトを移設しただけでも十分に速くなります。しかし、実際にはテーマ、プラグインの問題でKUSANAGI本来のスピードを殺してしまっていることが多々あります。
まずは何が原因で速度が落ちているのか確認をします。
おおよその目安は、ログインしていると表示される管理バー右側のパフォーマンス表示の数値です。サイトトップで0.100 sec(100ミリ秒)は最低でも切りたいですね。
WordPressで問題が発生した場合に良く行う手法として、テーマをデフォルトに戻し、プラグインをすべて停止すると言うのがあります。
公開サイトでこれを行うのはいろいろと難しいところがありますが、上で説明してきたクラウド上に新たに仮想マシンを建てて、hostsでアクセスする手法を使えば、テストサイトを作ってゆっくり試すことも可能です。
テーマをデフォルト、プラグインをすべて停止して20ミリ秒を超えてくるようなら十分にKUSANAGIのスピードを出せています。ちなみにKUSANAGIの公式サイトでは0.006 secなんて数値をたたき出していますが、これはKUSANAGIの最大性能(WordPress実行時間3ミリ秒台)を引き出すために特別にチューニングされたオンプレミスのサーバですので、クラウド環境ではさすがに難しいかもしれません。
テーマをデフォルト、プラグインをすべて停止しているのにあまり速度が出ていない場合は、サイドバーやテーマによってはヘッダーやフッダーに使用されているウィジェットエリアが問題になっているかもしれません。
この場合、テーマに改造を加えて、Transientsを駆使した部分キャッシュなどで高速化を図ることもできます。詳しくは「詳解WordPress」のP178などに詳しく説明されてます。
プラグインをひとつずつ有効化していくと突然遅くなる物があるかもしれません。
どうしても外せないプラグインの場合、同じ機能の他のプラグインを探すと言う方法もありますが、同様の機能がない場合には仕方がありません。自分がエンジニアで改修ができるのであれば改造すると言う方法もありますが、結構難しいですね。
仮に公式のプラグインを改修して高速化できたのであれば、是非作者にもパッチを送ってあげてくださいね。
速度テストやセキュリティテストなどが行われて、KUSANAGIで動作することを検証したプラグインやテーマを公開しているKUSANAGI Ready プロジェクトというサイトがありますので、こちらも参考にするとよいです。
十分な速度が出せるようになったら公開しましょう。
あまりアクセスのないサイトなら推奨環境のメモリ4GBでなくても十分に動作させることができます。まあ、あまりメモリが少ないと100ミリ秒を切るのも難しくなってしまうかもしれませんけども。
みなさんが無事にKUSANAGIで高速WordPressでサイトが公開できるようサンタさんにもお祈りしておきます。
なんと明日はいつもバグ報告や要望などをあげてくださる経験値を運営していらっしゃるトツオさんです!
“KUSANAGIに移設する際の5つの手順をまとめてみた” への2件の返信