Re: Why FastCGI?

Greetings, Gunter Grodotzki.
In reply to Your message dated Thursday, April 1, 2021, 13:53:06,


>> Eh, why? If you do not upload files, you don't need a shared volume.
>> 

> True. I suppose you can just passthrough any “.php” from nginx to fastcgi
> without verifying existence and then rely on php-fpm completely to handle failures.
> Then of course you would have to ensure that all static files are built
> into the nginx container while the php files are in the php-fpm container.

I have exactly zero .php files inside a webroot, even though I don't use
Docker. nginx is hardcoded to request the front controller script regardless
of what was requested. (The SCRIPT_FILENAME var is set to constant value.)

>> And will still need shared volume in same cases you would for CGI link.

> unless of course - similar to the php built-in you make it also respond to
> non-php files. Then you can add nginx as a layer (as mentioned in my
> previous post) but they both will work completely independently - file-wise.

Exactly. nginx will serve statics from specified location(s), the rest will be
sent to the backend.
If I want to return the ball from PHP to the nginx, I can use X-Accel-Redirect.

>> Er, I use TCP for my PHP FPM. For years.

> You are quoting me out of context so it makes little sense. I never said
> you couldn’t nor did I say a shared volume is required for fast_cgi_pass.

True. It just the discussion made the impression that shared volume is
required for FastCGI to operate. Sorry for confusion.

>> That says so much about people building these containers…

> Always easier to dismiss people than to put yourself in someone else’s shoes
> to understand their problem :)

I understand their problem. I've been there myself, and even made worse
mistakes that some wrong assumptions.


-- 
Sincerely Yours, Andrey Repin <[email protected]>