[php] core/php: Updated to run PHP-FPM as a service

[baggerspion]

Signed-off-by: Paul Adams paul@baggerspion.net

This update to the core/php package allows the user to optionally run php-fpm as a service to be bound to, and not simply as a library for import. This should not break any existing package that is based upon core/php, but open the door to building composite packages for PHP applications that deploy both nginx/apache + php-fpm. This is part of my overall mission to improve core/drupal.

[thesentinels]

Thanks for the pull request! Here is what will happen next:

1. Your PR will be reviewed by the maintainers
2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

[lancewf]

Thank you for adding this. I was planning on adding this same service but as a separate package like this one here.
https://github.com/lancewf/habitat-plans/tree/master/php-fpm/.

The way you are doing it here with updating the php plan seems like a better option.

We need this update to also fix the core/wordpress library that currently does not work, because it tries to spawn the php service from the hook/init (https://github.com/habitat-sh/core-plans/blob/master/wordpress/hooks/init#L25).

I have a small example of a LEMP that is using this PR’s code for the PHP service.
https://github.com/lancewf/habitat_lemp_dev_environment

Please try to get this merged in. I have 3 more project I would like to start packaging with this service. Two of them are with wordpress and I would love to get a good example up.

[lancewf]

Should we default this to "127.0.0.1"?

[baggerspion]

No strong opinion, so happy to change this.

[lancewf]

Can we add the 'listen' parameter also here. If the user is binding to localhost, checking the listen parameter is the only way to know that.

[baggerspion]

Easily added.

[afiune]

[lancewf]

What do you think about replacing the 'listen' export for a 'local_only' boolean export? The problem I am trying to solve is when the service is bound to localhost only. In that case the dependent service cannot connect with the IP address ('bind.php.first.sys.ip') it has to use 127.0.0.1. I have another PR here where I am trying to add the 'local_only' flag for mysql.

[nellshamrell]

@therealpadams ty so much for this contribution! Initially, the code looks fine and super useful. However, because this is a change in behavior, I would like to test this. Do you have any sample apps you could point me to that deploy both nginx/apache + php-fpm so I can test this?

[rsertelon]

@nellshamrell I think this might be it: https://github.com/therealpadams/habitat-plans/blob/master/drupal-nginx/plan.sh

[baggerspion]

I really want to make a composite plan for core/drupal. Let me give you a build of that using my baggerspion origin and you can then see this package in action. The package that @rsertelon linked is not built using this version of this plan. Eta sometime this week.

[lancewf]

@nellshamrell I have an example application with nginx/mysql/php here that uses these php changes published to my origin (lancewf/php).
https://github.com/lancewf/habitat_lemp_dev_environment

Also, below is a real nginx/mysql/php application that is using the same lancewf/php package.
https://github.com/lancewf/Marine-Mammal-Stranding-Network-Server

To test them out, enter the studio from the root directory and run the 'start' function.

[nellshamrell]

TY for the testing tips! Testing this now.

[nellshamrell]

@therealpadams I'm having some difficulty getting this tested. I first tried to create a plan similar to core/drupal or core/wordpress that used both core/nginx and the current core/php, which turned out to be an absolute nightmare (I can definitely see the reason for this PR and why people are so enthusiastic about it!).

This afternoon I took a different approach and attempted to create a new php site based on a build of this plan, a server plan based on core/nginx, and combined the two. I haven't quite got them binding yet, but if you are interested all of my current code is here.

Could you give me some guidance in how to use/test this? Additionally, since this is now a service package, rather than a binary package, could you be sure to update the README with the same information (using this template)?

This seems tremendously useful to our community, and I look forward to getting this tested, updated, and out into the world!

[baggerspion]

Hi @nellshamrell, "yes" to all of the above. I'm a little swamped at work just now, so it probably next week before I can get to this. I think the best thing I can do is also submit a PR for core/drupal that makes use of this. Then it should be easier to see how everything glues together.
With that "example" out of the way, separately I will tackle improved docs within this PR.

[nellshamrell]

Sounds great! TY!

[rsertelon]

@therealpadams Gentle ping ;)

[themightychris]

I have been working on something similar, and have a pretty thorough battery of code and practice working for testing/verifying PHP-FPM. A Caddy server spawned in your .studiorc is a great quick way to test it. And the the cgi-fcgi binary I'm providing in #1527 is a big help too. Unfortunately I can't post the project I'm piloting it on wholesale yet so I'll have to smuggle things out gradually for now

I recommend adding some additional config, but it would probably be safest to make at least the status path be off by default:

[path]
ping = "/.well-known/php-fpm/ping"
status = "/.well-known/php-fpm/status"

{{#if cfg.path.ping~}}
    ping.path                                      = {{ cfg.path.ping }}
{{~/if}}

{{#if cfg.path.status~}}
    pm.status_path                                 = {{ cfg.path.status }}
{{~/if}}

With that and the libfcgi package added as a pkg_dep, the php-fpm service could then come with a health_check script like this:

#!/bin/bash -e

{{#if cfg.path.ping}}
    SCRIPT_NAME="{{ cfg.path.ping }}" \
    SCRIPT_FILENAME="{{ cfg.path.ping }}" \
    REQUEST_METHOD="GET" \
        {{pkgPathFor "core/libfcgi"}}/bin/cgi-fcgi \
            -bind \
            -connect {{ sys.ip }}:{{ cfg.network.port }} \
        | grep pong
{{/if}}

I haven't written it yet but I think the health_check should also come with a test of the status page when enabled and output some of its key metrics like core/mysql's health_check

[themightychris]

Here's some useful snippets for testing with Caddy in a studio:

/src/Caddyfile:

localhost:2015 
 
errors errors.log 
 
fastcgi / 127.0.0.1:9000 { 
    root /src 
    index phpinfo.php 
    env SITE_ROOT /src 
    env SCRIPT_FILENAME /src/phpinfo.php 
} 

/src/phpinfo.php:

<?php

phpinfo();

/src/.studiorc:

echo
echo "--> Installing useful packages for development..."
hab pkg install core/caddy


echo
echo "--> Setting up development commands..."

echo "    * Use 'start-caddy' to launch a Caddy web server to expose the PHP-FPM application at http://localhost:2015"
start-caddy() { 
    hab pkg exec core/caddy caddy & 
}


echo

[baggerspion]

Just a quick poke to show that I am still alive and working on this! Especially during the Chefconf hackday. So here is my TODO list for ChefConf:

• Add libfcgi and create healthcheck
• PRovide (at least) a baggerspion/drupal based upon this package as an example of it in use

[nellshamrell]

@therealpadams - have you had a chance to look further into "Add libfcgi and create healthcheck"?

[nellshamrell]

@therealpadams - thank you so much again for this contribution. Because it's starting to drift from master pretty significantly, I'm going to go ahead and close this for the time being, but please feel free to re-open it at any time when you have some time to work on it.