このブログは、さくらVPSの一番小さいインスタンス上で、Nginx+Apache+Wordpress+MySQLの構成で動かしている。
一応、アプリケーションレイヤの部分は、Nginxを挟んでいることもありそこそこ柔軟に動かせたりするのだが、永続レイヤというかMySQLの部分はかなりつらい。今まで何度もサーバーのOSを再インストールして、一番最初の頃に作り上げたカオスな環境を脱しようかと思ったけど、DBの接続先がlocalhostである以上、DBも巻き沿いを食らう。別に止めても誰も困りもしないブログだけど、職業柄かしらないが障害でサイトが停止することにすごい抵抗感があったため、ズルズルとこの構成のまま二年くらい放置してしまった。
半年くらい前、ConoHaというVPSを知った。イメージキャラクターが清楚可愛いのはもちろんのこと、定期的に勉強会やイベントに出ていれば、結構ガバガバな感じのクーポンをもらえることを知った。また、さくらVPSとは少し毛色が違い、どちらかというとさくらクラウドに近い感じの、インスタンスやネットワークの管理をコンパネ上で行える、イケてる？ 感じのVPSだった。というか、コンパネがさくらクラウドのそれだった。ConoHaは、そこそこさくらVPSをライバル視してる感があり、価格設定とかもかなり意識されている。とりあえず、一番安い。しかも、クーポンとかも定期的に出ている。半年ほどウォッチしていた感じだと、そこそこ頻繁に障害が発生していたが、ここ数ヶ月は安定しているみたいだった。お名前.comでやらかしたばっかりのGMOグループっていうことは気になったが、Twitterとか見ている感じは、絶望的なセキュリティでもなさそうなので、サーバーを一台借りてDBサーバーとして運用しようと決めた。
ConoHaのVPSを借りるということは、ブログの構成が
[さくらVPS上のNginx+Apache+WordPress]-通信-[ConoHaVPS上のMySQL]
という形になる。これも職業病だけど、グローバルな通信を暗号化せずに行うことに対する拒否反応はすさまじい。だから、さくらVPSとConoHaとの間の通信をSSLで暗号化することにした。
ConoHa VPSのプロビジョニング
ConoHa VPSの借り方とか、いかにConoHaちゃんが清楚可愛いかは、多分放っておいても公式のTwitterが教えてくれるから触れない。
ConoHaのサーバーを借り、sshで通信ができたら、Ansibleを使ってDBサーバーとしてのプロビジョニングを行う。使うPlayBookは、Ansibleのコントリビューターの人が公開しているものを使う。
テキトーな場所でBest Practiceのディレクトリ構成を作ったら、READMEの通りに適当に設定し、playbookを実行。Inventoryとかはこんな感じ
ディレクトリ構成
group_vers/
host_vers/
roles/
mysql # さっきのリポジトリのクローンを置く
servers # 実行対象のホスト
site.yml # 大本のplaybook
site.yml
---
- hosts: db_servers
user: root
roles:
- mysql
servers
---
[db_servers]
conoha-db # ここの設定は、~/.ssh/configで定義されてる接続情報のホスト名
これだけ定義して、あとは次のコマンドで一発
ansible-playbook -i servers site.yml
正直、簡単すぎて失禁するレベル。
あとは、CentOSを選んだ場合、iptablesの設定を追記して3306ポートを開けなくてはいけない。
/etc/sysconfig/iptablesに、次の行を追記する
-A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT
その後、iptablesを再起動
service iptables restart
MySQLのSSL通信有効化
書いてあることをほとんどそのまま実行しただけだけ。
mkdir /etc/mysql-ssl
cd /etc/mysql-ssl
openssl genrsa -out ca-key.pem 2048
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -out server-cert.pem -set_serial 01
途中、CAの情報とかを入力するからめんどくさいが、全部適当な感じの値を入力してても問題ない。オレオレ認証なので。
あとは、my.cnfにSSLの設定を追加する。yumでは/etc/my.cnfだが、ソースからコンパイルしたりするとパスが違ったりするので、注意する。次の設定を、[mysqld]ディレクティブ（MySQLでもディレクティブっていうのかは忘れたが）の下に書く
ssl-ca=/etc/mysql-ssl/ca-cert.pem
ssl-cert=/etc/mysql-ssl/server-cert.pem
ssl-key=/etc/mysql-ssl/server-key.pem
その後、MySQLの再起動
service mysqld restart
DBの作成と、ユーザーの追加を行う
mysql -u root
create database 'tolarian_academy_wordpress'
grant all privileges on tolarian_academy_wordpress.* to wpadmin@'%' identified by "YOUR PASSWORD" require ssl;
古いDBのからデータの移行
新しいDBを作ったら、今度はmysql dumpを使ってデータを移行する。さくらVPS上で次のコマンドを実行。
mysqldump -u root -p tolarian_academy_wordpress > tolarian_academy_wordpress.dump.sql
作成されたファイルを、SCPなり何なりつかってConoHaVPSにコピーする。そして、ConoHa上で次を実行
mysql -u root tolarian_academy_wordpress < tolarian_academy_wordpress.dump.sql
これで、DBのデータの移行が完了
WordPressのDB接続をSSL化
これは。WordPressのバージョンによってかなり差があるみたいなので、エッセンス的にとどめておく。自分の環境では3.xだったので、wp-includes/pw-db.phpファイルに直接SSL接続を行う設定を追記した。このページを見ると、多分何をすればいいのかがわかると思う。
あとは、wp-config.phpの中の接続情報を書き換えるだけで完了した。
無事に移行して
思ったよりも簡単に移行が出来て、満足している。やはり、アプリケーションとDBを分けることは大切なのだ。アプリケーションをぶっ壊すたびに、DBまで巻き添えを食らう環境は、やはり精神衛生上良くない。