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

  • Why not use volumes to do that ? Bind the file to both machines. – jayooin Jan 28 '19 at 15:17
  • @jayooin I've already, the problem is for share the response of the command nginx configtest – D8vjörk Jan 30 '19 at 12:59

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.

  • Why your own image? You have this hub.docker.com/_/php which is the official one and it also comes with Apache – D8vjörk Jan 30 '19 at 8:25
  • 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 Jan 30 '19 at 9:42
  • 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 Jan 30 '19 at 9:46
  • 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 Jan 30 '19 at 9:51
  • 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 Jan 30 '19 at 9:52

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.