☰

nginx リバースプロキシから php-fpm へ

tag-icon • tag-icon php nginx docker reverse-proxy
nginx リバースプロキシから php-fpm へ

Nginx の設定で概念的に問題があります。SSLnginxターミネータ リバース プロキシから始めて、docker-compose.ymlそれぞれが仮想サービスを提供するいくつかのコンテナを使用したセットアップを使用します。これらのサービスは、単一のホスト名の下のサブディレクトリとして提供されます。

net --443--> nginx
             | | `--- ContainerA "https://example.com/serviceA/"
             | `----- ContainerB "https://example.com/serviceB/"
             `------- ContainerC "https://example.com/serviceC/"

プロセス リストのスニペット:

nginx:~$ ps fax
127285 ?        Ss     0:00  nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -g daemon off;
127419 ?        S      0:00   \_ nginx: worker process
127420 ?        S      0:00   \_ nginx: worker process
127421 ?        S      0:00   \_ nginx: worker process

ContainerA:~$ ps fax
127132 ?        Ss     0:09  php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
234053 ?        S      8:27   \_ php-fpm: pool www
236952 ?        S      8:12   \_ php-fpm: pool www
259123 ?        S      6:42   \_ php-fpm: pool www

nginxのインスタンスを 1 つ実行し、php-fpm各コンテナで を使用することで効率が向上すると考えました。

私考えるの前提は、php-fpmコンテナが独自のnginxプロセスを必要とせず、nginxプロセスがポート 9000 経由で各コンテナと通信することです (ネットワーク部分は機能します)。しかし、実際には問題が発生しているため、前提が適切であることを確認する必要があります。

この基本nginxとphp-fpmアーキテクチャの仮定は正しいでしょうか?あるいは、適切なnginx/php-fpmインフラストラクチャは直接の連携 (同じホストとファイルシステム) で使用することを意図しているのでしょうphp-fpmか、それともマルチホスティング/マルチファイルシステムが合理的かつ効率的でしょうか?

(最近、助けを求めて契約を結んだのですが、最初の返答は「nginx各コンテナで実行する必要がある」というもので、私の理解では意味がありませんでしたphp-fpm。)

nginx.conf(ここでは、この明らかに高レベルのアーキテクチャに関するものではなく、具体的な質問をする質問が多数あります。)

答え1

これは弱い答えですが、私はこう信じています。

はいこれは一般的に正しい考え方ですが、いくつか注意点があります。はファイルphp-fpmを処理するためにあります.phpが、すべての (PHP 以外の) ファイルを提供するためのものではないと思います。そのためには、フロント フェイスnginxプロセスは、実際の PHP 処理を行わない場合でも、すべてのファイルを参照する必要があります。

これを docker を使用してスマートに行うには、コンテナー内のファイルをphp-fpmコンテナーと明示的に共有する必要がありますnginx。docker でこれを行うための推奨される方法は、名前付きボリュームを提供し、それを両方のコンテナーで使用することです。たとえば、次のファイルですdocker-compose.yml。

version: '2'
services:
  serviceA:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolA:/path/to/serviceA
  serviceB:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolB:/path/to/serviceB
  nginx:
    image: ...
    volumes:
    - tmpvolA:/var/www/serviceA
    - tmpvolB:/var/www/serviceB
volumes:
  tmpvolA:
  tmpvolB:

(多くのフィールドが含まれていません...) 最後にリストされている 2 つのボリュームは、docker で言う「名前付きボリューム」であり、理由があって空になっています。スクリプトの起動時には空であることが意図されており、コンテナーの 1 つによって埋められます。(実際には、いくつかの要因に応じて、両方によって埋められる場合もあれば、どちらも埋められない場合もあります。)

この副作用の一つは、ボリュームが持続する。

  • 無駄に再作成されないので、効率の面で「これは良い」です。
  • 「これは良くない」というのは、仮想化されたサービスを持つことの利点の 1 つは、再起動してクリーンな状態を保証できることです。永続的な名前付きボリュームでは、以前のインスタンスで使用されたファイルが、下位の fs レイヤーの厳格なバージョンの代わりに使用されるため、クリーンな状態は (自動的に) 得られません。

この「悪い」状況を回避するには、ボリュームを手動でフラッシュします。これは、docker-compose down -vヘルプに従って、シャットダウン時に で実行できます。

    -v, --volumes       Remove named volumes declared in the `volumes` section
                        of the Compose file and anonymous volumes
                        attached to containers.

docker volume rm <volume-id>またはを使用して手動で実行することもできますdocker volume prune(これにより、一時的か名前付きかを問わず、現在使用されていないすべてのボリュームが削除されます)。

関連情報