<p>This could be solved by using <a href="https://github.com/nginx-proxy/docker-gen" rel="nofollow noreferrer">docker-gen</a> or <a href="https://github.com/nginx-proxy/nginx-proxy" rel="nofollow noreferrer">nginx-proxy</a> to simplify even more.</p>
<p>So this service will listen to the docker sock file (process) and whenever a container is up with a certain labels for customise the domain etc. It will create a vhost to that Nginx service and do the reload itself.</p>

CC BY-SA 4.0
2022-09-10T17:02:42.097Z
2022-09-10T17:39:03.193Z
2022-09-10T17:39:03.193Z
D8vjörk
<p>Here is <a href="https://github.com/UniqKey/s2i-nginx-php7-container/blob/master/7.2/Dockerfile" rel="nofollow noreferrer">nginx and php</a> done as an s2i builder image. You can basically have plain old php in a git repo and run s2i to make a runtime image that runs it with nginx and php. You simply docker build that dockerfile and pass the resultant image as the builder image to s2i along with your source code.</p>

<p>You will notice I have archived that project. That is because redhat have security patched image for php at <a href="https://access.redhat.com/containers/#/registry.access.redhat.com/rhscl/php-72-rhel7" rel="nofollow noreferrer">https://access.redhat.com/containers/#/registry.access.redhat.com/rhscl/php-72-rhel7</a> they happen to use apache httpd but since I don’t see that I use tell s2i “make a runtime container for my php code in git” and it just works and I get frequent security patches it’s way easier than messing around with my own dockerfile to do security patches. </p>

