PHP-FPM with Nginx in different containers (share init.d response between)

Question

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).

Answer 1

Here is nginx and php 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.

Answer 2

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, 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 @simbo1905 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 @simbo1905 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.

Answer 3

This could be solved by using docker-gen or 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.