Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@mby

【コンテナだとちょっとややこしい】nginxでPHPを動かす仕組み

Last updated at Posted at 2021-01-20

nginxもPHPも両方触った事なかったので、調べながら作業した際の記録＆コンテナの仕様関連ではまったりしたのでまとめました。

apacheとnginxの違い

主にwebサーバーへクライアントからのアクセスが重なった際の挙動が違うらしい
apache：1つのアクセスに対して1つの対応を処理
nginx：複数のアクセスに対してまとめて処理

参考：
https://www.kagoya.jp/howto/rentalserver/nginx/

また、apacheの場合はPHPを動かす際に必要になるモジュールがデフォルトでインストールされている為、特別な設定をしなくてもPHPを動かせるが、nginxにはそれがない。

###なぜnginxにはPHPモジュールが存在しないか？
モジュール版はWEBサーバーのプロセスとしてPHPが実行されているが、モジュールでは無い場合はWEBサーバーとは別のプロセス（fastcgiサーバーの中のプロセス）でPHPが実行される為、WEBサーバー自体の処理速度の向上が期待できる。

参考：
https://techplay.jp/column/563

処理の流れ

リクエスト→WEBサーバー→fastcgi
同じ経路を辿ってエンドユーザーにレスポンスを返す
fastcgiプロセスは処理が終わっても破棄されず継続する

###WEBサーバー→fastcgiの接続方法
以下の3種類になる
・socket
・名前付きパイプ
・TCP

socketをサポートしている言語であれば何でも利用することが可能

php-fpmについて

nginxでfastcgiを使用する際にPHPを実際に実行する仕組み
処理の流れはこうなる
リクエスト→WEBサーバー→fastcgi→php-fpm

###プロセス
プロセスの数を予め設定しておいたり（=static)、プロセス数が足りなくなったらプロセスを追加起動できる（=dynamic、追加起動できる数も予め設定できる）
このプロセス1つでCPUの1コアを占有する為、設定はCPUコア数により決める
尚、メモリ消費量はプロセス1つで100M切る模様
dynamicの場合プロセスが肥大化していく（=メモリ消費量の肥大、削除の仕組みがない？）定期的な再起動でメモリのクリアが必要

尚、プロセスの集まりをプールと呼ぶらしい

参考：
https://hackers-high.com/linux/php-fpm-config/

インストール

公式によると

FPM を有効にして PHP をビルドするには、configure 時に --enable-fpm を追加します。

との事。

尚コンテナに環境構築する場合、PHP公式のDockerイメージでイメージ名に「fpm」と明記されているものを選ぶと、コンテナ起動時にはfpmがインストールされた状態
（ここから登場する「デフォルト」は全て下記のバージョン前提）

/app # /usr/local/sbin/php-fpm -v
PHP 7.4.13 (fpm-fcgi) (built: Dec 17 2020 09:09:15)
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

設定ファイルについて

設定ファイルは下記にあった
/usr/local/etc/php-fpm.d/www.conf
コメント部分を抜くとこんな中身、なんとなくここまで記載した内容の事が指定されているような

[www]
user = www-data                                                                 
group = www-data  
listen = 127.0.0.1:9000  
pm = dynamic 
pm.max_children = 5 
pm.start_servers = 2  
pm.min_spare_servers = 1
pm.max_spare_servers = 3

あれ、公式にはこうなってたんだけどな（グループも）PHP8のページだからかな？

--with-fpm-user - FPM のユーザー (デフォルトは nobody)。

とりあえずデフォルトの状態でも使用する事自体はできる。
尚、上記設定ファイルは下記ファイルでインクルードされている（こちらもコメント割愛）
/usr/local/etc/php-fpm.conf