CC BY-SA 4.0
2019-01-30T08:25:22.973Z
Why your own image? You have this https://hub.docker.com/_/php which is the official one and it also comes with Apache
D8vjörk
CC BY-SA 4.0
2019-01-30T09:42:11.860Z
I said that I use a security parched 3rd party image and archived the one I wrote. Usually images on docker hub run as root (looking at the docker file of latest at your link it has no `USER` command to drop from root). Security teams on multi tenant k8s clusters don’t let you run containers that use root (eg I know one bank with 50,000 cpu support contracts for a commercial k8s distro). So I prefer to run out burins images that aren’t run as root and that have a security patching support. I find that most people starting out with docker don’t understand about container security.
simbo1905
CC BY-SA 4.0
2019-01-30T09:46:07.587Z
Also I prefer to have one image that makes application runtime images for all our micro services. The official images don’t solve that problem. So I use `s2i` images and have git hooks that trigger making a new application image but also a push trigger on the docker repository of my k8s cluster that rebuilds all of the images when I push a new security patched `s2i` image. So in short “doing docker” as per the framework official images isn’t really state of the art it’s kinda a “generation 1” approach that I have moved beyond. Checkout `s2i` and OKD BuildConfig see the latest innovations.
simbo1905
CC BY-SA 4.0
2019-01-30T09:51:11.303Z
The problem of it is that if you use Docker in production (as I imagined because of the security patched) you'll need a single container for each service Nginx and PHP-FPM because if you want to scale your app, you can replicate the PHP image instead of having multiple Nginx/Apache + PHP containers running
D8vjörk
CC BY-SA 4.0
2019-01-30T09:52:28.850Z
For the rest, you're right, Docker is not the best on security and I'll modify my images following the USER approach for it (right now the official Nginx image is the only one using this)
D8vjörk
CC BY-SA 4.0
2019-01-30T10:06:58.070Z
We run in production. We scale replicas of our pods. So I am not sure which problems you mean? I am talking about security. I prefer not to expose php directly and that’s how the security patched images comes. If that takes a bit of memory on my k8s cluster that’s fine by me. I also prefer s2i and not running as root. So I see three potential problems with running the images you suggest. Once again most folks are happy with the historic way of doing things if that works for folks then great.
simbo1905
CC BY-SA 4.0
2019-01-30T12:34:46.447Z
openshift k8s runs as a random high UID so all the long term support s2i images work that way. The cost is anything that looks up current UID in /etc/passwd causes you to have to add a few lines to fake a line without being root. Most web frameworks don’t need this so  not an issue for the added security. From a culture perspective I am often bemused by devs who don’t understand security demanding they control the dockerfile. with great power comes great responsibility and most devs should avoid that particular aspect and adapt to use s2i where the folks focusing on security supply the image.
simbo1905
CC BY-SA 4.0
2019-01-29T09:13:23.900Z
2019-01-29T09:13:23.900Z
simbo1905
<p>Using Apache v2.4+ with mod_php disabled, php-fpm enabled, and mpm_event (instead of default mpm_prefork) provides better performance (and tuning options, IMO) for PHP/PHP-FPM and multi-threaded processes. Using nginx as the front-end web server in a &quot;selective reverse proxy to apache2/httpd for PHP processes&quot; will still offer the added benefits of the superior static file serving, caching options + simple reverse proxy + load balancing featureset of nginx and add the superior multi threaded performance of Apache.</p>
<p>My &quot;answer&quot; here, would be:
I recommend using Apache v2.4+ as a backend for PHP processes with nginx as your &quot;public facing&quot; reverse-proxy. The primary concern seems to be for scalability, so I think that my suggestion would provide greater scalability and reduce resource consumption &quot;at scale&quot;, with only a minimal increase in resource consumption at idle.</p>
<p>==============================
This is where my curiosity kicks in (aka feeling curious, might delete later, idk):</p>
<p>Sorry if I'm necromancing this thread here, but there is limited material and content on this subject matter of splitting off PHP-FPM into a separate container from the web server.</p>
<p><a href="https://devops.stackexchange.com/questions/12361/what-is-the-purpose-of-running-php-fpm-in-its-own-container-instead-in-the-same">I've asked about this very topic here</a>, and here in the OP there is a vague mention of &quot;scalability reasons&quot;.</p>
<p>Though my &quot;answer&quot; doesn't actually answer the question proposed in the OP... This is me proposing a solution by asking: &quot;is this really the right question in the first place?&quot;</p>
<p>I agree with the ultimate point @simbo1905 is trying to make, here. Just use the same container for the web server + php-fpm.</p>
<p>But...</p>
<p>What is it about breaking off PHP-FPM from the web server (in this case: nginx) increases the scalability of an application? Why not use multiple instances of matching containers with nginx+php-fpm running together? Just as the answer by @simbo1905 suggests with apache2+php-fpm?</p>
<p>I see the points being made about security and scalability. I understand the concept of scaling up instances of php-fpm containers under heavy load, but nginx makes it VERY easy to load balance such load. Why not have the added benefit of additional load balanced resources if you are concerned about resource the resource usage php-fpm being scalable?</p>
<p>I'm not sure what the benefits are of having a separate PHP-FPM instance running are if you could just &quot;spend&quot; the extra tiny kb's of disk space and RAM for a more stable and performant application. If the PHP-FPM process(es) or the nginx process(es) fail, the application fails.</p>
<p>The case for making PHP/PHP-FPM &quot;more secure&quot; by having separated containers seems moot, also, considering the layers of protection to the PHP engine that are locked down by system users/groups with appropriate permissions. If anything, it seems like a larger attack surface for malicious actors to be able to pinpoint the port(s) that PHP-FPM is running on, instead of the &quot;same system default&quot; of connecting to php-fpm via unix socket(s).</p>
<p>All that said, I'm mostly asking for personal curiosity. I'm somewhat new to the nuances and performance tuning of Docker/Kubernetes, so I feel like there might be something I'm missing. In the research I've done, sometime around late 2019, many Devs/DevOps/Engineers seem to have started to lean towards putting EVERY service in its own separate container with PHP-FPM dependent applications. I have not yet wrapped my head around &quot;why&quot;. It makes sense to me having a separate SQL/Datastore container. It also makes sense to me to isolate the web server in use cases where PHP/php-fpm or some other web server dependent service isn't required as a core function of the entire application. But in the cases where you need both the web server(s) and the back-end services to work in concert, I have yet to understand why the need to separate them.</p>

CC BY-SA 4.0
2020-09-07T15:11:30.670Z
2020-09-07T15:11:30.670Z
CoolElectricity
<p>I have a Docker setup for my project with PHP-FPM, Nginx and many other services required by the application, but inside the PHP app I've to check the <code>init.d/nginx configtest</code> for new dynamic Vhosts (which are shared by volumes) generated for a tenancy based service. </p>

<p>The main thing its that I dont want to make a single container with PHP-FPM and Nginx for scalability reasons.</p>

