Open fg-j opened 2 years ago
fg-j
commented
2 years ago @paketo-buildpacks/php-maintainers @sophiewigmore and I are hoping to fill in some more context about this use case. We've split this out from the other php-fpm restructure issue since this represents a net new feature.
arjun024
commented
2 years ago Just curious about this line
it should NOT be a default process
Per the rfc: (1) the php-fpm buildpack sets the start command to start fpm. (2) the php-webserver (php-nginx/php-httpd) buildpacks sets the start command to start both fpm & the webserver. So if the detected group contains both (1) and (2), the start command of the php-fpm buildpack is a noop. Otherwise if the detected group only contains (1), the resultant built image can be used for standalone php-fpm. In that case, why shouldn't the fpm process be the default? edit: typo
dmikusa
commented
2 years ago To enable this new feature, this buildpack must contribute a new process type that runs php-fpm as PID1 in the container and is set up to manage process(es) running in other container(s).
I'm not sure I follow the "other containers" part. This should set up a process type that runs php-fpm and has it configured to listen on 0.0.0.0:9000, so it's accessible from outside the container. PHP-FPM itself will manage its sub-processes (it has a forking model). Those will run in the same container.
For validation, I think you'd just want to ensure that the process type is executing php-fpm and that when run it's listening on the right port and that the port can be accessed from outside the container. If it's doing those things, then a user should be able to configure a web server to talk over FastCGI (port 9000) and proxy requests to this container.
dmikusa
commented
2 years ago In regards to defaults...
(2) the webserver (nginx/httpd) buildpacks sets the start command to start both fpm & the webserver. So if the detected group contains both (1) and (2), the start command of the php-fpm buildpack is a noop. Otherwise if the detected group only contains (1), the resultant built image can be used for standalone php-fpm. In that case, why shouldn't the fpm process be the default?
This is new territory for me. I haven't had to deal with the case where two buildpacks both try to set default commands. With the Java buildpacks, they are mutually exclusive so only one will run and add process types. I had to look up in the spec to see what would happen.
An individual buildpack may only specify one process type with default = true. The lifecycle MUST select, from all buildpack-provided process types, the last process type with default = true as the buildpack-provided default. If multiple buildpacks define processes of the same type, the lifecycle MUST use the last process type definition ordered by buildpack execution for the combined process list (a non-default process type definition may override a default process type definition, leaving the app image with no default).
To @arjun024's point, and based on the spec I think that would depend on how the buildpacks are set up and the order group that gets used. You'd have to have PHP-FPM run first followed by the webserver buildpack. That way the webserver buildpack's default would override the PHP-FPM's default. Since the last buildpack to run wins. The proposed order group from the RFC is in that order, so it seems OK to me that they could both list a default process and we could change the criteria to: it should be a default process.
arjun024
commented
2 years ago You'd have to have PHP-FPM run first followed by the webserver buildpack. That way the webserver buildpack's default would override the PHP-FPM's default
There was a typo in my comment that I fixed now. I spelled out \<webserver> buildpack instead of php-\<webserver> buildpack.
I can't completely remember the discussion but I'll try to add what I recall from the RFC discussion for the 2 cases below:
(1) For the case with fpm and webserver running in the same container: The build cmd will be something like this:
pack build image <args> -b paketo/httpd -b paketo/php-dist -b paketo/php-fpm -b paketo/php-httpd
docker run <args> imageThe last buildpack's start command prevails, which according to the RFC is a start command (type web) to run PHP FPM and HTTPD Server. Thus the app starts both.
(2) For the case with fpm and webserver running in the separate container The build cmd will be something like this:
pack build fpmimage <args> -b paketo/php-dist -b paketo/php-fpm
pack build httpdimage <args> -b paketo/httpd # with httpd.conf configured to the right fpm socket
docker run <args-to-expose-fpm-port> fpmimage
docker run <args> httpdimageI believe both cases are taken care of by the order grouping in the RFC (perhaps the php-builtin-server in the final group should be optional?)
This is new territory for me. I haven't had to deal with the case where two buildpacks both try to set default commands.
This is less than ideal as there's duplication of setting start commands, but since spec doesn't allow a way for 2 buildpacks to contribute start commands, not sure if there's another option. See first point in Unresolved Questions
Per the restructure RFC:
To enable this new feature, this buildpack must contribute a new process type that runs php-fpm as PID1 in the container and is set up to manage process(es) running in other container(s).
To accomplish this, the buildpack should contribute a process to the launch configuration.
php-fpmThe buildpack should use
phpwith commands likephp --inito locate files it may need to properly configure the start command, like the location of the PHP installation, (rather than relying on environment variables being set by other buildpacks). This means that the buildpack's API will change to require php at launch AND at build time.Acceptance
TBD