wordpressはAWSで二台構成で運営する場合、
CloudfrontとALBを挟むとマジで辛い経験をされた方は多いのではないでしょうか。

例えば😜

・ビジュアルエディターモードが出ない
・リダイレクト問題
・Cloudfrontのキャッシュでwordpressのダッシュボードが死んでプレビューがTOPに戻る
・ALB設定ミスでwordpressダッシュボードにログインできない

などなど。。そこらへん初めて構築してハマることがないように今回はブログします。


■構成

動きとしてはユーザ→Cloudfront(443)→ALB(80)→EC2(80)なので、
証明書はACMを使ってクラフロのみ443にし、内部は80で返してます。
もちろんwordpressのダッシュボードもCloudfront経由でアクセスする想定です。
※web01のwordpressコンテンツはrsyncでweb02に毎分rsyncで上書きしてます。


■wp-config.php

・wordpressの仕様について
CloudfrontからALBにアクセスすると80→443に対応(プロキシ変換)していないため、
コンテンツ等型ずれが起きます。強制的にそうならないよう上記をwp-config.phpに直接書きます。


■ALB(Load Balancer)

ロードバランサーはもちろん分散しているため、
デフォルトはブラウザでwordpressを編集する(ダッシュボード)と
二台目(web02)にもアクセスしてしまう。(ログインしたのにログアウトされてしまう)
ロードバランサ上の設定を変更して/var/www/html/wp/配下は一台目(web01)のみアクセスしないようにします。

・一台目(web01)を指すターゲットグループを作成

・既存のリスナーから「ロードバランサ」-「ルールの表示/編集」

・各ルールの追加

これでALBは問題ないはず!


■Cloudfront

・Behavior

上から見ていきましょう。
基本wp-admin、wp-login.php、*phpはマストでキャッシュ0にします。
記事書いてプレビューすると何故かログアウトされTOPページにリダイレクトされるので注意しましょう。
もしくはログインができません。
さらにCloudFrontからアクセスした場合、User-agent「Amazon CloudFront」で書き換えられます。
PCからのアクセスでないと判定されビジュアルエディタモードがOFFになってしまうため上記のようにホワイトリストを追記します。
Defaultはちゃんとキャッシュするように!

・Hit from cloudfront

curlコマンドでキャッシュ聞いてるか確認できるのでやってみると良いでしょう。
ちゃんとadachin.comはx-cache: Hit from cloudfrontになっていることが分かります。
※ちなみにドメインは適当


■まとめ

wordpressめ!
と言いたいところですが、2台構成で究極な負荷分散を実現できます。
これら設定漏れあると死んでしまうのでterraformで全てコード化すると良いですね😁

参考
https://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13

The following two tabs change content below.

あだちん

1989年生まれ。 Infra Engineer(SRE) In Shibuya 2013年新卒に自宅サーバを構築し、この技術ブログを立ち上げたが、 2017年に電源が壊れConoHaにリプレイスした。 好きな構成管理ツールはAnsible,Terraform。 インフラならAWS/Docker。言語はPython。 WEBサーバならH2O。そして「脆弱性スキャナVuls」のOSS活動もしており、VulsRepo init fileのコミッターでもある。VulsのためにGolangと格闘中でエバンジェリストに任命!?HIPHOPが好きすぎてTrack Makerでもある。

コメントを残す