<p>My idea is to use any Linux package for watch any change on a folder (Vhosts folder in my case) and test and then reload the service.</p>

<p>Any suggestion?</p>

<p>Note: I've RabbitMQ in one container which is used by the PHP application but now I need to connect it with the Nginx-based container (I don't know if there's a CLI or linux native client for this).</p>

CC BY-SA 4.0
2019-01-28T15:17:47.023Z
Why not use volumes to do that ? Bind the file to both machines.
jayooin
CC BY-SA 4.0
2019-01-30T12:59:14.597Z
@jayooin I've already, the problem is for share the response of the command nginx configtest
D8vjörk
<docker><nginx><php>
PHP-FPM with Nginx in different containers (share init.d response between)
D8vjörk
# PHP-FPM with Nginx in different containers (share init.d response between)

(Asked by: username_0 on 2019-01-28)

I have a Docker setup for my project with PHP-FPM, Nginx and many other services required by the application, but inside the PHP app I've to check the `init.d/nginx configtest` for new dynamic Vhosts (which are shared by volumes) generated for a tenancy based service.

The main thing its that I dont want to make a single container with PHP-FPM and Nginx for scalability reasons.

My idea is to use any Linux package for watch any change on a folder (Vhosts folder in my case) and test and then reload the service.

Any suggestion?

Note: I've RabbitMQ in one container which is used by the PHP application but now I need to connect it with the Nginx-based container (I don't know if there's a CLI or linux native client for this).

**Tags:** docker, nginx, php

> **Comments:**
> **username_1**: Why not use volumes to do that ? Bind the file to both machines.  
> **username_0**: @username_1 I've already, the problem is for share the response of the command nginx configtest  

---

## 3 answers

### Answer by username_0 on 2022-09-10. Score: 0 | Accepted answer

