読者です 読者をやめる 読者になる 読者になる

uzullaがブログ

uzullaがブログです。

nginxと、php-fpmで動くアプリケーションをマウントする時の話

php

「nginx+php-fpmをつかって構築しましょう!」みたいなのをしらべると、大体locationで正規表現で \.php$マッチしよう!みたいな、URL中の拡張子をみてあれやこれやしてどうこう、というApache的世界観を達成しようというのが結構あるのだけれど、
実際のところ、個人的には毎回ウ〜ンとなる事が多い。


昨今のPHPは大体フレームワークをつかっており、1つのファイルがブートストラップになっていて、たくさんの*.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にすればええやんけ、というのもまったくそうではある。
(意味無くそうしたくもないから、悩んでいるのだが)

こちらからは以上です。

*1:勿論urlに.phpってだしたってなんの問題もないと思うし、「私は」出ていてもあまり問題ない派なのだが

*2:たとえばSlim frameworkのことだ

*3:その構成でbuiltin serverをつかうなら、router scriptを合わせるように書かないといけないし、まあ軽い二度手間感