Hacker News new | ask | show | jobs
by fideloper 1345 days ago
Removing php-fpm + nginx from a container sounds AMAZING to me. If I can just have one thing in a container (plus a code base), that would be a LOT simpler than:

nginx, php-fpm, some init system, and the convoluted configuration needed to get logs out via Docker's logging mechanism.

2 comments

What about having 1 Dockerfile but run php-fpm in 1 container with nginx in a 2nd container?

This pattern is common for background workers too, such as running gunicorn + celery in separate containers (Python tools) but the same image is used for both. You can change the CMD at runtime by overwriting it (for example the `command` property in Docker Compose and Kubernetes).

This avoids needing to hack around things at the Docker level to install an init system and it gives you a way to split things out at runtime so you individually scale and log them as needed.

It does mean a change in your app would restart nginx since the image would change for both but this isn't that big of a deal. If that was a deal breaker then you could create separate images for each one to still avoid an init system running in your container.

Very doable. Although on systems like Fly where you attempt to build one container to run an app, it’s a bit overkill.

What I dislike most about php-fpm is the logging mechanism (or lack thereof). You need to configure it to capture stderr from php processes and then have PHP send logs to stderr. Sorta wonky.

> Although on systems like Fly where you attempt to build one container to run an app, it’s a bit overkill.

I never used Fly but hosting a web + worker combo is common in a lot of tech stacks and with Docker it's really common to use 1 image to drive both containers with a different command. If Fly doesn't support that then I'd suggest hosting things elsewhere. Docker Compose and Kubernetes supports this no problem, it's a really basic / day 1 use case.

I've recently changed our nginx/php-fpm containers to caddy/php-fpm

Caddy has a supervisor plugin, so can start php-fpm itself and the containers entrypoint can be Caddy, which achieves similar objectives here that Caddy becomes a PHP application server.

FrankenPHP will perform better than php-fpm though, in worker mode, because it doesn't need to bootstrap fully on every request. In the conference slides, Kevin showed php-fpm had a 12ms request latency, whereas FrankenPHP had 3ms.

But yes, the supervisor plugin is definitely nice to be able to wrap up Caddy + php-fpm in a single container. Makes shipping it easier, especially with the PHP code (because both Caddy and php-fpm need access to the code; Caddy so it can serve static files and check for the existence of PHP files, and php-fpm to actually run your code).

So, not for everyone, especially when you have to manage your own binary.

No one can feel 0.01s faster load time and there will be a dozen more things to tune in your app than shave that tiny bit off.

There's really not much to manage. It's not in any way a challenge, especially if you ship it as a Docker container.

It's true it's probably not for everyone though; the worker mode will not work with legacy apps that heavily use globals and statics, and works best with frameworks that have infrastructure in place to reset in-memory state on each request. Symfony and Laravel are set up for this, for example. API Platform as well, which the author of FrankenPHP himself authored.

The decreased latency means you can serve more requests with the same hardware, with less of an energy cost. That's a win-win. It's not simply about the user experience.

Also remember that loading a webpage often takes many requests. Every little bit shaved off of one request is multiplied. Add onto this that it supports 103 Early Hints which can tell the client to start loading static assets ahead of time, this dramatically reduces total page load times because it avoids the cascade (i.e. browser needing to wait to read the HTML to know what JS/CSS to load). That definitely has a noticeable effect to users.