This could be solved by using [docker-gen](https://github.com/nginx-proxy/docker-gen) or [nginx-proxy](https://github.com/nginx-proxy/nginx-proxy) to simplify even more.

So this service will listen to the docker sock file (process) and whenever a container is up with a certain labels for customise the domain etc. It will create a vhost to that Nginx service and do the reload itself.


---

### Answer by username_2 on 2019-01-29. Score: 1

Here is [nginx and php](https://github.com/UniqKey/s2i-nginx-php7-container/blob/master/7.2/Dockerfile) done as an s2i builder image. You can basically have plain old php in a git repo and run s2i to make a runtime image that runs it with nginx and php. You simply docker build that dockerfile and pass the resultant image as the builder image to s2i along with your source code.

You will notice I have archived that project. That is because redhat have security patched image for php at <https://access.redhat.com/containers/#/registry.access.redhat.com/rhscl/php-72-rhel7> they happen to use apache httpd but since I don’t see that I use tell s2i “make a runtime container for my php code in git” and it just works and I get frequent security patches it’s way easier than messing around with my own dockerfile to do security patches.

> **Comments:**
> **username_0**: Why your own image? You have this https://hub.docker.com/_/php which is the official one and it also comes with Apache  
> **username_2**: I said that I use a security parched 3rd party image and archived the one I wrote. Usually images on docker hub run as root (looking at the docker file of latest at your link it has no `USER` command to drop from root). Security teams on multi tenant k8s clusters don’t let you run containers that use root (eg I know one bank with 50,000 cpu support contracts for a commercial k8s distro). So I prefer to run out burins images that aren’t run as root and that have a security patching support. I find that most people starting out with docker don’t understand about container security.  
> **username_2**: Also I prefer to have one image that makes application runtime images for all our micro services. The official images don’t solve that problem. So I use `s2i` images and have git hooks that trigger making a new application image but also a push trigger on the docker repository of my k8s cluster that rebuilds all of the images when I push a new security patched `s2i` image. So in short “doing docker” as per the framework official images isn’t really state of the art it’s kinda a “generation 1” approach that I have moved beyond. Checkout `s2i` and OKD BuildConfig see the latest innovations.  
> **username_0**: The problem of it is that if you use Docker in production (as I imagined because of the security patched) you'll need a single container for each service Nginx and PHP-FPM because if you want to scale your app, you can replicate the PHP image instead of having multiple Nginx/Apache + PHP containers running  
> **username_0**: For the rest, you're right, Docker is not the best on security and I'll modify my images following the USER approach for it (right now the official Nginx image is the only one using this)  
> **username_2**: We run in production. We scale replicas of our pods. So I am not sure which problems you mean? I am talking about security. I prefer not to expose php directly and that’s how the security patched images comes. If that takes a bit of memory on my k8s cluster that’s fine by me. I also prefer s2i and not running as root. So I see three potential problems with running the images you suggest. Once again most folks are happy with the historic way of doing things if that works for folks then great.  
> **username_2**: openshift k8s runs as a random high UID so all the long term support s2i images work that way. The cost is anything that looks up current UID in /etc/passwd causes you to have to add a few lines to fake a line without being root. Most web frameworks don’t need this so  not an issue for the added security. From a culture perspective I am often bemused by devs who don’t understand security demanding they control the dockerfile. with great power comes great responsibility and most devs should avoid that particular aspect and adapt to use s2i where the folks focusing on security supply the image.  

---

### Answer by username_3 on 2020-09-07. Score: 0

Using Apache v2.4+ with mod\_php disabled, php-fpm enabled, and mpm\_event (instead of default mpm\_prefork) provides better performance (and tuning options, IMO) for PHP/PHP-FPM and multi-threaded processes. Using nginx as the front-end web server in a "selective reverse proxy to apache2/httpd for PHP processes" will still offer the added benefits of the superior static file serving, caching options + simple reverse proxy + load balancing featureset of nginx and add the superior multi threaded performance of Apache.

My "answer" here, would be:
I recommend using Apache v2.4+ as a backend for PHP processes with nginx as your "public facing" reverse-proxy. The primary concern seems to be for scalability, so I think that my suggestion would provide greater scalability and reduce resource consumption "at scale", with only a minimal increase in resource consumption at idle.

==============================
This is where my curiosity kicks in (aka feeling curious, might delete later, idk):

Sorry if I'm necromancing this thread here, but there is limited material and content on this subject matter of splitting off PHP-FPM into a separate container from the web server.

[I've asked about this very topic here](https://devops.stackexchange.com/questions/12361/what-is-the-purpose-of-running-php-fpm-in-its-own-container-instead-in-the-same), and here in the OP there is a vague mention of "scalability reasons".

Though my "answer" doesn't actually answer the question proposed in the OP... This is me proposing a solution by asking: "is this really the right question in the first place?"

I agree with the ultimate point @username_2 is trying to make, here. Just use the same container for the web server + php-fpm.

But...

What is it about breaking off PHP-FPM from the web server (in this case: nginx) increases the scalability of an application? Why not use multiple instances of matching containers with nginx+php-fpm running together? Just as the answer by @username_2 suggests with apache2+php-fpm?

I see the points being made about security and scalability. I understand the concept of scaling up instances of php-fpm containers under heavy load, but nginx makes it VERY easy to load balance such load. Why not have the added benefit of additional load balanced resources if you are concerned about resource the resource usage php-fpm being scalable?

I'm not sure what the benefits are of having a separate PHP-FPM instance running are if you could just "spend" the extra tiny kb's of disk space and RAM for a more stable and performant application. If the PHP-FPM process(es) or the nginx process(es) fail, the application fails.

The case for making PHP/PHP-FPM "more secure" by having separated containers seems moot, also, considering the layers of protection to the PHP engine that are locked down by system users/groups with appropriate permissions. If anything, it seems like a larger attack surface for malicious actors to be able to pinpoint the port(s) that PHP-FPM is running on, instead of the "same system default" of connecting to php-fpm via unix socket(s).

All that said, I'm mostly asking for personal curiosity. I'm somewhat new to the nuances and performance tuning of Docker/Kubernetes, so I feel like there might be something I'm missing. In the research I've done, sometime around late 2019, many Devs/DevOps/Engineers seem to have started to lean towards putting EVERY service in its own separate container with PHP-FPM dependent applications. I have not yet wrapped my head around "why". It makes sense to me having a separate SQL/Datastore container. It also makes sense to me to isolate the web server in use cases where PHP/php-fpm or some other web server dependent service isn't required as a core function of the entire application. But in the cases where you need both the web server(s) and the back-end services to work in concert, I have yet to understand why the need to separate them.


---

