<p>There is no meaningful benefit that outweighs having to manage two containers. As long as you have a 1:1 relationship between the processes and they serve a single purpose, put them in the same container. </p>

CC BY-SA 3.0
2017-09-20T13:06:48.480Z
Do you mean different images on the same container?
CarlosAS
CC BY-SA 3.0
2017-09-20T14:49:56.117Z
How will you start nginx and php-fpm in the same container? Please add an example.
030
CC BY-SA 3.0
2017-09-20T15:24:54.117Z
@030 [here](https://hub.docker.com/r/richarvey/nginx-php-fpm/) an example
CarlosAS
CC BY-SA 3.0
2017-09-20T17:41:14.263Z
@carlos Very valid exemple for dev purposes, I'd block this kind of things for production use (running supervisord within a container can turn in a footgun quite easily)
Tensibai
CC BY-SA 3.0
2017-09-20T18:30:14.693Z
I disagree with that answer, with this reasoning a apache server with mod security talking to a tomcat talking to a postgresql server hosting only one app should fit within a single container.
Tensibai
CC BY-SA 3.0
2017-09-20T22:19:24.107Z
@Tensibi your example doesn't apply to my answer, because a database doesn't have a 1:1 relationship to a web/app service. You normally have many applications talking to few database servers. If it was a distributed database and you never needed any other service to speak to it, then it might be worth considering. A modsec layer is usually shared across services, so I also do not think it applies here.
user2640621
CC BY-SA 3.0
2017-09-20T22:27:40.563Z
@CarlosAS Thank you for adding a link to an example. The dockerfile is quite large and that makes it more difficult to troubleshoot possible issues. I prefer that every container has its own responsibility.
030
CC BY-SA 3.0
2017-09-20T22:35:45.027Z
@user one DB per app to avoid DB impact from one app to another. I agree the comment was a tad caricatural including mod security, but there's nothing preventing it. Returning your comment, there's no reason to dedicate one php-fpm daemon to a single app either, as there's none to dedicate one nginx server per app. Otoh there's reasons to have a cluster of php-fpm daemons behind a single nginx for performance purposes, weighting toward the separation of concerns. At this point I think I'll extend my answer when I can
Tensibai
CC BY-SA 3.0
2017-09-20T10:52:01.233Z
2017-09-20T10:52:01.233Z
user2640621
<p>Actually, one missing point here is the horizontal scalability. There's an article from Jamie Alquiza long time ago addressed this:</p>
<p><a href="http://archive.is/pDzz0" rel="nofollow noreferrer">http://archive.is/pDzz0</a></p>
<p>In short, you scale your php-fpm horizontally for reaching higher performance. Scaling Nginx+php-fpm together does not bring you any benefit. I encourage you do some stress testing (e.g. Tsung, Gatling, etc.; please don't do Apache ab, that is a very old toy) yourself to verify what the article stated. I personally have several real world experiences proved the article is true in general.</p>
<p>But there're two drawback (maybe not for Kubernetes) for bare metal machines / VMs:</p>
<ol>
<li>How to configure Nginx dynamically discover php-fpm container changes? This is the easy part.</li>
<li>How do we share the same volume / file systems after scaling? Nginx and php-fpm containers should read exactly the same content to reach consistency. This leaves you the least complicated puzzle piece (and the most fun part) to work on.</li>
</ol>
<p>EDITED: Now it's almost halfway into the of year 2019. Old model, php-fpm+nginx in the same pod, has different usage. If you're familiar with service mesh, then nginx (or what so call Nginmesh) serves as a sidecar to handle east-west bound traffic. East-west bound traffic mostly used to authenticate among services, or other fancy functionalities, whereas pure &quot;php-fpm only&quot; containers could not do that alone.</p>

CC BY-SA 4.0
2018-01-15T02:23:43.863Z
2021-02-04T20:31:28.637Z
2021-02-04T20:31:28.637Z
Ming Hsieh
<p>The advantage is : you can run multiple php-fpm containers in back-end, we call it PHP cluster, via number of ports.
Example port 9000, 9001, 9002 .. and so on </p>

CC BY-SA 4.0
2019-01-22T07:45:41.107Z
2019-01-22T07:45:41.107Z
Dylan B
<p>PHP with nginx is usually done using php-fpm which is a separate processus.</p>

<p>Keeping the core idea of docker of one process (see end of answer for more details on this point) per container this makes sense to have the nginx process and php-fpm process in separate containers.</p>

<p>As the communication between nginx and php-fpm arise through fastcgi the php-fpm container can also be on a separated host and this allows using a cluster of php-fpm containers behind nginx.</p>

<p>After the wall of comment here's a little more background, docker documentation have paragraph about the idea that <a href="https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#each-container-should-have-only-one-concern" rel="noreferrer">a container should have only one concern</a>.</p>

<p>The main idea of a linux container (<strong>lxc</strong>) is to run a process in an isolated namespace at the cpu and memory level, docker add on top of this an isolation at the filesystem level.<br>
The advantage is that the compromission of a process within this namespace won't allow to read memory of other processes and as such should prevent other compromission on the host.</p>

<p>While talking about nginx and php-fpm, they work in pair but each has it's own concern, nginx will do the HTTP part, routing, headers validation, etc. and php-fpm will do the code interpretation and return the html part to nginx. While it's usual to have both together serving a single application that's not mandatory.</p>

<p>Depending on context it may be easier to have a container including the whole stack for an application, on a developer workstation for exemple. But ideally for production use, try to keep the fewer interaction inside the container, having separated processes in the same container with supervisord brings its share of problem in term of zombie process and log handling (exemple story <a href="https://www.google.fr/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=1&amp;cad=rja&amp;uact=8&amp;ved=0ahUKEwi6u6DSsbjWAhVmqFQKHcGjBXwQFggnMAA&amp;url=https%3A%2F%2Fblog.deimos.fr%2F2016%2F01%2F13%2Fdocker-why-you-should-use-monit-instead-of-supervisord%2F&amp;usg=AFQjCNGSFNEpM5C7dTlLQ1czMyW89FFepw" rel="noreferrer">here</a> for illustration purpose only).</p>

<p>So finally I'll quote the docker page with some emphasis:</p>

<blockquote>
  <p>While “one process per container” is frequently a good rule of thumb, it is not a hard and fast rule. <strong>Use your best judgment to keep containers as clean and modular as possible</strong>.</p>
</blockquote>

<p>There's no "silver bullet rule" which apply to everything, it's always a balance between the complexity within the container and the complexity orchestrating the containers themselves.</p>

CC BY-SA 3.0
2017-09-20T10:41:33.707Z
The core idea is actually "Each container should have only one concern", and "it is not necessarily true that there should be only one operating system process per container". https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#avoid-installing-unnecessary-packages
user2640621
CC BY-SA 3.0
2017-09-20T10:54:25.783Z
I admit it's a shortcut to strike the idea, nginx is not a single monolithic process nor is php-fpm, but replace process by concern in my answer and it is still OK nginx does the routing, php-fpm does the interpretation
Tensibai
CC BY-SA 3.0
2017-09-20T16:26:26.083Z
The answer is usually one service one port per container, not really one process. On the other hand, if you have multiple running processes in a container, you need to consider some init process, service management, restarts, independent logging, independent package dependencies, it gets a bit more complicated. And sometimes 1:1 mapping turns into 1:n mapping when scaling.
Jiri Klouda
CC BY-SA 3.0
2017-09-20T18:27:59.017Z
@Jiri playing devil's advocate: so a apache in front of a rails app using a postgres DB should go within the same container? That's just one service in an external point of view after all.
Tensibai
CC BY-SA 3.0
2017-09-20T18:32:00.080Z
It is context dependent, but it might be the case. It all depends on the architecture. But one could argue that in cases where that would be the case, some more lightweight technology choices could have been made.
Jiri Klouda
CC BY-SA 3.0
2017-09-20T18:45:23.267Z
@Jiri this also mean you're defeating the purpose of namespacing the processes as a breach in one can allow access to the memory of all others, and so using a container doesn't make more sense than using a host. (the opposite argument, which I tend to follow for production use to avoid a web server flaw allowing to read the DB memory)
Tensibai
CC BY-SA 3.0
2017-09-20T18:51:40.257Z
@jiri I mean the only valid context I can think of for this is a container running on a dev workstation for tests purposes before a push, not something to advertise too much as an entry point. And this question is an entry point
Tensibai
CC BY-SA 3.0
2017-09-22T01:55:11.360Z
It is all about deployment. If there is a complex service that requires 7-8 processes to run and orchestrate, you are pulling all the orchestration outside the container. So some form of deployment instructions need to travel with the containers to orchestrate them properly, the other containers are potentially exposed to unless you have security profile accompany it, its a mess.
Jiri Klouda
CC BY-SA 3.0
2017-09-22T08:34:00.367Z
@JiriKlouda answer amended, I hope it's detailed enough to convey all the points raised in comments.
Tensibai
CC BY-SA 3.0
2017-09-22T08:34:30.667Z
@user2640621 I've amended my answer, I'm taker of your feedback on this version
Tensibai
CC BY-SA 3.0
2017-09-20T09:49:23.963Z
2018-01-16T15:20:21.563Z
2018-01-16T15:20:21.563Z
Tensibai
<p>I just started working with Docker and Kubernetes and I've been watching a lot of stacks, in which some people build nginx+php in a single image and some build an image with nginx and another one with php (mounting the same path and enclosing both containers in the same deployment in Kubernetes).</p>

<p>What would be the advantages of building two docker images instead of installing both nginx+php in the same one?</p>

<docker><dockerfile>
What are the advantages of dockerizing nginx and php in different containers?
CarlosAS
# What are the advantages of dockerizing nginx and php in different containers?

(Asked by: username_0 on 2017-09-20)

I just started working with Docker and Kubernetes and I've been watching a lot of stacks, in which some people build nginx+php in a single image and some build an image with nginx and another one with php (mounting the same path and enclosing both containers in the same deployment in Kubernetes).

What would be the advantages of building two docker images instead of installing both nginx+php in the same one?

**Tags:** docker, dockerfile


---

## 4 answers

### Answer by username_3 on 2017-09-20. Score: 22 | Accepted answer

PHP with nginx is usually done using php-fpm which is a separate processus.

Keeping the core idea of docker of one process (see end of answer for more details on this point) per container this makes sense to have the nginx process and php-fpm process in separate containers.

As the communication between nginx and php-fpm arise through fastcgi the php-fpm container can also be on a separated host and this allows using a cluster of php-fpm containers behind nginx.

After the wall of comment here's a little more background, docker documentation have paragraph about the idea that [a container should have only one concern](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#each-container-should-have-only-one-concern).

The main idea of a linux container (**lxc**) is to run a process in an isolated namespace at the cpu and memory level, docker add on top of this an isolation at the filesystem level.  
The advantage is that the compromission of a process within this namespace won't allow to read memory of other processes and as such should prevent other compromission on the host.

While talking about nginx and php-fpm, they work in pair but each has it's own concern, nginx will do the HTTP part, routing, headers validation, etc. and php-fpm will do the code interpretation and return the html part to nginx. While it's usual to have both together serving a single application that's not mandatory.

Depending on context it may be easier to have a container including the whole stack for an application, on a developer workstation for exemple. But ideally for production use, try to keep the fewer interaction inside the container, having separated processes in the same container with supervisord brings its share of problem in term of zombie process and log handling (exemple story [here](https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi6u6DSsbjWAhVmqFQKHcGjBXwQFggnMAA&url=https%3A%2F%2Fblog.deimos.fr%2F2016%2F01%2F13%2Fdocker-why-you-should-use-monit-instead-of-supervisord%2F&usg=AFQjCNGSFNEpM5C7dTlLQ1czMyW89FFepw) for illustration purpose only).

So finally I'll quote the docker page with some emphasis:

> While “one process per container” is frequently a good rule of thumb, it is not a hard and fast rule. **Use your best judgment to keep containers as clean and modular as possible**.

There's no "silver bullet rule" which apply to everything, it's always a balance between the complexity within the container and the complexity orchestrating the containers themselves.

> **Comments:**
> **username_1**: The core idea is actually "Each container should have only one concern", and "it is not necessarily true that there should be only one operating system process per container". https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#avoid-installing-unnecessary-packages  
> **username_3**: I admit it's a shortcut to strike the idea, nginx is not a single monolithic process nor is php-fpm, but replace process by concern in my answer and it is still OK nginx does the routing, php-fpm does the interpretation  
> **username_6**: The answer is usually one service one port per container, not really one process. On the other hand, if you have multiple running processes in a container, you need to consider some init process, service management, restarts, independent logging, independent package dependencies, it gets a bit more complicated. And sometimes 1:1 mapping turns into 1:n mapping when scaling.  
> **username_3**: @Jiri playing devil's advocate: so a apache in front of a rails app using a postgres DB should go within the same container? That's just one service in an external point of view after all.  
> **username_6**: It is context dependent, but it might be the case. It all depends on the architecture. But one could argue that in cases where that would be the case, some more lightweight technology choices could have been made.  
> **username_3**: @Jiri this also mean you're defeating the purpose of namespacing the processes as a breach in one can allow access to the memory of all others, and so using a container doesn't make more sense than using a host. (the opposite argument, which I tend to follow for production use to avoid a web server flaw allowing to read the DB memory)  
> **username_3**: @jiri I mean the only valid context I can think of for this is a container running on a dev workstation for tests purposes before a push, not something to advertise too much as an entry point. And this question is an entry point  
> **username_6**: It is all about deployment. If there is a complex service that requires 7-8 processes to run and orchestrate, you are pulling all the orchestration outside the container. So some form of deployment instructions need to travel with the containers to orchestrate them properly, the other containers are potentially exposed to unless you have security profile accompany it, its a mess.  
> **username_3**: @JiriKlouda answer amended, I hope it's detailed enough to convey all the points raised in comments.  
> **username_3**: @username_1 I've amended my answer, I'm taker of your feedback on this version  

---

### Answer by username_1 on 2017-09-20. Score: 5

There is no meaningful benefit that outweighs having to manage two containers. As long as you have a 1:1 relationship between the processes and they serve a single purpose, put them in the same container.

> **Comments:**
> **username_0**: Do you mean different images on the same container?  
> **username_2**: How will you start nginx and php-fpm in the same container? Please add an example.  
> **username_0**: @username_2 [here](https://hub.docker.com/r/richarvey/nginx-php-fpm/) an example  
> **username_3**: @carlos Very valid exemple for dev purposes, I'd block this kind of things for production use (running supervisord within a container can turn in a footgun quite easily)  
> **username_3**: I disagree with that answer, with this reasoning a apache server with mod security talking to a tomcat talking to a postgresql server hosting only one app should fit within a single container.  
> **username_1**: @Tensibi your example doesn't apply to my answer, because a database doesn't have a 1:1 relationship to a web/app service. You normally have many applications talking to few database servers. If it was a distributed database and you never needed any other service to speak to it, then it might be worth considering. A modsec layer is usually shared across services, so I also do not think it applies here.  
> **username_2**: @username_0 Thank you for adding a link to an example. The dockerfile is quite large and that makes it more difficult to troubleshoot possible issues. I prefer that every container has its own responsibility.  
> **username_3**: @user one DB per app to avoid DB impact from one app to another. I agree the comment was a tad caricatural including mod security, but there's nothing preventing it. Returning your comment, there's no reason to dedicate one php-fpm daemon to a single app either, as there's none to dedicate one nginx server per app. Otoh there's reasons to have a cluster of php-fpm daemons behind a single nginx for performance purposes, weighting toward the separation of concerns. At this point I think I'll extend my answer when I can  

---

### Answer by username_4 on 2018-01-15. Score: 4

Actually, one missing point here is the horizontal scalability. There's an article from Jamie Alquiza long time ago addressed this:

<http://archive.is/pDzz0>

In short, you scale your php-fpm horizontally for reaching higher performance. Scaling Nginx+php-fpm together does not bring you any benefit. I encourage you do some stress testing (e.g. Tsung, Gatling, etc.; please don't do Apache ab, that is a very old toy) yourself to verify what the article stated. I personally have several real world experiences proved the article is true in general.

But there're two drawback (maybe not for Kubernetes) for bare metal machines / VMs:

1. How to configure Nginx dynamically discover php-fpm container changes? This is the easy part.
2. How do we share the same volume / file systems after scaling? Nginx and php-fpm containers should read exactly the same content to reach consistency. This leaves you the least complicated puzzle piece (and the most fun part) to work on.

EDITED: Now it's almost halfway into the of year 2019. Old model, php-fpm+nginx in the same pod, has different usage. If you're familiar with service mesh, then nginx (or what so call Nginmesh) serves as a sidecar to handle east-west bound traffic. East-west bound traffic mostly used to authenticate among services, or other fancy functionalities, whereas pure "php-fpm only" containers could not do that alone.


---

### Answer by username_5 on 2019-01-22. Score: -1

The advantage is : you can run multiple php-fpm containers in back-end, we call it PHP cluster, via number of ports.
Example port 9000, 9001, 9002 .. and so on


---

