AWSの複数インスタンス間でWordPressのファイルを同期して冗長化(Lsyncd & Rsync)
何度もハマって、丸一日溶かしたのですが、最終的できたのはこの方法。
Nginx + lsyncd で WordPress を負荷分散させる | dogmap.jp
やりたい事
- AWSでWordPressの開発環境と本番環境を運用したい。
- 問題となるのは本番環境では、wp-content/uploadsやwp-content/pluginが 日々更新され、差分がでてくる。
- WP内の特定フォルダを指定して「本番環境→開発環境」へ同期したい。
構成
全体のイメージ
日々の更新を開発環境へ反映
wp-content/uploadsとwp-content/plugin ※今回やるのはこれ
開発環境 <---- (Lsyncd & Rsync) <---- 本番環境
開発環境 <---- (Lsyncd & Rsync) <---- 本番環境
テーマ開発をで管理して本番へデプロイ
wp-content/themes
開発環境 ----> (GitHub) ----> 本番環境
本番環境(サーバー1)
Lsyncd をインストール
sudo yum -y install rsync xinetd
設定ファイルで注意をしたいのはsync.targetに記載する接続先。 AWS EC2のPrivateIPを入れること。ElasticIPじゃないよ。(当たり前なのかもしれないですが)
settings{ statusFile = "/tmp/lsyncd.stat", statusInterval = 1, logfile = "/var/log/lsyncd/lsyncd.log", } sync { default.rsync, source = "/var/www/vhosts/i-xxxxxxxx/wp-content/test/", target = "[開発環境(サーバー2)]::test", }
開発環境(サーバー2)
xinetd をインストール。(rsyncはAWSの場合は既に入っているはず)
sudo yum -y install xinetd
設定ファイルで注意をしたいのはhosts allowの設定もAWS EC2のPrivateIPを入れること。 また、ここで指定した名前[test]がLsyncd側でtarget指定する名前になります。
log file = /var/log/rsyncd.log [test] path = /var/www/vhosts/i-xxxxxxxx/wp-content/test hosts allow = [本番環境(サーバー1)] hosts deny = * list = true uid = root gid = root read only = false
テーマフォルダのパスをURLを除外して取得する
すごい悩んだけど、こう書くことにした。 なんかうまい関数が実はある気がするな。
<?php $url = site_url(); $tmpl_dir = get_template_directory_uri(); echo str_replace($url,'',$tmpl_dir); ?>
Wordpressの開発でマルチデバイスでLivereloadしたくて苦労した話
普段の開発はChromeエクステンション「LivePage」を使っていたのですが、iPhoneやAndroidでもライブリロードしながら開発したかったので、色々調べたものの、うまく動くものが、なかなか見つからず苦労しました。
タスクランナー系では「Grunt」と「glup」を試しましたがどちらも、設定がややこしくて、挫折しました。ちなみに参考にしたのはこちらの2記事。
ということでタスクランナー系は諦めて、別を探していたら、LIve.jsというスクリプトを発見しました。
テスト環境のHTMLファイルで問題なく動いたので、Wordpressでも行けると思ったのですが、なんとPHPでは動かないらしい。
ということで、この記事を参考にPHPファイルでもHTTP Request HeaderにContent-lengthとLast-Modifiedを入れたのですが、Wordpress側の問題か、動きません。
それなら、誰かがきっとWordpressのプラグインを作っているだろうと、さまよっていたら発見しました。無事動いているので、ここにリンクを置いておきますね。
長い道のりでした。これでマルチデバイスで同時にプレビューが可能になります。
Google Analyticsをユニバーサルアナリティクスへ移行するまでの期限
Google Analyticsで自宅のIPアドレスを除外フィルタする
ある程度トラフィックの多いサイトであれば、自分のアクセスを除外する必要性を感じないかもしれません。
しかしですよ、Google Analyticsで多角的にデータを見たいときはクリックイベントとかを計測し始めるので、それがブレてしまうのはいかがなものかと。やっぱりInternal IPは除外した方がよいので、設定してみました。
手順は、
- アナリティクス設定 > 全てのフィルタ> 新しいフィルタ > カスタムフィルタ
- 「フィルタフィールド」をIPアドレスにして、フィルタしたいアドレスをエスケープして入力(※ここで注意したいのは、ピリオドの前にバックスラッシュを入れること)
という感じ。みんなちゃんと設定しておきましょう。
WPのDBが重すぎるとき引っ越しでトラブるのでコマンドでやろう
いつもWordpressのDBを引っ越しするときにDBが重すぎると
- エクスポート:DBがデカすぎてphpMyAdminが落ちる
- インポート:DBがデカすぎてphpMyAdminが「そんなサイズ読めません」
って言われてなんだかんだ、設定が必要だったりトラブルが多い。なので、dogmap.jpさんのやり方を見て、エクスポートはコマンドでバイナリダンプ、インポートもmysqlへコマンドで直接ブチ込むようにしたら、なんのエラーも出ずに綺麗に引っ越しができることがわかったので、今後はこれでやろうと思っています。
エクスポートはこれ
mysqldump --default-character-set=binary \ -h localhost -u mysqluser -p wordpress_db > wpdump.sql
インポートはこれ
mysql -u mysqluser -p wordpress_db < mysqldump.sql
Wordpressで利用するEC2のインスタンス選び
インスタンス選びで悩んでいました。価格を取るか快適を取るか。
まず、インスタンス選びで価格を見るのですが、あんまり小刻みな料金体系ではないです。東京リージョンの場合でざっくり
- 約2,000円/月 (t1.micro)
- 約6,000円/月 (m1.smallなど)
- 約13,000円/月 (m1.midium , c3.largeなど)
こんな感じなので、6,000円の次が倍以上の価格なのが痛いです。
で、ウチ(www.danshihack.com)の場合のCPU負荷をm1.smallとc3.largeで比較してみたので見てみましょう。
m1.smallの場合 (CPU負荷が100%まで上がります)
c3.smallの場合 (CPU負荷が10%平均で余裕があります)
やっぱりコンピューティング最適なc3は至極快適で、WPの設計が悪いのか、m1.smallはもっさりしてしまいました。これじゃ仕事にならんということで、c3で行く予定なのですが、少しお高いですよね。
そもそもWPの設計が悪い可能性がありますが、そのへんは勉強中なので、今は棚に上げておきましょう。
あとAWSはレンタルサーバーに比べて、自分で負荷状況をモニタできたり、試しにサーバー立ててみたり、スケールのアップダウンをいつでもできたりと、クラウドって素敵だなと思うプロダクトに仕上がっています。おもしろいよ。