<p>We're hosting a lot of different applications on our Kubernetes cluster already - mostly Java based.</p>

<p>For PHP-FPM + Nginx our approach is currently, that we're building a container, which includes PHP-FPM, Nginx and the PHP application source code.
But this actually breaks with the one-process-per-container docker rule, so we were thinking on how to improve it.
We tried to replace it by using a pod with multiple containers - a nginx and a PHP container.</p>

<p>The big question is now where to put the source code. My initial idea was to use a data-only container, which we mount to the nginx and PHP-FPM container. The problem is, that there's seems to be no way to do this in Kubernetes <a href="https://github.com/kubernetes/kubernetes/issues/831" rel="noreferrer">yet</a>.</p>

<p>The only approach that I see is creating a sidecar container, which contains the source code and copies it to an emptyDir volume which is shared between the containers in the pod.</p>

<p>My question: Is there a good approach for PHP-FPM + Nginx and a data container on Kubernetes, or what is best practice to host PHP on Kubernetes (maybe still using one container for everything)?</p>

<p>This is a good question because there is an important distinction that gets elided in most coverage of container architecture- that between multithreaded or event-driven service applications and multiprocess service applications. </p>

<p>Multithreaded and event-driven service applications are able with a single process to handle multiple service requests concurrently. </p>

<p>Multiprocess service applications are not.</p>

<p>Kubernetes workload management machinery is completely agnostic as to the real request concurrency level a given service is facing- agnostic in the sense that different concurrency rates by themselves do not have any impact on automated workload sizing or scaling. </p>

<p>The underlying assumption, however, is that a given unit of deployment- a pod- is able to handle multiple requests concurrently.</p>

<p>PHP in nearly all deployment models is multiprocess. It requires multiple processes to be able to handle concurrent requests in a single deployment unit. Whether those processes are coordinated by FPM or by some other machinery is an implementation detail. </p>

<p>So- it's fine to run nginx + FPM + PHP in a single container, even though it's not a single process. The number of processes itself doesn't matter- there is actually no rule in Docker about this. The ability to support concurrency does matter. One wants to deploy in a container/pod the minimal system to support concurrent requests, and in the case of PHP, usually putting it all in a single container is simplest.</p>
