21:32WordPressNginxNginxでWordPressを使う時の設定は色々な書き方が出来ますが、ネットの情報は断片的な気がしたのでまとめてみました。可読性良く設定をしたいのと、WordPress向けにこれだけ書けば不自由はないよ!っていうのを目的に設計してます。再精査し内容をアップデートしました。各種スペックはこんな感じでやってます。7.3.3WordPressもSSLで運用するアップデートに追随しないと後々面倒になるので、NginxとPHPは常に新しい物を使うようにします。特別な理由が無い限りWordPressもSSLで運用するのが当たり前になってきたので、NginxはSSL利用を前提とした設定にします。DBについてはこの記事では触れませんが、WordPressの動作要件を満たしたMySQLかMariaDBを適時インストールしてください。NginxのインストールCentOSの場合はyumを使うかソースからNginxをインストールします。運用するようにしてますので、このようなユーザーアカウントを作成しています。wwwNginxをyumでインストールする方法yumでNginxをインストールする場合はこのように。yumの場合は安定版の偶数バージョンがインストールされます。nginxNginxをソースからインストールする方法ソースからNginxをインストールする時はこのようなオプションでコンパイルしています。configureします。\--with-openssl=../openssl-1.0.2r/PHP7とphp-fpmのインストールPHPはremiリポジトリを使ってyumでインストールします。違うバージョンのPHPが入っている場合は先にアンイストールしておきます。php-pearphp-fpm.confのサンプルメモリ4GBのVPSで実際に運用している設定内容をそのまま載せます。/var/log/php-fpm/$pool-slow.logmax_childrenの数はメモリと相談ですが、php-fpmプロセス全体のメモリ量が搭載メモリ以下、max_childrenの数はMySQLのmax_connectionsと同等かそれ以下になるように設定しておきます。max_requestsは子プロセスが応答する最大リクエスト回数で、メモリリーク対策で少なめにしています。プロセス数が少ないように見えますが、Nginxでキャッシュを作る前提だとこの内容で一日30万PV位は問題なく処理できるので問題無しです。配下に設定するようにNginxを構成します。Nginxデフォルト設定のファイルを除くと、各種設定ファイルはこのように配置します。ディレクトリは無いので先にmkdirしておきます。(全体的な設定)Nginxのメインファイルはこのように設定します。(汎用的な設定)このファイルには毎回使うような汎用的な設定を書きます。使う時の設定なので、ディレクトリとかは環境に合わせ変更してください。Encryptの認証アクセスを振り分けて運用するようにしています。(キャッシュの設定)Nginxがキャッシュを保存するパスとキャッシュ周りの設定をここに書きます。設定しているパラメータは下記を参考に必要な分を計算して設定してます。(WordPressの汎用設定)WordPressの設定は複雑なのでここに繰り返し使えるようまとめます。OKなら5分のキャッシュを作るようにしています。inactiveの値も一緒に調整します。キャッシュの有効期限は長いほうがサーバ負荷も減りますが、メディア運用の立場で考えると5分位が何だかんだで都合が良かったりします。側と合わせてください。ここがズレていると想定機種通りのキャッシュが作成、表示できません。(バーチャルドメインの設定)ここではバーチャルドメインの設定を書きます。conf.d/wordpress.conf;}設定ファイルを細かく分けたので、バーチャルドメインはこのようにシンプルに設定できます。可読性が悪いと設定ミスをする原因になるのでよく触る部分程シンプルに保つように心掛けています。EncryptでSSL証明書を取得する方法等はこちらを参照してください。最後は設定に問題が無いかを確認してNginxとPHP-FPMのデーモンを起動します。設定のチェックWarningが出ない事を確認してからデーモンを起動します。コマンドでプロセスが動いているかを確認し終了です。WordPressをNginxで運用する為の設定は以上で、あとはNginxを運用してみて気付いた点等の所感を書きます。SELinuxを有効にしていると出力されるエラーSELinuxが有効になっているとNginxのエラーログに下記のエラーが出てPHPが実行出来ないので注意。“worklog.be”fastcgiの設定に問題があっても出力されるエラーですが、設定に問題が無いようならSELinuxも確認しておきましょう。WordPressの運用はNginxとApacheどちらが良いかWebサーバでNginxとApacheをそれぞれ運用してきてどちらが良いかっていう意見を書きます。等の静的ファイルならNginxというのがパフォーマンスが良い気がします。Nginxはスレッド処理なのでメモリ消費が少ないとは言いつつも、PHP-FPMを結局立ち上げるので管理しないといけないプロセスが増えるっていう点があります。WordPress何かは毎回動的生成に拘る必要も無いページが殆どだと思うので、5分とかそういう短い時間でもいいかキャッシュを作ってしまえば断然Nginxが速い!と思ってます。あとApacheのmod_rewriteが凄い苦手という事もあるので、その処理もまだわかりやすく書けるNginxに軍配という形です。インフラエンジニアだったら両方を触れるようにしておかないといけませんが、それ以外だったらNginxを覚えて置けばいいんじゃないかなという感想です。Nginxで作ったキャッシュの削除方法についてNginxで作成されたキャッシュは、特に何もしなければ有効期限が切れるまで削除されず、クライアントにはキャッシュが返されます。高頻度で更新するサイトで無ければキャッシュ期間を短くするだけでも十分対応可能かとは思いますが、WordPressは様々なフックが用意されていますので更新したらキャシュも同時に消すような機能をWordPressに実装すれば良いです。してますがこれで殆どのケースは大丈夫。Nginxを介さずにキャシュを消してしまうとこのようなエラーログが出てしまいますが、これで困った事は置きてないので良しとしています。directory)あとは、ページによってキャッシュするしない等をNginx側で細かく制御しても良さそうです。WordPress用のキャッシュ削除プラグイン今だとNginxのキャッシュを削除するWordPressプラグインがいくつかあって、自分が採用している方法に非常に近いプラグインを見つけたのでご紹介します。Cache使い方は非常に簡単でプラグインをインストールしたら管理面でキャッシュディレクトリを設定するだけです。どんな処理をしているか確認すると、cache_pathに指定したNginxが自動で作成するキャッシュの親ディレクトリを丸ごと消して再作成しているみたい。true;}試したら問題なくサクッと動作したので自作プラグインは止めて今後はこれを使おうかな。アクセスの多いサイトだと消している間にキャッシュをまた作ろうとするので、一時的に親ディレクトリが無い状態でも大丈夫なのか少し心配ではあります。アクセス数が多い場合、キャッシュファイルの数もそれなりに増えるので消すのにも時間がかかる。こんな風に改良したらより良さそう。(キャッシュ再作成開始)古いディレクトリは後でゆっくり消すこれは後で試す。Cacheは凄いお手軽に使えるのでオススメなプラグインだと思います。以上が運用上の所感です。NginxでWordPressを使う時の設定方法はこれでおしまいです。