PHP Cloud Native Buildpacks

At work, I've been helping to rewrite the PHP buildpack as a set of Cloud Native Buildpacks. The PHP CNBs are coming together, current quality is alpha, but I think they're ready enough for people to try them out and report how they work for you. This post has instructions and a demo to use the PHP CNBs.

But first, a slight digression.

A little about the architecture of the PHP CNBs. The previous PHP buildpack has been decomposed into a set of five PHP CNBs, two of which are optional. There are php-cnb, php-composer-cnb, httpd-cnb, nginx-cnb and php-web-cnb.

Here's a rough description of each:

• php-cnb provides PHP binaries, that's it.
• php-composer-cnb provides all the functionality related to Composer. It installs and runs Composer.
• httpd-cnb provides Apache Web Server. It is optional.
• nginx-cnb provides Nginx Web Server. It is optional.
• php-web-cnb ties everything together. It generates the configuration for PHP, PHP-FPM, HTTPD and Nginx. It also contains the logic to generate start commands for various types of PHP apps. It can run PHP cli scripts, PHP's bundled web server, PHP-FPM plus HTTPD and PHP-FPM plus Nginx.

What's also super cool about these CNBs is that some of them like httpd-cnb and nginx-cnb can work all on their own. Want to stand up a proxy or a static site, httpd-cnb or nginx-cnb can be given an httpd.conf or nginx.conf file and they'll run their respective server with that config for you. Similarly, you can mix and match CNBs. Don't want to use the PHP binaries provided by php-cnb, you could substitute another CNB that provides PHP. Pick the parts you like, replace the ones you don't with other things.

On to the show.

If you want to get started there's a little setup that you need to perform.

First,  `git clone` these repos and optionally check out a release branch.

• https://github.com/cloudfoundry/php-cnb
• https://github.com/cloudfoundry/php-composer-cnb
• https://github.com/cloudfoundry/httpd-cnb
• https://github.com/cloudfoundry/nginx-cnb
• https://github.com/cloudfoundry/php-web-cnb

Second, install the latest version of the pack cli. That is v0.2.1 at time of writing.

Third, install Docker if you don't have it already. Make sure it's running too.

Fourth, package up each buildpack that you'd like to use. In each folder that you cloned, you can run `./scripts/package.sh` and it will build the CNB (this requires Golang to be installed). Note the path at which the packaged CNB can be found. You'll need to pass this to the pack cli so it can find the buildpacks. To do that, run `export BUILDPACKS='--buildpack /path/to/buildpack1 --buildpack /path/to/buildpack2 ...'` and paste in the path to each buildpack you packaged. Order is important, use the order listed in the bullet list above.

If you'd like to build them all at once, you can run the following command from the directory where you cloned all of the repos:

for buildpack in ./php-cnb ./php-composer-cnb ./httpd-cnb ./nginx-cnb ./php-web-cnb; do pushd "$buildpack" && ./scripts/package.sh && popd; done | grep "Creating package in" | awk '{printf "--buildpack %s ", $5}'

This will run the package script for each CNB & then print out a list of the locations for each package. Simply copy the output, then run `export BUILDPACKS='paste output from command here'`. We set this as a convenience to make using the pack cli easier and the commands shorter.

At this point, you're all set to build some images. To do this, you run `pack build $BUILDPACKS -p /path/to/php/files`.  This will build an image using the buildpacks that we've specified in our environment variable and it will use the PHP code that you've pointed to with the `-p` argument (you can skip `-p` if the files are in the current directory.

As `pack build` runs, you'll see each build pack run. If there are any errors the buildpack will fail and tell you what happened. If it succeeds, you'll end up with a docker image that you can run using the command `docker run`. For example, if you have a web app, you can `docker run -it -e PORT=8080 -p 8080:8080 `.  The PORT env variable tells the web server which port it should listen to. That should match with the port that you expose using the `-p` flag.

Time for a full example.

Let's say you want to run PHP MyAdmin. The following is a demo of how you could do that. For simplicity sake, it spins up a Percona DB as well. That allows you to have something to connect to within PHP MyAdmin. If you already have a MySQL DB, you can skip that part and point `htdocs/config.inc.php` to your existing server (you could also skip the docker network bits, that just makes it easy to connect to the deployed Percona DB).

Download and run the Gist below. This will set everything up for you.

Here are the highlights:

• Line #10 runs Percona
• Lines #15 - #21 download PHP MyAdmin & configure `htdocs/config.inc.php`. If you want to adjust PHP MyAdmin's config, you can do so at this point.
• Lines #24 - #36 adds a php.ini snippet that enables the PHP extensions needed by PHP MyAdmin
• Line #45 runs `pack build`
• Line #48 runs the image that we build with Docker.

At this point, you can go to http://localhost:8080 in your browser and you should be able to access PHP MyAdmin. Enter `root` and `hacKm3` as the credentials and you can access the database. If you edited the config to point to your own MySQL server, use the credentials for that server instead.

Last notes:

• If you want to adjust the PHP MyAdmin config. Run `docker stop php-myadmin`. Edit `htdocs/config.inc.php` then run lines #45 & #48 again.
• If you want to clean up & remove everything run `docker stop php-myadmin test-db` followed by `docker system prune --volumes`. The latter will clean up a bunch of things for you, be careful when running that if you are running other things with Docker.

Please provide any feedback about the PHP CNBs to the respective CNB Github page. Open an issue with your comments/questions. Thanks & hope you enjoy!

CloudFoundry & PHP

Update:  This article is out-of-date.  Please see this updated article instead.

As a part of my job, I get to work on the support team for Pivotal's commercial offering of CloudFoundry. For those who don't know, CloudFoundry is an OpenSource PaaS (Platform as a Service) project that allows a developer to run his or her application without having to worry about managing and administering the back-end servers to run it.
For the past year and a half, CloudFoundry has been running as a free service for developers to test. In the last month, the service was updated to v2 or the second generation of the service. In addition to readying the service for production use, this update is a nice refinement of the system and adds some awesome new functionality in the system.
One of the nice new features is that users now have the ability to run any arbitrary applications on the system, regardless of CloudFoundry "officially" supporting that development stack. Borrowing a good idea from Heroku, CloudFoundry has added support for build packs. Build packs are a way that end users can customize the deployment environment for their applications. Out-of-the-box CloudFoundry provides build packs for Ruby, the JVM (Servlet, Spring, Grails, Play, Lift, etc...) and Node JS, but it does not end there. Users can specify an arbitrary build pack by specifying the "--buildpack" argument as they push their application to CloudFoundry. By using this argument, a user will indicate that a custom build pack should be used to build and deploy their application.
In an effort to learn more about the build pack system, I've created a new build pack for CloudFoundry to run PHP based applications. The build pack is hosted on Github here and instructions for using it can be found in the README.
With the PHP build pack, a user can push anything from a custom PHP application to phpMyAdmin or even Wordpress.
I encourage PHP developers to give it a shot, see how it works for them and post feedback to the Github project!