nginxと、php-fpmで動くアプリケーションをマウントする時の話
「nginx＋php-fpmをつかって構築しましょう！」みたいなのをしらべると、大体locationで正規表現で \.php$マッチしよう！みたいな、URL中の拡張子をみてあれやこれやしてどうこう、というApache的世界観を達成しようというのが結構あるのだけれど、
実際のところ、個人的には毎回ウ〜ンとなる事が多い。
昨今のPHPは大体フレームワークをつかっており、１つのファイルがブートストラップになっていて、たくさんの*.phpファイルがちらばることは減り(減ってるだけで、無いとはいわない！)、勢い、index.phpを省略するのが通常になっている。
勿論nginxにかぎった話ではなく、Apacheでもrewriteするのが普通だろう。
nginxでapacheでよくあるファイル存在確認しつつなんたらするのは、try_filesをつかうのが多いとおもうのだが、*1、どうもtry_filesの泥臭さみたいなものが好きになれない。
というか、try_filesは仮想パスが複雑だと、扱いづらいと思う
で、私が思っているのは、いっそのこと、
location / {
}
location ~ ^/api/ {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /path/to/api.php; # 直接指定する
fastcgi_param SCRIPT_NAME /api;
}こんな風なのがよくないか？ということである。
（SCRIPT_NAMEが異様だが、これはフレームワークの「よしな」によって、SCRIPT_NAMEとPATH_INFOがケンカして微妙な事になるので指定する事が「私は」ある*2）
そもそも、PHP以外のアプリケーションサーバーだと、結局こんな概念になっているのではないか（imgや、cssなど「スタティックファイル以外なら、APサーバに投げる」設定も多いけど）。
この設定の副作用として（？）、htdocs以下にphpファイルを置かなくても良い。
まあ気休めかもしれないけど、nginxは設定ミスるとすぐにソースが漏れるので個人的には気に入っているのだが、皆さんはどうだろうか。
(ただ、Builtin-serverで開発する場合は相性が悪い *3 )
あと、やっぱりPHPが悪いとはいわないが、PATH_INFOは闇が深く、nginxのconfで、
if ($uri ~ "^(.+.php)(/.+)") {
set $script $1;
set $path_info $2;
}こんなの本当になみだぐましい。
とにかく良い感じにミスりづらい、イケてる感じの手法は何かなあ、というのが最近の気分です。
phpが「本番で使えるhttpd」をもってくれていれば、こんなことしなくて良い気もするし、バックエンドをApache+mod_phpにすればええやんけ、というのもまったくそうではある。
（意味無くそうしたくもないから、悩んでいるのだが）
こちらからは以上です。
