Feature Request: Docker-based php-fpm containers

[aka-tpayne]

I'd like to see the php-fpm layer of Valet be able to use Docker containers to support multiple version of PHP concurrently. This would be configurable per site if necessary, but default to the latest version of PHP that Valet uses.

Valet + Docker-based php-fpm containers + Takeout would be amazing.

Reference Tweet:
https://twitter.com/aka_tpayne/status/1299427266418667521?s=20

[mattstauffer]

I love this idea.

valet use docker {somethingHere} or somethign like that and then we're serving a docker-hosted PHP.

[drbyte]

IMO if this is the direction Valet is going to go, then first Valet should be refactored to just be a "DNS+domains" helper tool, which by default connects homebrew Nginx/PHP or optionally connects Docker-served Nginx/PHP (but without doing any docker management whatsoever: just passing it to Takeout)

Mangling the current PHP/Nginx treatment without abstracting it out first will result in chaos.

The result is Valet becomes something less than what it does today.

[mattstauffer]

Eh, I'm more inclined to keep Valet as a primarily-Brew-managed tool; if it's impossible to do this well without mangling Valet I'd rather we build a bridge or something.

That said, to be clear: I don't think we should make any changes to Nginx, only PHP.

[drbyte]

Agreed: remaining Brew-focused is essential.
Agreed: no immediate need to touch Nginx versions. Just its configs.

Here's a slightly updated explanation of what I meant earlier:
Valet first needs to be expanded to allow per-domain PHP directives in the domain's nginx config.
Currently it supports only a single active PHP version, and various commands write/rewrite all configs to use that active PHP version's FPM socket.
Reworking that capability then opens up the freedom to either just use multiple brew-managed PHP versions or specify to use docker for specific PHP versions.

As for the "DNS+domains helper" comment, I'll clarify: lots of people say they "want Valet and (something)" (eg docker/etc), but don't state what they mean by the "want Valet ...." part. Usually I discover what they mean by that is the simplified local project directory + domain resolution stuff, and have all that point to their webserver+php version/s of choice. And the reason they want "choice" over webserver/php stuff is because they have project-specific requirements such as ancient PHP versions or alternate webserver engines so they're containerizing that stuff or proxying it away someplace.

So, if we tackle the part about being able to specify a certain PHP connection/provider per-domain without just overwriting all configs when changing the PHP version, that will likely significantly improve the flexibility desired.

As to how to denote which PHP service to use ... well ... that needs exploration.

• currently it only supports one provider: PHP-FPM specifically via a socket at ~/.config/valet/valet.sock
• custom configuring per-domain would require tracking state, either by writing to a file (json?) to remember what was requested via CLI for each domain, or simply parsing out of each nginx config what socket/connection is being used (requires intelligent reading/writing of the Nginx configs, instead of just reading a stub and substituting placeholders as it does now)

I prefer to avoid more json files, as that leaves garbage behind and means more places to fail. Parsing the nginx files is probably best, and probably means we should add a text placeholder "section" where we replace the fastcgi provider text between start/end block of the placeholder lines.
Then when Valet installs a PHP version it needs to set a version-specific socket that it's running on.
Then there needs to be a way to tell Valet what providers are available, even if that's just an internal function that enumerates installed (or at least "running") PHP versions.
And some way of cleaning up old Nginx configs when a PHP version is deleted. Otherwise 502 Gateway Not Found errors will be prolific.
And probably an audit of some sort, even if it's just an update to the sites command to note which PHP connection is configured for each domain. (Kinda like the proxy list command does.)

Sorry, I've probably repeated myself a bunch here. Need a coffee break!

[mattstauffer]

Valet first needs to be expanded to allow per-domain PHP directives in the domain's nginx config.

Right! Got it.

custom configuring per-domain would require tracking state, either by writing to a file (json?) to remember what was requested via CLI for each domain

I was thinking it would have to live in ~/.config/valet/config.json in a paths section or something?

But I guess we could try the nginx thing too? That seems.. a bit hairier for me, though, which is why I'd prefer Json?

Then there needs to be a way to tell Valet what providers are available,

Yah, I think the hardest part of this whole thing is how Valet would know what's available and how it would clean up. I often switch PHP versions globally with Valet and then some other parts of my system break. I really wish there were a single repository system that had knowledge of the state of my running PHP installs--both with Brew and, now, with Docker.