回答:
通常、nginxを使用したPHPは、別のプロセスであるphp-fpmを使用して実行されます。
コンテナーごとに1つのプロセスのdocker（この点に関する詳細は回答の終わりを参照）のコアアイデアを維持することは、nginxプロセスとphp-fpmプロセスを別々のコンテナーに入れることには意味があります。
nginxとphp-fpmの間の通信はfastcgiを介して行われるため、php-fpmコンテナーは別のホスト上に置くこともできます。これにより、nginxの背後でphp-fpmコンテナーのクラスターを使用できます。
ここでコメントの壁がもう少し背景になった後、Dockerのドキュメントには、コンテナには1つの懸念しか持たないという考えについての段落があります。
Linuxコンテナ（lxc）の主なアイデアは、CPUおよびメモリレベルで分離されたネームスペースでプロセスを実行することです。これに加えて、Dockerはファイルシステムレベルで分離を追加します。
利点は、この名前空間内のプロセスの妥協により、他のプロセスのメモリの読み取りが許可されないため、ホスト上の他の妥協が防止されることです。
nginxとphp-fpmについて話しているとき、それらはペアで機能しますが、それぞれに懸念があり、nginxはHTTP部分、ルーティング、ヘッダー検証などを行い、php-fpmはコード解釈を行い、html部分をnginxに返します。両方が一緒に必須ではない単一のアプリケーションにサービスを提供するのが通常です。
コンテキストによっては、アプリケーションのスタック全体を含むコンテナを、たとえば開発者向けのワークステーションに用意する方が簡単な場合があります。しかし、実稼働環境での使用に理想的なのは、コンテナー内でのやり取りをできるだけ少なくすることです。同じコンテナー内でプロセスを監視し、supervisordを使用すると、ゾンビプロセスとログ処理の点で問題が発生します（ここでは、説明のみを目的とした例です）。
最後に、ドッカーページを引用して強調します。
「コンテナごとに1つのプロセス」が大まかな目安となりますが、それは難しくて速いルールではありません。コンテナをできるだけ清潔でモジュール式に保つために、最善の判断をしてください。
すべてに当てはまる「銀の弾丸ルール」はありません。それは常に、コンテナ内の複雑さと、コンテナ自体を調整する複雑さのバランスです。
実際、ここで欠けている点の1つは、水平方向のスケーラビリティです。ずっと前にこれに対処したJamie Alquizaの記事があります。
要するに、より高いパフォーマンスを実現するためにphp-fpmを水平にスケーリングします。Nginx + php-fpmを一緒にスケーリングしてもメリットはありません。記事に記載されている内容を確認するために、ストレステスト（ツング、ガトリングなど。非常に古いおもちゃであるApache abはしないでください）を自分で行うことをお勧めします。私は個人的に、この記事が一般的に真実であることを証明したいくつかの現実世界の経験を持っています。
ただし、ベアメタルマシン/ VMには2つの欠点があります（Kubernetesにはない場合があります）。
編集済み：2019年のほぼ半分になりました。同じポッド内の古いモデルphp-fpm + nginxの使用方法は異なります。サービスメッシュに精通している場合、nginx（またはNginmeshと呼ばれるもの）は、東西行きのトラフィックを処理するサイドカーとして機能します。純粋なphp-fpmはそれを行うことができませんでしたが、東西行きのトラフィックは主にサービス間または他の派手な機能間の認証に使用されました。
2つのコンテナを管理することを上回る意味のある利点はありません。プロセス間に1対1の関係があり、それらが単一の目的を果たす限り、それらを同じコンテナに入れます。