[global]
include=etc/php-fpm.d/*.conf

webサーバー側の.conf設定

appサーバーとwebサーバーを別々のマシンとして分けたいという状況を元に下記を作成。

server {
    listen 80 default_server;
    server_name _;
    root /app/webroot;
    index index.php;

    location ~ ^/(.*)$ {
        fastcgi_pass app:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param CAKE_ENV local;
        include fastcgi_params;
    }

    error_page 404 /404.html;
        location = /40x.html {
    }

    error_page 500 502 503 504 /50x.html;
        location = /50x.html {
    }

}

ポイントはfastcgi_xxの部分。

####fastcgi_pass
TCPで指定、違うコンテナ間での通信の場合、socketは使用できないというのをどこかで見た為（どこで見たか忘れた）

####fastcgi_index
ディレクトリのリクエストがあった場合に返すファイル

####fastcgi_param
環境変数の設定

最低限、これだけで動くらしいけど、本当はもっといっぱい便利に使える設定とかあるんだろうなぁ。
今時点では全く網羅できない。

php-fpmの動作確認（と落とし穴）

設定もなんとなくできたから早速コンテナ起動して動作確認してみよう、と起動するもphpが動作しない。
なぜ、、へこむ。プロセスを確認。

/app # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 tail -f /dev/null
   20 root      0:00 /bin/sh
   52 root      0:00 ps aux

あれ、php-fpmのプロセスもないけど、PID1が何か、、
全てのプロセスの生みの親はどこへ？

PID1問題

ここにコンテナの衝撃の仕様が書いてあった
コンテナでコマンド実行するとPID1になるのかーーー

####起こった事象のまとめ（推測含む）

コマンドなしでコンテナ起動した場合、php-fpmのプロセス（PID1）が存在
（fpmイメージにこのプロセスが起動されるように仕込まれているらしい）
docker inspectの結果、下記のようになっていた

            "Cmd": [
                "php-fpm"
            ],

ちなみにエントリーポイントは下記

            "Entrypoint": [
                "docker-php-entrypoint"
            ],

これをkillしようとしたりするとできなかったりする
↓
コマンドありでコンテナ起動した場合、PID1がコマンドに上書きされる
結果php-fpmマスタープロセスが消える事でプール全部消える
↓
コマンドが何かのインストールだった場合、インストール処理が終わったら継続するプロセスが何も存在しない事でコンテナも落ちる（プロセスが何であれ継続するプロセスがひとつ存在しなければならない）

今まで深く考えずtail -f /dev/nullしていたけど、掘り下げたらこういう仕組みだったという事ですね。

まとめの内容を踏まえて対応を考える

今回のミッションとしては
・APとWEBでコンテナを分けたい
・コンテナ起動時にcomposer installをしたい

こういう理想があるので、それを実現する方法として

    command: >
      sh -c "
      composer install --no-interaction &&
      /usr/local/sbin/php-fpm
      "

php-fpmが起動しさえすれば、このプロセスが使われてなくても継続されるものなので、インストールが終了した後もコンテナが落ちないという事ですね。

ただ、これだとPID1がphp-fpmになる様子

/app # ps
PID   USER     TIME  COMMAND
    1 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   29 root      0:00 /bin/sh
  318 www-data  0:00 php-fpm: pool www
  320 www-data  0:00 php-fpm: pool www
  321 root      0:00 ps

コンテナなのでそもそもしないと思うけど、php-fpmプロセスをkillしたりするときに変な挙動をする可能性が残っている

####composeファイルのinitオプションを使う

この問題を避ける為に、Docker-composeには既にオプションが存在しました！

Run an init inside the container that forwards signals and reaps processes. Set this option to true to enable this feature for the service.

このオプションをtrueにすることで使用することになるinitの設定を変えることもできるみたいだけど、デフォルトのもので動作確認。

/app # ps
PID   USER     TIME  COMMAND
    1 root      0:02 /sbin/docker-init -- docker-php-entrypoint sh -c  composer install --no-interac
    6 root      0:03 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   16 www-data  0:00 php-fpm: pool www
   17 www-data  0:00 php-fpm: pool www
   18 root      0:00 /bin/sh
   23 root      0:00 ps

PID1がdocker-initというものになった！
これで仮にphp-fpmのプロセスを再起動したい、等の場合対応できるはず

php-fpmの停止＆再起動の方法

単にkill+PID（又はプロセス名）だけではコンテナが落ちる。
この辺りは最初PID1のプロセスの際に起こるのかと思っていたけど、PID1の件が解決しても起こる。

参考：
https://www.softel.co.jp/blogs/tech/archives/5196
公式を元にした上記ブログの情報だとkill+PIDで停止できるようだけど、コンテナの場合少し事情が違う？
この辺りはコンテナとphp-fpmの掘り下げが更に必要そう、、

####再起動は可能
上記のブログに記載の内容で停止はできないけど、再起動はできる。
USR2シグナルを使用するらしい。（php-fpmで定義されていると思われる）

/app # kill -USR2 6
/app # ps
PID   USER     TIME  COMMAND
    1 root      0:00 /sbin/docker-init -- docker-php-entrypoint sh -c  composer install --no-interac
    6 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   18 root      0:00 /bin/sh
   24 www-data  0:00 php-fpm: pool www
   25 www-data  0:00 php-fpm: pool www
   26 root      0:00 ps

こちらにも同じ再起動の方法が記載されていた
参考：
https://cloudpack.media/13479

なんで停止はできないんだろう、、
ちなみにPID1がphp-fpmのマスターの場合でも、上記再起動は可能

$ docker-compose exec app ps
PID   USER     TIME  COMMAND
    1 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
    6 www-data  0:00 php-fpm: pool www
    7 www-data  0:00 php-fpm: pool www
    8 root      0:00 ps
$ docker-compose exec app kill -USR2 1
$ docker-compose exec app ps
PID   USER     TIME  COMMAND
    1 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   18 www-data  0:00 php-fpm: pool www
   19 www-data  0:00 php-fpm: pool www
   20 root      0:00 ps

もやっとするけど、必要な設定を備えたコンテナ起動という目的は達成したので、ここの掘り下げはまた時間がある時に。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?