1

I'm fairly new to Docker so excuse any obvious ignorance or misunderstandings. That said, I've been coding and configuring web applications for a long time now. I have recently been dabbling with some more sophisticated (Docker and "traditional") web/application server setups and experimenting with performance enhancements and simplifying deployments.

My personal favorite configuration to use for most projects thus far is nginx as a (mostly) "static file" web server &&|| caching mechanism &&|| Load Balancer in a reverse proxy config with Apache v2.4+ as the "backend" which runs PHP (also Perl &&|| Python) in a "FastCGI" (PHP-FPM) configuration (with mod_php disabled) and mpm_events (instead of mpm_prefork). We can always add in something else also such as REDIS or memcached, where applicable (but I rarely see a significant performance gain when using Cloudflare caching).

I've been dabbling with a few different ways to keep my "favorite web server composition" flexible and "ephemeral" enough to accommodate any and all possible options for further performance gain or resource load management. What I keep seeing is that there seems to have been a shift towards using PHP-FPM in its own separate "stand-alone" Docker container sometimes around late 2019.

Why?

While I can appreciate keeping resources isolated and separate for an easier to debug/config/secure configuration(s), I don't fully understand what the benefits are to having PHP-FPM in a separate Docker container that is implicitly REQUIRED by the application that the Docker containers are comprising.

If anything, having a separate PHP-FPM container seems like additional configuration, additional resource consumption and an even more complicated build/deploy consideration in a CI/CD pipeline.

I can even get onboard with "simple preference", such as instead of using Apache2 and nginx on the same Ubuntu/Debian or RHEL/CentOS container, break off nginx into its own container(s) and simply config your hostname(s) &&|| IPs and ports appropriately.

But what is a practical use case and advantages for having PHP-FPM separated from Apache or nginx containers for any additional benefit beyond perhaps using more Dockerfile &&|| docker-compose.yaml and less ba.sh scripting to get the same job done? If any part of the application fails or falters, then functionality will suffer. The additional network &&|| docker-network communications and hostname resolutions seems like it would just be a performance penalty over combining certain aspects of the docker-composer-ed application together, rather than splitting them up simply for the sake of splitting them up.

  • 1
    This is, by far, the best synopsis that I've found on this subject thus far, from 2017-2018: "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." - devops.stackexchange.com/a/2090/9877 – K8sN0v1c3 Sep 7 '20 at 15:31
  • Same OP as above comment has this to say, with an older link to an interesting article (a case FOR separation of a php-fpm container from the web server container) - devops.stackexchange.com/a/3080/9877 – K8sN0v1c3 Sep 7 '20 at 18:28

Your Answer

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

Browse other questions tagged or ask your own question.