前編ではサーバを支えるバックエンドについて設定のこつなどを書きましたが、後編ではフロントエンドおよび番外編としてWordPressの移転について少し書かせてもらいたいと思います。なお、箇条書きの番号は案内ページに書いてある番号をそのまま使っていますのであしからず。
14.MariaDBの導入
WordPressやら何やらを使うためにはどうしてもデータベースサーバが必要になります。そのため、MySQL互換のMariaDBを導入しておく必要性がある、というわけです。今回はMariaDBのサーバからリポジトリを導入しているので実は
# yum install mariadb-server mariadb-clinent
とやるだけで最新のMariaDBが導入できちゃったりします。ちなみに私が導入したときのバージョンは10.3系でした。それ以外の設定もMySQL時代と同じ設定がほとんど使えますので「設定を書く場所を間違えなければ」ほぼそのまま書くことができます。例えばサーバに関する設定であれば/etc/my.cnfは変更せずに/etc/my.cnf.d/server.cnfに書く、とかでしょうか。
あともう一つ注意なのが今回MariaDBの領域を別パーティションとして扱っているので、/var/lib/mysql直下にlost+foundディレクトリが生成されています。MySQLやMariaDBはデータベースごとにディレクトリを生成してその中に格納していくタイプなので、空のディレクトリがあると間違えて存在するデータベースとして認識されてしまいます(私の場合は#mysql5.0#lost+foundだったかな？)。一応ディレクトリを削除すればデータベースはなかったことになりますし、実はMariaDBの設定ファイル/etc/my.cnf.d/server.cnfあたりに
[mysqld] ignore-db-dir = lost+found
とやるとMariaDBからデータベースが「見えなく」なります。USE DATABASEで選択できるので隠しデータベースのできあがり、というなんとも怖い現象だったりするのですが…。
15. nginxの導入
あとはフロントエンドに当たるnginxを導入します。こちらも今回はリポジトリが設定されているので
# yum install nginx
だけでインストールが可能です。まあ、Apache2.4系になったこととOpenSSLもある程度新しくなっているのでApache側でHTTP/2.0が使えるようになっている、というのがなんともいえないところでしょうか。キャッシュなんかもnginxを通さなくてもある程度速度が出るのかも…。
ちなみに今回は設定を以前のサーバからそのまま持ってきたので詳しいチューニングは行っていません。VPSサービスそのものはほぼ同じ物を使っているので問題はないはずですが…。
番外編その1 WordPressの移行
これでWebサーバの基本的な構築は完了したので各部分の動作チェックを行えば移行が可能になります。今回少し苦労したWordPressの移行について少し書いておきます。基本的にWebのファイルについては前のサーバでtarで固めたものを持ってきて展開、データベースは対象の部分を一度SQLでdumpした後移行するサーバ上でSQLを直接発行して終わりになります。
SQLの部分はちょっとサイズと実行時間に問題があった(php-fpmのタイムアウト設定やらphpのアップロードサイズ設定やらnginxのアップロードサイズ設定やらにひっかかる)ので、Webからの処理は諦めてターミナルから入れて解決しました。取り出すときはWebからの処理でも大丈夫だったのに…。
そして面倒だったのがWebファイル側の部分です。パーミッションや所有者はtarで固めている関係で迷うことは全くなかったのですが、Webページを開こうとすると500エラーで開かない。Webのエラーログをあさってみても500を「起こした」ことは書いてあったも具体的なエラー原因がわからない。というわけでターミナル上からphpをindex.phpに対して直接発行することで何がエラーになったのか、を調べてみました。結論から言うとWordPress本体はPHP7.0系以上が基本となっているのですが、プラグイン側の一部がPHP7.0系以上で動かない構造になっていた、具体的にはphpはmysql系関数はPHP7.0系以上では使用不可となりPDOかmysqli関数を使わないといけないのですが、そのプラグインがmysql関数を使う構造となっていたためあえなくアウトということになってしまいました。これに関してはまさか初めからWordPressを展開して記事だけ移行＋プラグインを一つ一つ入れていく、なんてことをやると大変なのでWordPressプラグインのディレクトリから対象のプラグインを除去する形で処理してなんとか動かすことに成功しました。この辺は知識がないと難しいですね…。
番外編その2 ドメイン移行前に対象ドメインへのアクセスチェックをするには？
Webサーバなんかではアクセスしてきたドメインごとに振り分ける機能がありますが、これはこの手のサーバ移転ではくせ者になります。つまり、移転作業はチェックが終わるまでは外部に公開できないのに公開した状態がどうなのか？をチェックするためにはドメインを移行したように見せかけなくてはならない、ということになります。SSL証明書なんかでもドメイン名を指定するので移転前だとIPを直接入れるか仮のDNSからアクセスすることになるので毎回ブラウザからのアクセスが不正だ、といわれてしまいます。内部だけでやっているのであれば何とでもできる(DNSサーバをいじるなど)ですが、今回その方法はとれません。
で、どうするか？というと手順としてはこんなやり方をします。
- 仮想マシンなど対象のWebサーバにアクセスするためのマシンを用意する
- 対象のマシンのhostsファイルを一時的に書き換えてしまう(WindowsならWindows/System32/etc/driversにあるので、編集するなら管理者権限があるメモ帳を使うのが一番簡単か？)
- 適当なブラウザでアクセスしてみる
仮想マシンを用意しているのはhostsの書き換えの結果をできれば破棄したいからです。作業環境を書き換えると元に戻すことを忘れたときに面倒なことになるからですね。この方法はWebサーバ以外でもftpサーバやメールサーバへのアクセスチェックでも活躍できます。現に私がチェックしたときには同様のことを行いました。新しく構築する場合はこの手の作業はあまり必要ではないのですが…。
残りのサービスは最終回に持ち越し
ftpサーバとメールサーバですね。ただし、こちらも設定を引き継ぐだけなのであまり詳しいことは書きませんよ。