Categories


Archives


Recent Posts


Categories


Five Reasons Your PHP Application is Hard to Containerize for Production

astorm

Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

Updated for Magento 2! No Frills Magento Layout is the only Magento front end book you'll ever need. Get your copy today!

First — the container/docker/K8s approach presumes that your application can easily run as a stand-alone Linux process and PHP applications aren’t stand-alone processes. PHP itself doesn’t handle incoming HTTP requests (hello Swoole/async users I see you but you’re still a small niche in the PHP world, this isn’t for you). There’s almost always a web server like apache, nginx, or LiteSpeed sitting in front of PHP handling incoming requests.

Right out of the gate you need to decide

  1. Apache and mod_php?
  2. Litespeed and the LiteSpeed SAPI?
  3. Apache and PHP-FPM?
  4. Nginx and PHP-FPM?
  5. Other combinations less known to me, etc.?

Additionally — if you chose an approach like FastCGI you’ll need to decide whether your web server and FastCGI/PHP-FPM server are in the same process-space/container or if they’re in separate process-spaces/containers.

Second — there’s the PHP command line. Since PHP applications aren’t persistent in memory like a Node.js or Java application it’s very common for there to be a cron process running that handles things like log rotation, index rebuilding, etc. The PHP command line that runs the cron is a separate concern and in a containerized approach almost becomes a second application you need to deploy and maintain.

Third — PHP’s extension architecture. There’s no universal PHP binary that runs programs. PHP’s core runtime architecture is extension based. There are 72 extensions that some folks will consider part of core PHP, and other folks will consider optional. There’s also the wide world of pecl extensions — many of which folks consider hard requirements. These extensions can be compiled into the binary or enabled via shared .so files and php.ini configuration. What extensions will be there by default? How will users add new extensions to the system? If users need to compile their own extensions, what build tools and Linux distributions will your containers be based on?

Fourth — and more cultural than a strict technical requirement — most PHP applications have assumptions about access to a shared file system baked in. PHP’s built-in sessions work via the file system by default. Many complex MVC systems feature various levels of caching that default to the file system — often with options to skip the file system as a storage engine and use something like your database or Redis instead. So that’s needing to have your volumes story right straight out of the gate and possibly more containerized DB or cache processes to manage (or, more likely, a cloud DB/cache solution as container scaling and DB scaling are different worlds).

Finally — while all this is possible to do it puts the container orchestrator in a bit of a bind. Should she make these decisions for her users? Or should she build a container solution that handles every combination for her users? Or should she build a generic set of containers that allow her users to make these decisions for themselves? In an ideal world, it’s all of them — but time is the ultimate trade-off. Particularly with open-source work.

The end result? Drupal provides a dizzying array of tags with different Linux distributions and PHP versions. Laravel provides a new noun. The core PHP project side steps the issue and lets “the Docker community” build their images. Etc. So far containerization remains uneven and inconsistent across the PHP world and will likely stay that way.

Series Navigation<< Running Go Programs in Docker Scratch ContainersAccessing Docker Desktop’s Virtual Machine >>

Copyright © Alan Storm 1975 – 2023 All Rights Reserved

Originally Posted: 26th December 2022