Support for PHP based applications.
Initial PHP support via lighttpd.
Cleaning launching, shutdown, docs.
- Make the stop script more configurable, and give lighttpd a chance to cleanup first
- Only launch a single php-cgi helper process
- Add docs on installing wordpress demo
We'll get reviewed and pulled shortly, pending any feedback. That being said, before we can pull it, we want to add the ability to enable/disable frameworks so that we don't disrupt the large production system at Cloud Foundry until this has been through our load/stress tests. We'll enable it in the Microcloud context out of the gate though.
Did you do add a test for this one in vcap-tests? I don't see a corresponding pull request for this over there like you did for the Erlang one.
I haven't, no - I'm a bit foggy on exactly what the process is for creating appropriate tests. I can certainly add one if I get some guidance on what I should be wiring in.
At a minimum we will need something that pushes an app that uses the framework and hits a url on it to make sure that the app launched correctly and is responding to end user requests. If you do any auto-wiring of services, i.e. rewriting DB connection strings or something like the spring framework does, then a test for that too.
Is that something just in the form of a Cucumber feature?
Would you expect to see these new languages woven into the current features, or should I just create a new feature for PHP? (I ask because I can't see any specific feature that deals with just basic deployment of each framework type)
You can do it as a new isolated feature if that is easiest. We plan on doing a lot of work on the test suite to enhance it.
Disable lighttpd from auto-starting
We have reviewed this pull request, it looks really good. We have some concerns though about using lighttpd as it seems to be de-facto abandoned — there were no changes to 1.4 since August 2010 and there is no information on 2.0 release date. Can you consider using nginx + php fpm as an alternative to lighttpd? We're using nginx ourselves in vcap and feel more comfortable if new runtimes use it as well. Thanks!
See, I was just interpreting that as it being stable ;)
I'll look into re-wiring to use Nginx.
It doesn't look like Nginx will work particularly well as a replacement, since it requires that you do your own PHP process management. As far as I can tell, launching multiple processes via dea would be quite tricky (mainly in the failure cases). I think I'm going to need to investigate using Apache + mod_php instead.
@paulj PHP-FPM handles its own process pool management.
@davidstrauss Indeed, it does, but it requires something to do the HTTP <-> FCGI bridge in front of it. So this requires the second process to support it. In the case of lighttpd, it would manage the php-fpm process. Nginx configurations require for you to specifically manage the lifecycle of the php-fpm process yourself, which seems to be difficult with dea's architecture.
@paulj It shouldn't be hard to set up a script that manages both the nginx and PHP-FPM daemons. vcap would only need to be aware of the master script.
Merge branch 'master' of git://github.com/cloudfoundry/vcap into php-…
Remove unintentional whitespace change.
@davidstrauss I did get a way down that path, but the problem is handling application crashes. Without writing a fairly complex supervisor, ensuring that the pair of processes are both alive or dead at the same time is fiddly. The default scripts just do a wait on the process - waiting on both means that the script would still look ok even if one of the two parts has crashed.
Merge pull request #2 from pantheon-systems/master
Update PHP support to HEAD of main repository master branch
@paulj What if the process forked nginx and PHP-FPM and then polled them (every X seconds) and killed itself if either has died? It would be pretty trivial using Python's subprocess support.
@davidstrauss interesting idea. It might even be possible to do this directly via the shell script too - the trap command could be used to be notified of any child failure, and cleanup any existing processes.
@paulj Or, to avoid polling, it would be possible to use a master Python process that starts two other Python processes (one each for nginx and PHP-FPM) and then waits forever. Each of the Python subprocesses would start its related daemon and wait for the daemon to terminate. On daemon termination, either Python subprocess would go on to terminate the master Python process.
@paulj That shell method looks even better.
PHP support pulled.